Check the ARP and NDP neighbor cache on Sophos Firewall

If a device is unreachable despite having the correct IP address, the firewall rule or route is not necessarily the problem. On the local network, Sophos Firewall also needs the destination’s correct MAC address. It stores this mapping in the neighbor cache.

Under Network > Neighbors (ARP–NDP), one can check which MAC address and interface are currently associated with an IP address. First, document the existing entry and compare it with the actual network setup. Flush and relearn the affected cache only if the mapping is stale.

⚠️ Flush clears the selected IPv4 or IPv6 cache, not just a single row. On a production firewall, record the current entry first, limit the scope of the test, and avoid flushing the cache during peak load.

What ARP, NDP, and the neighbor cache do

ARP maps an IPv4 address to a MAC address within the local Layer 2 segment. This means a directly reachable device, typically in the same VLAN. For IPv6, the Neighbor Discovery Protocol (NDP) performs this task using ICMPv6. The firewall needs this information before it can send a packet through a directly connected interface to the next neighbor.

Dynamically learned mappings remain in the cache for 600 seconds by default. They are then relearned when needed. A stale entry can occur after replacing a device or network adapter, or after moving a VM. A duplicate IP address, by contrast, can cause the displayed MAC address to change repeatedly.

The neighbor cache only covers directly reachable neighbors in the relevant Layer 2 segment. For a remote destination, the firewall stores the MAC address of the next router rather than that of the destination server.

This is not the same as Proxy ARP: in that case, the firewall answers an IPv4 ARP request for another destination address on an interface on its behalf. This special case is covered separately in Configure and test Proxy ARP on Sophos Firewall.

Check the neighbor cache first

1. Open Network > Neighbors (ARP–NDP).
2. Under Show, select IPv4 neighbor cache or IPv6 neighbor cache.
3. Search for the affected IP address.
4. Record the IP address, MAC address, and interface.
5. Under Static neighbor table, make sure there is no fixed but incorrect binding for the same IP address.
6. Compare the MAC address with the endpoint, hypervisor, switch, or next router.

The interface matters just as much as the MAC address. A correct IP-to-MAC mapping on the wrong port often indicates a VLAN, bridge, LAG, or cabling issue. The expected MAC address can usually be found in the endpoint’s network details, the switch’s MAC address table, or on the directly connected router. If the entry is missing entirely, send a targeted ping from the firewall to the affected IP address, then check the view again.

For IPv4, the current ARP table can also be displayed in the Device Console. After signing in through SSH or the console, open Option 4: Device Console and run:

system diagnostics utilities arp show

This is a read-only command. It is particularly useful when WebAdmin is unavailable or the mapping must be checked quickly during a test. For IPv6, the IPv6 neighbor cache view in WebAdmin remains the definitive place to check. Access is explained in Connect to Sophos Firewall using SSH.

Relearn a stale mapping safely

Flushing the cache is a diagnostic step, not a permanent fix. It also does not remove an incorrect static binding. If the same incorrect mapping returns, the underlying network problem remains.

1. Document the current IP address, MAC address, and interface.
2. Reproduce the issue with a single ping or connection attempt.
3. If a duplicate IP address or manipulation is suspected, capture the current state and a short packet capture first. Flushing immediately would remove this evidence.
4. Under Show, select the affected IPv4 or IPv6 cache.
5. Click Flush. This clears the selected cache.
6. Generate targeted traffic again from the affected device.
7. Check which MAC address and interface were relearned.
8. Retest the original service using the same source and destination.

For a controlled test from the Device Console, one can send four packets to a documented destination address, for example:

ping 192.0.2.10 count 4
ping6 2001:db8:10::10 count 4

These addresses are examples and must be replaced with the actual IPv4 or IPv6 destination. A successful ping only confirms basic reachability; the service that originally failed must still be tested afterwards.

Relearning can cause a brief delay. Reducing the timeout substantially across the board is rarely the best solution: the firewall then has to resolve neighbors more often, without fixing a duplicate IP address or an incorrect switch port.

If only a public IP address still does not move to the new firewall MAC address after the flush, the stale entry is probably held by the provider or an upstream router. Follow the separate procedure in Resolve ARP issues after a firewall migration.

