Resolve Sophos Firewall ARP Issues After Migration

After a firewall migration, it may happen that the new Sophos Firewall is generally online, but individual public IP addresses or alias IP addresses are still unreachable. This is particularly typical after switching from another manufacturer to Sophos Firewall or after migrating from XG to XGS hardware. The IP addresses remain the same, but the MAC address on the WAN interface changes.

If an upstream router, a provider CPE, or a switch still has old ARP entries in the cache, it continues to send packets to the previous MAC address. This then appears as if only certain alias IP addresses, DNAT targets, or ping tests do not work. For general migration planning, the article What is the difference between an XG and XGS Firewall? is also suitable.

Typical Symptoms

ARP issues after a change usually appear immediately after the switch or after a restore on new hardware.

Typical indications:

• The WAN interface of the Sophos Firewall is online.
• The main IP address works, but individual alias IP addresses do not.
• Ping to certain public IPs fails, while other IPs on the same interface respond.
• DNAT or WAF rules appear correctly configured but do not reach the internal server.
• A service is reachable internally but is only disrupted on certain public IPs externally.
• After some time, it suddenly works because an ARP cache automatically expires.

It is important to differentiate: Not every accessibility issue after a migration is an ARP problem. Firewall rules, NAT rules, zones, alias configuration, provider routing, and return routes must also be checked.

Why ARP Can Be Disruptive After a Migration

ARP resolves IPv4 addresses into MAC addresses. In a local Layer 2 segment, a device asks: Which MAC address belongs to this IP address? The answer is stored in the ARP cache so that not every packet triggers a new ARP request.

During a firewall migration, the IP address often remains the same, but the MAC address changes. This can be problematic:

• The provider router still knows the public IP with the old MAC address.
• An upstream switch or router holds outdated ARP entries.
• An alias IP was correctly set up on the new firewall, but the neighbour continues to send to the old hardware.
• Only part of the IPs has already been relearned, so some addresses work and others do not.

With individual alias IP addresses, this is particularly confusing because the basic connection seems to work. One quickly looks into NAT, firewall rules, or routing, although the error already occurs at Layer 2.

Check Before the CLI Command

Before actively triggering ARP, the basic configuration should be correct. Otherwise, an ARP ping will only cover up another problem.

Check:

1. Under Network > Interfaces, check if the affected IP address or alias IP address is on the correct interface.
2. Check the zone of the interface, for example, WAN.
3. Check gateway, subnet mask, and alias network logic.
4. Under Rules and policies > NAT rules, check if the DNAT rule points to the correct public IP.
5. Under Rules and policies > Firewall rules, check if there is an appropriate rule for the traffic.
6. In the Log Viewer, see if packets are arriving at the firewall at all.
7. If necessary, use Sophos Firewall Packet Capture in WebAdmin to check if incoming packets are visible on the WAN interface.

If no packets for the affected public IP arrive in the Packet Capture, the problem is likely before the firewall: provider router, upstream switch, ARP cache, or routing at the provider. If packets arrive but are discarded, NAT, firewall rules, and zones should be checked first. For interface and zone logic, Configure Sophos Firewall Zones and Interfaces can help.

Execute ARP Ping via the Device Console

Sophos Firewall can trigger an ARP ping with a defined source IP and interface via the Device Console. This is helpful if an alias IP should be actively announced in the network after migration.

Important: The command should only be executed when it is clear which source IP, which interface, and which target in the local segment are used. Incorrect values do not help and can distort the analysis. Before making changes to a productive migration, a current Sophos Firewall Backup should be available.

The command is executed in the Device Console, not in the Advanced Shell:

system diagnostics utilities arp ping source <alias-ip> interface <interface> <target-ip>

Example:

system diagnostics utilities arp ping source 198.51.100.21 interface Port2 198.51.100.1

In this example, 198.51.100.21 is the affected alias IP on Port2. 198.51.100.1 is a reachable target in the same Layer 2 segment, typically the upstream gateway or the provider CPE. This causes the firewall to generate ARP traffic with the correct source IP over the correct interface.

