Resolve Sophos Firewall ARP Issues After Migration

After replacing a firewall, the new Sophos Firewall may be online while individual public alias IP addresses remain unreachable. The upstream router often still associates these addresses with the WAN MAC address of the old appliance. Packets then never reach the new firewall, even though the alias, DNAT and firewall rule appear to be correct.

This guide shows how to narrow down this IPv4 issue by checking the interface, Packet Capture and upstream ARP. Only after confirming the Layer 2 cause should you update the ARP cache selectively or trigger an ARP ping through the Device Console. For general hardware migration guidance, also see Compare Sophos XG and XGS.

When ARP Is Actually the Suspect

The issue typically starts immediately after replacing an appliance, restoring a configuration or switching vendors. The public IP address remains the same, but the MAC address of the WAN interface changes.

Strong indicators include:

• The main IP address of the WAN interface works, but one or more alias IP addresses do not.
• An external test cannot reach a published service on specific public IP addresses.
• Packet Capture shows no incoming packet for the affected IP address.
• The service suddenly starts working after an upstream cache expires, without any further firewall changes.
• The upstream router still shows the MAC address of the old appliance for the public IP address.

ARP is not automatically the cause. If packets reach the WAN interface, the next checks are DNAT, the firewall rule, zone, internal server and return route. This procedure also does not apply to IPv6, where Neighbor Discovery performs neighbour resolution.

To inspect the Sophos Firewall’s local ARP or NDP cache instead, see Check the ARP and NDP neighbor cache. It also explains when flushing the cache is appropriate and when the problem still lies with the provider or upstream device.

Why Alias IPs Can Fail After a Replacement

ARP maps an IPv4 address to a MAC address on the local Layer 2 segment. A router stores this mapping in its ARP cache. After the replacement, the upstream device should learn the WAN MAC address of the new firewall. If it does not do so for an alias IP address, it continues sending packets to the old hardware.

This explains why the main IP address can work while an alias IP address fails: the upstream device maintains a separate entry for each IP address. One mapping may already be current while another still points to the old MAC address.

First, however, establish how the provider delivers the public addresses:

• Directly connected network: The upstream device resolves the main and alias IP addresses using ARP. Stale entries after replacing hardware are plausible.
• Routed public block: The provider routes the block to the primary WAN IP address. A separate ARP entry for each public IP address is not necessarily expected; the provider route and the local alias or NAT configuration are more important.

Diagnose Before Intervening

The diagnosis should first establish where the packet flow stops. This avoids changing ARP, NAT and firewall rules at the same time.

1. Under Network > Interfaces, check the physical WAN interface and the affected addresses. An alias IP address is bound to the correct physical interface through Add interface > Add alias; the IP version, address and netmask must match the design.
2. If alias addresses come from a different subnet, check whether the upstream gateway in that subnet is reachable from the firewall. Multiple separate WAN interfaces in the same subnet are not a clean solution and can themselves cause ARP issues; depending on the design, alias or LAG interfaces are intended for this purpose.
3. Test the same public IP address and service from a genuinely external system. Ping alone is insufficient because ICMP may be blocked; also test a known TCP port.
4. Capture traffic on the WAN interface under Diagnostics > Packet capture. For the Layer 2 check, filter by interface and Ethernet type: ARP; then filter for the service by the affected destination IP address and protocol.
5. Only when IP packets arrive should you search the Log viewer for the destination IP address, service, Firewall Rule ID and NAT Rule ID. Assess ARP itself with Packet Capture, not with a normal firewall rule log.

Use Packet Capture on Sophos Firewall explains the display in more detail. For checking the interface, zone and alias assignment, see Configure Sophos Firewall zones and interfaces.

The observation points in a clear direction:

• No packets on the WAN interface: Check upstream ARP, provider routing, the CPE or an upstream switch.
• Packets arrive and are dropped: Check the firewall rule, DNAT, zone and service.
• Packets are forwarded internally but no response returns: Check the return route, internal server, SNAT and server firewall.
• Only the alias IP is affected: Compare the alias configuration and upstream entry specifically for that IP address.

Update the ARP Mapping Selectively

Clear the Upstream Cache

