What Is Proxy ARP?
Proxy ARP is where one host responds to an ARP request on behalf of another device. Typically this is done by a router.
The most common scenario is where a host on one network ARPs for a host on a remote network. The router detects this ARP and responds with its MAC address. This causes the host to associate the destination IP address with the MAC address of the router and to send the traffic with the destination IP address set to the end host and the destination MAC address set to that of the router. The router then forwards this traffic to the remote host.
The other common scenario has to do with firewalls and NAT. We’ll come back to this a bit later.
What Is The Difference Between Proxy ARP And A Default Gateway?
The difference is really in the client’s behavior and not the router. In some ways, the result looks similar, but it is different.
When using a default route the source host will determine if the destination is on the same network. Assuming it determines the destination is on a remote network it will ARP for the default gateway and populate its ARP table with the IP address and MAC address of the default gateway. It does not have an ARP entry for the destination address.
With proxy ARP the source host thinks the destination is on the same network and will send an ARP for the destination host. The router, acting as a proxy, will respond with an ARP reply. The source host then populates its ARP tabling mapping the destination IP address with the MAC address of the router.
How Does Proxy ARP work?
For proxy ARP to work, we need three things.
- A host is configured so it will ARP for remote destination IP Address.
- A device or router with Proxy ARP enabled on the interface facing the LAN where it will act as a proxy.
- The proxying device or router must have a route to the destination IP Address
For a host to ARP for an address, it needs to think the destination is one it can talk to directly. In other words, it must believe it is on the same subnet. To achieve this, the host needs to have the “wrong” netmask configured for the subnet it is connected to.
For example, if the host was configured with an IP address and netmask of 10.0.10.2/24 it will think that anything with an address starting with 10.0.10 is on the same network will attempt to talk to it directly. It will think that a host with an address of 10.0.20.5 is on a different network and instead of ARPing for it directly, it will instead ARP for its own default gateway.
If we change the configured netmask to 10.0.10.2/16, the host will think that any address starting with 10.0 is on the same network. The host will now ARP for 10.0.20.5 as it believes it can talk to it directly.
The second part of the equation is the router needs to be configured with proxy ARP and it must have a route towards the destination IP address. Continuing the example above, it would have proxy ARP enabled on the interface in the 10.0.10.x network, and it would need a route to the 10.0.20.5 device.
Why Do We Need Proxy ARP?
For the most part, proxy ARP is a holdover from the earlier days of networking. It was useful when host machines didn’t have any form of routing intelligence and couldn’t handle a default route. This scenario is less likely in modern networks, especially when we hand out network configuration with DHCP.
In most office or corporate environments, it is no longer used and usually turned off or disabled on the routers.
Firewalls, NAT, And Proxy ARP
There are some situations where Proxy ARP is used with firewalls and NAT.
This is required where the NAT addresses belong to the same subnet as one of the configured firewall interfaces.
Consider the following scenario
- A router and firewall share a link-net of 172.16.0.0/24
- The router has the .1 address and the firewall has the .2 address
- The firewall is NATing traffic destined to 172.16.0.10 onto an inside host address of 10.0.10.5. The NATed address belongs to the link-net subnet used between the router and the firewall.
When the router wants to send traffic to the NAT address of 172.16.0.10 it will ARP for the address because it believes it can talk to that host directly.
Since there is no device on that network with the configured address of 172.16.0.10 the router will not receive a response to its ARP query.
The firewall does not respond because its address is 172.16.0.2. Even though it is NATing the address of 172.16.0.10, that address isn’t configured on the firewall interface, so it won’t respond.
In this situation, the firewall needs to be configured with proxy ARP so that it will respond for the NAT address as well as its configured address. Now the router receives an ARP reply with the firewall’s MAC address, causing the router to have an ARP table entry of the destination address of 172.16.0.10 mapped to the firewall’s MAC address.
Note that there are other ways this NAT solution could be set up that would avoid the use of proxy ARP. Usually, a range of NAT addresses would be routed to the firewall, instead of using addresses from the link-net subnet. For example, the router could route the 172.16.20.0/24 network to the firewall, and the firewall could then use any of those addresses as the destination NAT.
Once again – it all depends on the situation and constraints as to what approach is best.
Proxy ARP Example
This example uses the following lab topology.
- Hosts 3 and 4 are connected to VLAN 10.
- Host 5 is connected to VLAN 20.
- Host 6 is connected to VLAN 30.
- vMX-1 is configured as the gateway for VLANs 10 and 20. It also has a route for VLAN 30 pointing to the CSR
- CSR-1 is configured as the gateway for VLAN 30 and has routes for VLANs 10 and 20.
Proxy ARP will be tested by pinging from Host 3 to Hosts 5 and 6.
Initial State
In this initial test, there is no proxy ARP configured on either vMX-1 or CSR-1. Hosts 4, 5, and 6 are configured with the correct subnet mask and have an appropriate default gateway set.
Host-3 is configured with the correct IP address and netmask but without a default gateway.
Host-3:
eve@Host-3:~$ ip route
10.0.0.0/24 dev ens3 proto kernel scope link src 10.0.0.24
10.0.10.0/28 dev ens4 proto kernel scope link src 10.0.10.12
eve@Host-3:~$ ping -c2 10.0.10.14
PING 10.0.10.14 (10.0.10.14) 56(84) bytes of data.
64 bytes from 10.0.10.14: icmp_seq=1 ttl=64 time=309 ms
64 bytes from 10.0.10.14: icmp_seq=2 ttl=64 time=106 ms
--- 10.0.10.14 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 106.195/207.811/309.427/101.616 ms
eve@Host-3:~$ ping -c2 10.0.20.5
ping: connect: Network is unreachable
eve@Host-3:~$ ping -c2 10.0.30.8
ping: connect: Network is unreachable
eve@Host-3:~$Since Host-3 does not have a route for 10.0.20.0/28 or 10.0.30.0/28 networks it is unable to ping Hosts 5 or 6.
Change Host-3’s Netmask
In this test, the Host-3 netmask has been changed. Instead of 10.0.10.12/28, it is now 10.0.10.12/16.
Host-3:
eve@Host-3:~$ ip route
10.0.0.0/24 dev ens3 proto kernel scope link src 10.0.0.24
10.0.0.0/16 dev ens4 proto kernel scope link src 10.0.10.12
eve@Host-3:~$ ping -c2 10.0.10.14
PING 10.0.10.14 (10.0.10.14) 56(84) bytes of data.
64 bytes from 10.0.10.14: icmp_seq=1 ttl=64 time=311 ms
64 bytes from 10.0.10.14: icmp_seq=2 ttl=64 time=106 ms
--- 10.0.10.14 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 106.478/208.690/310.903/102.212 ms
eve@Host-3:~$ ping -c2 10.0.20.5
PING 10.0.20.5 (10.0.20.5) 56(84) bytes of data.
From 10.0.10.12 icmp_seq=1 Destination Host Unreachable
From 10.0.10.12 icmp_seq=2 Destination Host Unreachable
--- 10.0.20.5 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1006ms
pipe 2
eve@Host-3:~$ ping -c2 10.0.30.8
PING 10.0.30.8 (10.0.30.8) 56(84) bytes of data.
From 10.0.10.12 icmp_seq=1 Destination Host Unreachable
From 10.0.10.12 icmp_seq=2 Destination Host Unreachable
--- 10.0.30.8 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1005ms
pipe 2
eve@Host-3:~$ arp -n -i ens4
Address HWtype HWaddress Flags Mask Iface
10.0.20.5 (incomplete) ens4
10.0.10.14 ether aa:bb:cc:00:10:14 C ens4
10.0.30.8 (incomplete) ens4
eve@Host-3:~$Due to the change in the netmask Host-3 now has a route to 10.0.0.0/16. This encompasses the addressing for Hosts 5 and 6, even though they are on a different network.
Host-3 now thinks Hosts 5 and 6 are on the same network and that it can talk to them directly. So it ARPs for their MAC addresses. It doesn’t receive any responses as those hosts are on a different network.
In the packet capture shown below you can see Host-3 (aa:bb:cc:00:10:12) sending ARPs for 10.0.20.5 and 10.0.30.8 and not receiving any responses.
Enabling Proxy ARP On vMX-1
Next, proxy ARP is enabled on vMX-1 on interface ge-0/0/0.10, its interface in VLAN 10.
Now we can repeat the test on Host-3 and see what happens with proxy ARP turned on.
Host-3:
eve@Host-3:~$ ip route
10.0.0.0/24 dev ens3 proto kernel scope link src 10.0.0.24
10.0.0.0/16 dev ens4 proto kernel scope link src 10.0.10.12
eve@Host-3:~$ ping -c2 10.0.10.14
PING 10.0.10.14 (10.0.10.14) 56(84) bytes of data.
64 bytes from 10.0.10.14: icmp_seq=1 ttl=64 time=309 ms
64 bytes from 10.0.10.14: icmp_seq=2 ttl=64 time=107 ms
--- 10.0.10.14 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 106.764/207.980/309.196/101.216 ms
eve@Host-3:~$ ping -c2 10.0.20.5
PING 10.0.20.5 (10.0.20.5) 56(84) bytes of data.
64 bytes from 10.0.20.5: icmp_seq=1 ttl=63 time=511 ms
64 bytes from 10.0.20.5: icmp_seq=2 ttl=63 time=368 ms
--- 10.0.20.5 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 368.187/439.358/510.529/71.171 ms
eve@Host-3:~$ ping -c2 10.0.30.8
PING 10.0.30.8 (10.0.30.8) 56(84) bytes of data.
64 bytes from 10.0.30.8: icmp_seq=1 ttl=62 time=565 ms
64 bytes from 10.0.30.8: icmp_seq=2 ttl=62 time=307 ms
--- 10.0.30.8 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 307.399/436.046/564.693/128.647 ms
eve@Host-3:~$ arp -n -i ens4
Address HWtype HWaddress Flags Mask Iface
10.0.20.5 ether aa:bb:cc:00:10:01 C ens4
10.0.10.14 ether aa:bb:cc:00:10:14 C ens4
10.0.30.8 ether aa:bb:cc:00:10:01 C ens4
10.0.10.1 ether aa:bb:cc:00:10:01 C ens4
eve@Host-3:~$This time Host-3 can ping all the hosts – 4, 5, and 6.
Note in the arp display that Hosts 5 and 6 (10.0.20.5 and 10.0.30.8) have the same hardware address as the router interface (10.0.10.1).
The packet capture below shows that Host-3 is again ARPing for Hosts 5 and 6. Due to proxy ARP, vMX-1 responds with its MAC address (aa:bb:cc:00:10:01).
Final Thoughts
Proxy ARP works by one device answering an ARP request for an IP address it does not have, but that it can reach.
In most networks, proxy ARP is disabled as there isn’t a need to use it.
There may be some situations when proxy ARP is still useful, but it should be considered a last resort, rather than your first choice option.