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 on the device that holds the stale entry. For general hardware migration guidance, also see Compare Sophos XG and XGS Appliance.

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. If there are more than three aliases, SFOS initially shows only three addresses. Hover over a visible address and scroll through the list before recreating an alias that appears to be missing.
2. If alias addresses come from a different subnet, internal hosts must use Sophos Firewall as their default gateway, and the upstream device needs an address in every alias subnet that acts as a reachable gateway for the firewall. According to Sophos, multiple separate WAN interfaces in the same subnet cause ARP issues and unreachable gateways; use alias or LAG interfaces as appropriate for the design.
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. Under Diagnostics > Packet capture, turn on the capture and open Display filter. For the Layer 2 check, select Interface name and Ethernet type: ARP. For the service, use Ethernet type: IPv4, the affected Destination IP and, if needed, Destination port. Without Wrap capture buffer once full, capture stops when the 2048 KB buffer is full; click Clear, then repeat the reproducible test. With the option selected, capture continues from the beginning of the buffer and overwrites older packets.
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 IPv4 packet on the WAN interface: Check upstream ARP, provider routing, the CPE or an upstream switch.
• Status Incoming or Violation: The packet reaches the firewall. For Violation, Reason, the firewall rule, DNAT, zone and service provide the next clues.
• Status Forwarded, 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 on the Upstream Device

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, Sophos lists restarting the responsible router as the alternative. Schedule it in a maintenance window because a restart interrupts other connections and cannot be undone. Clearing a dynamic cache entry needs no configuration rollback because the router relearns it. If you roll the migration back, clear the entry again after reconnecting the old appliance so that the old MAC address can be learned. 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.

No additional Device Console command is needed for this fix. The current SFOS 22 help explicitly specifies clearing the router cache or restarting the router for stale alias ARP entries. If the provider routes the addresses instead of resolving them locally through ARP, both actions against an alias entry are ineffective; check the provider route and local alias or NAT configuration instead.

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 primary device responds to ARP requests with the interface’s virtual MAC address. Only virtual appliances with Use host or hypervisor-assigned MAC address selected use the host- or hypervisor-assigned MAC address instead.

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 cache clear or restart,
• 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 the router was restarted in an agreed maintenance window.
• 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