If SSH is not yet set up, Connect Sophos Firewall via SSH describes how to access the Device Console. During migrations, SSH should not be broadly allowed from the WAN permanently. A temporary, restricted administrative access from a trusted network is better.

Recommended Procedure

1. Collect Affected IP Addresses

First, document which IP addresses work and which do not. For alias IP addresses, the list should be directly compared with the interface configuration.

Note:

• Interface, for example, Port2
• Main IP and alias IP addresses
• Upstream gateway or provider CPE
• Affected NAT or WAF rules
• Result of ping, port test, and packet capture

2. Narrow Down ARP Issue

From an external test system, check the affected public IP. Simultaneously start packet capture on the Sophos Firewall on the WAN interface.

Interpretation:

• No packets arrive at the WAN interface: Check upstream, ARP, provider routing, or upstream device.
• Packets arrive but are discarded: Check firewall rule, NAT, zone, or service.
• Packets arrive and go internally, response missing: Check return route, internal server, SNAT, or server firewall.
• Only alias IP affected, main IP works: Specifically check ARP cache or alias configuration.

3. Execute ARP Ping for Each Affected Alias IP

For each affected alias IP, execute the ARP ping with the appropriate source IP and the correct interface. After that, do not immediately change several other things, but first test if the behaviour changes.

Example with placeholders:

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

If multiple alias IP addresses are affected, the command is executed individually per address. This makes the check traceable and prevents not knowing which measure helped in the end.

4. Validate Accessibility

After the ARP ping, repeat the same test:

• Ping or TCP port test from external.
• Packet capture on the WAN interface.
• Filter Log Viewer on the affected target IP.
• Check NAT and firewall rule if packets now arrive.

If the upstream correctly relearns the ARP information, packets for the alias IP should now arrive at the new firewall. Whether the published service then works depends additionally on NAT, firewall rules, internal server, and return path.

If ARP Ping Does Not Help

If the ARP ping does not bring improvement, do not randomly try further commands. A structured narrowing down is then sensible.

Further checks:

• Upstream device may still hold outdated ARP entries.
• Provider needs to reload ARP cache or CPE.
• Alias IP is on the wrong interface or in a wrong network.
• Public IP is routed by the provider instead of being learned directly in the local segment via ARP.
• DNAT rule points to the wrong public address.
• Firewall rule does not allow the traffic.
• Internal server responds via another gateway.
• Wrong MAC address expected during HA or hardware change.

Restarting the provider CPE or an upstream router can clear ARP caches but should not be the first measure. In productive environments, it is cleaner to first collect evidence with packet capture and Log Viewer.

Involve Provider or Upstream Specifically

If no packets for the affected public IP arrive at the WAN interface, the request to providers or upstream responsible parties should be as specific as possible. A general message like “the firewall is not reachable” often leads to unnecessary loops. Better is a short technical proof showing which IP is affected and what was checked on the Sophos Firewall.

Helpful information:

• Affected public IP or alias IP: The provider can specifically check the ARP or routing entry.
• WAN interface and new MAC address: Shows which assignment is expected after the migration.
• Upstream gateway or CPE address: Narrows down which neighbouring device needs to learn the address.
• Time of ARP ping test: Facilitates matching with provider logs or CPE status.
• Packet capture result: Proves whether packets reach the Sophos Firewall at all.
• Checked DNAT and firewall rule: Prevents the case from being prematurely classified as a local rule problem. The MAC address of the WAN interface can be documented in the WebAdmin interface under Network > Interfaces. If the provider needs to clear an ARP cache or reload a CPE, it should be related to the specific IP or the affected interface. A blanket restart of all involved devices is only sensible if responsibility, maintenance window, and impact are clear.

Checklist

• Documented affected main and alias IP addresses.
• Checked interface, zone, gateway, and alias configuration.
• Checked NAT and firewall rules for the affected IP.
• Packet capture shows whether packets arrive at the WAN interface.
• ARP ping executed only with correct source IP, interface, and target IP.
• External accessibility tested again after each change.
• If necessary, contacted provider or upstream responsible parties with specific IP, MAC address, test time, and packet capture observation.

FAQ