Create a static neighbor only for fixed mappings

A static neighbor permanently binds an IP address to a MAC address and a physical interface. Only one such binding can exist per IP address. The firewall checks static entries before the dynamic cache and removes dynamic references for the same IP when the entry is saved. If the IP address, MAC address, or port changes later, connectivity can fail even though the endpoint itself is configured correctly.

Static entries are therefore suitable for stable systems, such as a permanently cabled infrastructure device with a fixed IP address. They are generally unsuitable for DHCP clients, mobile devices, HA or VM moves, and changing switch ports.

Under Network > Neighbors (ARP–NDP), open the Static neighbor table and select Add. Then configure the following values:

• IP version: Select IPv4 or IPv6.
• IPv4/IPv6 address: Enter the device’s fixed address.
• MAC address: Enter the actual MAC address of the device.
• Interface: Select the physical interface through which the neighbor is reachable.

A documented example could use 192.0.2.10, 02:00:00:00:00:10, and Port1. These values are placeholders and must all be replaced with the real IP address, MAC address, and port.

The option Add as a trusted MAC address to prevent a spoofing attempt also adds the IP-to-MAC mapping to the trusted MAC list. Enable it only when this protection strategy is being used deliberately, as a later VM, NIC, or port change may then appear as a legitimate conflict. Review Sophos Firewall spoof protection and DoS settings explains how these bindings interact with dynamic networks, DHCP, and virtualization.

After saving, test the specifically bound device. Also document who is responsible for updating the entry after a hardware, IP address, or port change. Without clear ownership, a static binding can later become an invisible source of errors.

Check possible neighbor poisoning attempts

A static binding defines the expected combination of IP address, MAC address, and interface. If the same IP appears with a different MAC address, or the same IP-to-MAC combination appears on another bound port, the firewall treats this as possible manipulation and does not update the cache with the conflicting mapping.

Under Network > Neighbors (ARP–NDP), enable Log possible neighbor poisoning attempts and save it with Apply. This option helps with diagnosis, but not every discrepancy should immediately be treated as an attack. A duplicate IP address, a replaced network adapter, a moved VM, or a port change can also cause a conflict.

Dropped IPv4 ARP packets can be displayed in the Device Console during a short test:

drop-packet-capture 'arp'

If there are many interfaces, restrict the output to a physical port:

drop-packet-capture interface Port1 'arp'

Port1 is an example and must be replaced with the affected interface. Reproduce the issue once, then stop the live output with Ctrl+C. The filter only shows dropped ARP packets and is not a permanent log archive. For IPv6 NDP or a general packet analysis, use Packet capture in WebAdmin and narrow the capture by source, destination, protocol, and interface.

Interpret common symptoms

• The destination remains unreachable after replacing a device or NIC: Compare the old MAC address with the newly learned value, flush the cache in a controlled manner, and test again.
• The MAC address changes repeatedly: Check for a duplicate IP address, DHCP lease, cloned VM, or HA behavior. A static entry would only hide the underlying conflict.
• The mapping appears on the wrong interface: Check the VLAN, bridge, LAG, switch port, and cabling.
• A statically bound device fails after network changes: Compare the IP address, MAC address, and physical port with the binding, then deliberately update or remove the entry.
• Only IPv6 is affected: Check the IPv6 neighbor cache, router advertisements, VLAN, and ICMPv6 path. An IPv4 ARP command provides no evidence for this case.
• Packets reach the firewall but the service still fails: Check the firewall rule, NAT, routing, and return path separately. The neighbor cache only proves local Layer 2 delivery.

Acceptance check

• Documented the affected IP address, expected MAC address, and interface.
• Checked the IPv4 or IPv6 cache before making a change.
• If necessary, flushed only the selected cache and generated targeted traffic.
• Compared the relearned mapping with the endpoint, switch, hypervisor, or router.
• Used a static binding only for a permanently stable IP-to-MAC-to-port mapping.
• Distinguished a poisoning warning from a duplicate IP address, device replacement, and network changes.
• Retested the original service after the Layer 2 check.

FAQ