The cleanest correction is made on the device that holds the incorrect entry. If you manage the upstream router or provider CPE, delete the ARP entry specifically for the affected IP address. The upstream device must then learn the new WAN MAC address.

If the entry cannot be cleared selectively, restarting the responsible router may also refresh the cache. Schedule this in a maintenance window because a restart interrupts other connections. For provider-managed devices, give the provider the affected IP address, the old and new MAC addresses and the responsible CPE instead of restarting the entire path indiscriminately.

Trigger an ARP Ping Through the Device Console

Sophos Firewall provides an ARP diagnostic in the Device Console. Using the affected source IP address and WAN interface, an ARP ping can prompt the directly connected upstream device to update its mapping.

After signing in through the console or SSH, open Option 4: Device Console and run the command with the actual values:

system diagnostics utilities arp ping source <alias-ip> interface <wan-interface> <upstream-gateway>

Example using documentation addresses:

system diagnostics utilities arp ping source 198.51.100.21 interface Port2 198.51.100.1

Here, 198.51.100.21 is the affected alias IP address on Port2; 198.51.100.1 is the directly reachable upstream device on the same Layer 2 segment. The source IP address, interface and destination must correspond. If several alias IP addresses are affected, test each address individually so that the effect remains traceable.

The command does not correct an invalid alias configuration or a static ARP entry at the provider. If the provider routes the addresses instead of resolving them locally through ARP, ARP ping is also not the appropriate solution. Connect to Sophos Firewall using SSH explains secure access to the Device Console.

Validate Connectivity After the Correction

Repeat the same test after exactly one corrective action. This keeps it clear which action resolved the issue.

1. Check whether the affected IP address now points to the new WAN MAC address on the upstream device.
2. Repeat the external ping or TCP port test with the same source and destination.
3. Use Packet Capture to verify that the packets now reach the WAN interface.
4. If packets arrive, check the Firewall Rule ID and NAT Rule ID in the Log Viewer.
5. Test the published service through to the internal server and back along the return path.

An updated ARP entry only proves that the upstream device can send packets to the new firewall. Whether the service works still depends on DNAT, the firewall rule, the internal target and the return route. Publish a server using DNAT shows the complete rule path for publishing a server.

If the Issue Persists

If the IP address remains unreachable despite an updated ARP entry, do not try additional shell commands. Change the hypothesis instead.

Typical alternatives include:

• The alias IP address is assigned to the wrong physical interface or uses an incorrect netmask.
• The provider routes the public block differently from what was assumed.
• A static ARP or MAC entry on the upstream device overrides dynamic learning.
• An upstream switch retains an old MAC mapping or uses port security.
• The DNAT rule refers to a different public IP address.
• The firewall rule does not permit the source, service or zone.
• The internal server replies through a different gateway.
• In an HA deployment, the wrong virtual or physical MAC address is expected.

Repeated ARP loss is also not a case for a periodically executed custom command. The provider, CPE and Layer 2 design, and Sophos Support where necessary, must be used to determine the cause.

Involve the Provider or Upstream Team Precisely

If the WAN capture shows no packets for the affected IP address, the provider needs precise findings rather than a general report that the firewall is unreachable.

Have the following ready:

• affected main or alias IP address,
• WAN interface and new MAC address,
• upstream gateway or CPE,
• time of the external test and ARP ping,
• Packet Capture result,
• expected delivery as a directly connected or routed network,
• result for the main IP address and other alias IP addresses.

This allows the provider to check the specific ARP entry, a static mapping or the route to the public block. Only transmit sensitive configuration data or complete packet captures through an agreed support channel.

Compact Acceptance Checklist

• Main and alias IP addresses and the delivery method are documented.
• Physical interface, IP version and netmask have been checked.
• External TCP test and Packet Capture were performed against identical destinations.
• ARP and IP traffic were considered separately during diagnosis.
• The upstream entry was cleared selectively or ARP ping was run with the correct parameters.
• The new MAC mapping was confirmed on the upstream device.
• DNAT, Firewall Rule ID, NAT Rule ID and the return path were checked subsequently.
• The cause and corrective action were documented in the change or migration record.

FAQ