We’ve discussed the use cases and role of traditional ARP in the prior article of this series. In this article we will discuss Proxy ARP and its role and significance.
Proxy ARP occurs when one node is responding to an ARP request on behalf of another node.
Proxy ARP is not a malicious event, it occurs to enable connectivity between two hosts that wouldn’t otherwise be possible.
Original Use Case
The original thought process for Proxy ARP was to accommodate hosts with misconfigured subnet masks.
As we’ve discussed before, when a host is speaking to another host on the same IP network, the target for the ARP request is the other host’s IP address. If a host is speaking to another host on a different IP network, the target for the ARP request will be the Default Gateway’s IP address.
The item which tells a host whether another IP address is on the same network or a different network is the subnet mask. This topology will illustrate how it works:
Host A is configured with the IP address
10.0.0.11 and a subnet mask of
/24 in CIDR). Host A will consider any IP address in the range of
10.0.0.255 on its local network.
Host B is configured with the IP address
10.0.0.22 and misconfigured with a subnet mask of
/16 in CIDR). Host B will consider any IP address in the range of
10.0.255.255 on its local network.
Presume both of these hosts are trying to speak to Host D, which exists on a different network and has the IP address
However, when Host B tries to speak to
10.0.4.44, it would (incorrectly) consider Host D on the same network and would instead try to ARP for Host D’s MAC address directly.
Host B’s ARP Request will be broadcast to the local network, but will never make it across the Router to Host D. Therefore, the ARP Request will go unanswered, and Host B will be unable to communicate with Host D.
Unless the Router itself responds to Host B’s ARP Request on behalf of Host D – which is the exact definition of a Proxy ARP.
Here is the process in action (Host A is not pictured):
The ARP Response sent by the Router looks exactly like a normal ARP response. Host B will use the response to create an ARP mapping that states the IP
10.0.4.44 maps to the MAC address
0053.ffff.9999. All subsequent packets sent to Host D will use this MAC address in the L2 header.
So despite the misconfigured Subnet Mask, Host B will be able to speak to Host D, due to the Router’s heroic use of Proxy ARP.
That being said, it does impose additional work load on the Router. We used the specific example of Host D’s single IP address, but due to Host B’s misconfigured subnet mask there are roughly 65,000 IP addresses that Host B now considers on its local network. When in reality only about 250 could possibly exist on its local network.
So while Proxy ARP enabled connectivity in this example, it unfortunately does not scale indefinitely and should not be relied upon. The long term solution is to correct the misconfigured Subnet mask on Host B.
Moreover, this specific use case for Proxy ARP is based solely around enabling routing despite there being a misconfiguration. With Proxy ARP, Host B may never even realize it has an incorrect Subnet Mask.
There is another school of thought that instead would prefer Host B’s misconfiguration to cause the communication to fail in order for Host B to be notified that something is wrong. Thereby creating an opportunity for Host B to fix the root problem.
That said, there is a very important and legitimate use case for Proxy ARP — one which does not stem from a misconfiguration. We’ll take a look at it after exploring the Packet Structure for Proxy ARP next.
Proxy ARP Packet Structure
The ARP Request looks identical to the traditional ARP Request we looked at in the last article. In fact, it is a traditional ARP request, as the initiator of the ARP Request does not know whether the response will come in via proxy.
The Proxy ARP Response is slightly different, but has the same packet structure as the traditional ARP Response packet:
Notice the response is sent Unicast, directly from the Router’s MAC address to Host B’s MAC address.
The Opcode still contains the value
2, indicating an ARP response.
The crux of the Proxy ARP is in the Sender MAC and Sender IP address fields.
Notice, the Sender MAC address is the Router’s MAC address, but the Sender’s IP address is Host D’s IP address. The Router is providing its own MAC address as the owner for another hosts IP address, hence responding to the ARP on behalf of Host D.
Finally, the Target MAC and Target IP address fields, as expected, contain the information correlating to Host B, which is the intended recipient of this ARP Response.
Proxy ARP in Network Address Translation
Earlier we discussed Proxy ARP and its use case for routing for misconfigured hosts. Of course, that use case all but disappears if every host is configured properly.
However, there is a very legitimate and necessary use case for Proxy ARP, and that has to do with Network Address Translation, or NAT.
We will use this topology to describe it:
Our Firewall has the IP address
18.104.22.168 in the
22.214.171.124/24 network. Our Firewall is also configured with a Static NAT that translates the IP address
10.3.4.55. These IP addresses belong to Host Y, with the IP address
10.3.4.55. Host X is simply some host on the other side of the Internet, using the IP
If Host X sends a packet to Host Y, that packet will have a Source IP of
126.96.36.199 and a Destination IP of
188.8.131.52. Routing will take that packet across the internet until it finally arrives at Router C.
Router C now needs to deliver a packet that is destined to a network it is directly attached to (
184.108.40.206/24). Router C initiates an ARP Request to determine the MAC address which owns the IP address
But the device which owns that IP address is Host Y, which is not in the same network as Router C. So Host Y would be unable to respond to this query.
The Firewall, however, having been configured to translate packets from
10.3.4.55, knows it must receive the packets destined to
220.127.116.11 so that it can translate them and deliver them to Host Y.
Therefore, the Firewall will use Proxy ARP to respond to Router C’s ARP Request for the
18.104.22.168 IP address on behalf of Host Y.
The entire process is illustrated in this animation:
If not for the Firewall participating in Proxy ARP, the Network Address Translation would fail, since packets sent from Router C would never arrive to the Firewall.
Hence, for Network Address Translation to work properly, the translation device must use Proxy ARP to properly receive packets to be translated.
As demonstrated, any NAT deployment will require the use of Proxy ARP to properly receive packets which must be translated.