Configure and Test Proxy ARP on Sophos Firewall

Proxy ARP is only required on Sophos Firewall when a device in the directly connected IPv4 segment requests an additional destination address and the firewall must respond on its behalf with its MAC address. This can occur, for example, with an additional public IP that is then forwarded to an internal server using DNAT.

The important point is that Proxy ARP only solves neighbor resolution before the actual IP data path. It doesn’t create a firewall rule, NAT rule, or return route. Therefore, first use an ARP capture to confirm that this exact response is missing. Only then add a single Proxy ARP entry and test it together with the real service.

⚠️ Don’t enable Proxy ARP preemptively for an entire public address range. Before making the change, document the provider allocation, interface, original ARP state, backup, independent management access, and rollback. An incorrect or duplicate destination address can draw traffic to the wrong firewall.

Proxy ARP in eight steps

1. Ask the provider or upstream team whether the additional IPv4 address is requested by ARP on the WAN segment or routed to the firewall as a prefix.
2. Rule out that the address is already used as an alias, on another device, or by an existing design.
3. Capture ARP on the expected ingress interface while starting a new connection.
4. Continue only if the ARP request for the destination address arrives and the required response from the firewall is demonstrably missing.
5. In the Device Console, add an entry with set proxy-arp add for exactly one IPv4 address.
6. Configure or verify the firewall rule, DNAT or route, and return path separately.
7. Test the ARP reply, Firewall Rule ID, NAT Rule ID, and real service with a new connection.
8. Repeat the same test after an HA failover or during rollback, and remove the entry specifically with set proxy-arp del.

Distinguish Proxy ARP, aliases, and routing

What Proxy ARP actually does

Before an IPv4 device can send a packet to a neighbor on the same Layer 2 segment, it needs the neighbor’s MAC address. It sends an ARP request for this purpose. With Proxy ARP, Sophos Firewall answers such a request for another destination IP using the MAC address of its selected interface.

The upstream device then sends subsequent Ethernet frames to the firewall. Only after that do routing, NAT, and firewall rules decide what happens to the IP packet. A successful ARP reply therefore doesn’t yet prove that the published service works.

The Device Console command documented by Sophos applies to ARP and therefore to IPv4. IPv6 uses Neighbor Discovery for neighbor resolution. No Proxy NDP procedure can be inferred from this command.

Which option fits the provider allocation

• Alias IP: The additional address is bound locally to a physical firewall interface. This is suitable when the firewall must own the address or use it specifically for NAT or system traffic. Configure an alias IP on Sophos Firewall shows the complete procedure.
• Proxy ARP: The firewall responds on behalf of a forwarded or translated IPv4 address. This command doesn’t add the address as a normal interface address.
• Routed prefix: The upstream device routes an entire network to the WAN address or an agreed next hop. It then normally doesn’t send an ARP request on the WAN segment for every destination address in that prefix. A manual Proxy ARP entry would be the wrong fix.
• Static neighbor: This maps a directly reachable neighbor to a fixed MAC address. It is the opposite direction of view and isn’t a substitute for Proxy ARP. See Check the ARP and NDP neighbor cache for the distinction.

A DNAT rule also doesn’t automatically mean that manual Proxy ARP is required. Test the existing data path first. The CLI entry is only justified when the provider design and capture genuinely prove that the ARP reply is missing.

Example and replaceable values

The example uses a directly connected public IPv4 allocation. An HTTPS service must be reachable through the additional address 203.0.113.10:

• WAN interface: Port2
• WAN address of the firewall: 203.0.113.9/29
• Provider gateway: 203.0.113.14
• Additional public destination IP: 203.0.113.10
• External test host: 198.51.100.25
• Internal server: 10.20.40.20
• Service: HTTPS

203.0.113.0/24 and 198.51.100.0/24 are documentation networks. They don’t work as production addresses and must be replaced completely with the actual provider allocation and an authorized external test host. Port2 is also only an example; use the exact interface on which the ARP request demonstrably arrives.

The /29 mask isn’t used in the Proxy ARP command. It only explains the example network. The entry itself deliberately applies only to 203.0.113.10. Only answer for an entire range when ownership, use, and syntax are clearly documented for every address and tested on the deployed build.

Check the provider path and ARP before making changes

Before using the CLI, distinguish three possible findings:

1. No ARP request reaches the firewall: The provider path, VLAN, switch port, or assumption about the allocation must be resolved before the Proxy ARP step.
2. The request arrives and a device already responds: Don’t create a second reply. First identify the owner of the visible MAC address.
3. The request arrives, but no one responds: Only this finding is consistent with a missing Proxy ARP reply on the firewall.

For the capture, sign in using SSH or the local console and open Option 4: Device Console. Connect to Sophos Firewall using SSH explains access and the distinction between Device Console and Advanced Shell.

The following BPF filter is read-only and shows only ARP traffic for the example address:

tcpdump 'arp and host 203.0.113.10'

Then start a new connection to 203.0.113.10 from the authorized external test path. If the upstream device still has a cache entry, update only that entry using the router’s or provider’s documented method, or let it expire. Flushing all ARP caches or restarting a router is disproportionate for the initial diagnosis.

The interface, destination IP, and time in the capture must match the test. An ARP request on another VLAN or interface isn’t solved by an entry on Port2.

Add a single Proxy ARP entry

If the preliminary check is conclusive, add exactly the confirmed address in the Device Console:

set proxy-arp add interface Port2 dest_ip 203.0.113.10

The fixed parts are set proxy-arp add interface and dest_ip. Replace Port2 and 203.0.113.10 with the actual interface and the individually confirmed IPv4 address.

Sophos also documents dst_iprange, but the current help page doesn’t publish a complete, tested range example. Therefore, this article doesn’t guess a format. A single address is also the safer pilot for public ranges: it limits the impact and allows unambiguous positive and negative tests.

Immediately after the command, generate another fresh ARP request and repeat the capture. Expect a response with the MAC address of the intended firewall interface. If another MAC address responds or multiple responses appear, stop the rollout and resolve the address conflict first.

Implement the firewall rule, NAT, and return path separately

Proxy ARP draws the Ethernet frame to the firewall. The subsequent IP data path still needs its own technically appropriate configuration.

For the internal HTTPS server in the example, this includes:

• a narrow DNAT rule from 203.0.113.10:443 to 10.20.40.20:443;
• a matching firewall rule from the authorized WAN source to the server zone;
• logging during acceptance testing;
• a return path from the server through Sophos Firewall;
• loopback, if required, only as a separately planned internal use case.

Publish a server using DNAT covers rule position, Original Destination, destination zone, loopback, and protection features. NAT on Sophos Firewall explains SNAT, DNAT, MASQ, and PAT.

If the additional public address must be routed to a downstream system without DNAT, the firewall instead needs an unambiguous route and matching rules. Don’t hide an overlapping network behind a guessed static route or Proxy ARP range. The provider prefix, internal addressing, and return path must first be established as a coherent routing design.

Validate ARP and the real service

Acceptance testing consists of a Layer 2 check and an IP/application check:

1. Generate a fresh ARP request for 203.0.113.10.
2. In the capture, confirm the request on Port2 and exactly one reply with the expected firewall MAC address.
3. Open a new HTTPS connection from test host 198.51.100.25.
4. In Log viewer, verify the expected Firewall Rule ID and NAT Rule ID.
5. In the built-in Packet Capture, compare ingress on Port2 and egress toward the server.
6. On the server, confirm that the connection arrives and that the response returns through the firewall.
7. Test a disallowed port and an unauthorized source negatively.
8. If HA is used, test a new connection and a new ARP exchange after a controlled failover.

Success is only proven when both the ARP reply and the real service are correct. A ping isn’t enough: ICMP can intentionally be handled differently from HTTPS under Device Access or in the firewall rule. Packet Capture on Sophos Firewall explains filters, Status, Reason, Rule ID, and interface comparison; systematically test firewall rules covers complete rule acceptance.

Troubleshoot systematically

No ARP request arrives

Check the provider allocation, upstream routing, VLAN, switch port, and actual ingress interface. A local Proxy ARP entry can’t answer a request that never reaches the interface. With a routed prefix, the absence of an ARP request for the individual destination IP is even expected; check the route and next hop instead of Proxy ARP.

The ARP request arrives, but no reply leaves

Compare the destination IP and interface in the command with the capture. Then rule out that the interface changed, the address was mistyped, or the test ran from another Layer 2 segment. Don’t add a wider IP range to make an unclear single-address test appear to work.

If the documented entry on the confirmed interface still doesn’t respond, collect the firmware version, a short capture, and the exact topology for Sophos Support. Undocumented Advanced Shell changes to ARP or kernel parameters aren’t a safe standard step.

Multiple MAC addresses respond

Stop the test. Common causes are a duplicate IP address, an old device that is still active, an alias on a second firewall, or another Proxy ARP entry. Identify the owner of every MAC address and resolve the address conflict first. A firewall rule can’t correct competing ARP replies.

ARP is correct, but the service remains unreachable

Proxy ARP has already done its job. Next, verify the Firewall Rule ID, NAT Rule ID, rule order, destination zone, service, server gateway, and return path. Use a new connection so that an old session isn’t reused.

The address is briefly unreachable after replacement or HA failover

Check ARP and the real service again on the node active at the time of the event. The upstream device may still hold an old MAC mapping. Update only the affected entry in a controlled way first; resolve ARP issues after a firewall migration provides the complete process for old provider or router caches.

No uninterrupted continuation of existing connections is promised. What matters is a fresh ARP request, a new application session, and the logs of the node that actually processed the traffic.

Rollback and operation

Before removal, document which published address and service depend on the entry. During a maintenance window, remove the same single value with del:

set proxy-arp del interface Port2 dest_ip 203.0.113.10

Then generate a fresh ARP request. The firewall must no longer respond for this manual entry, provided that no alias, HA peer, or other legitimate mechanism serves the same address. Return dependent test rules and temporary NAT configuration to the documented previous state.

The entry belongs in the operations documentation because it isn’t visible as a normal interface address explaining why the firewall responds for the additional IP. After an interface redesign, replacement appliance, restore, firmware change, or HA test, verify the destination address, interface, ARP reply, and real service again.

Checklist

• Provider allocation and ARP rather than routing model confirmed.
• Destination IP demonstrably belongs to the organization and isn’t duplicated.
• ARP request arrives on the documented interface.
• Missing response proven by capture before the change.
• Only one pilot address entered using dest_ip.
• Firewall rule, NAT or route, and return path tested separately.
• Expected MAC address, Firewall Rule ID, and NAT Rule ID confirmed.
• Disallowed source and disallowed port tested negatively.
• HA failover or replacement path tested with a new connection.
• Exact del command and original state documented.

FAQ