Proxy ARP Explained

Lessons Discussion
61

Hello David

Proxy ARP is indeed often associated with poor or misconfigured network designs, as it can lead to various network issues such as broadcast storms and increased network traffic. However, it can also be useful in certain scenarios, such as when network devices are not in the same network but need to communicate as if they were. Sometimes the simplicity of implementation outweighs the negative impacts of security, especially in smaller networks.

As for Local Proxy ARP, it is a variation of Proxy ARP that works within the same network or VLAN. In a standard Proxy ARP situation, a router responds to ARP requests intended for another network, essentially “pretending” to be the destination host and then forwarding the traffic appropriately. With Local Proxy ARP, the router responds to ARP requests even if the hosts are on the same network. This can be useful in situations where hosts on the same network are not allowed to communicate directly for security reasons, such as when private VLANs are deployed.

I hope this has been helpful!

Laz

62

Hi Rene,
Slightly philosophical question - if it is (as it seems) really only useful in glossing over config errors (which feels like a BAD thing to do, why not find and fix the config errors instead?), why is it included as a default? Is this yet another of the ‘it’s like this because of history’ things? It seems incredibly marginal! It’s also just cost me a day of fiddling to find out what was going on with my MikroTik-to-Cisco dhcp relay which wasn’t working until I disabled proxy-arp… (given how much I learned from it I’m not actually feeling too grumpy :wink: )

63

Hello Hild

You bring up a great point. Proxy ARP, like many other features, is included as a default setting due to historical reasons and specific use-case scenarios. It’s not necessarily about glossing over config errors, but more about providing flexibility in the network by default.

Proxy ARP can be useful in situations where hosts are not on the same subnet but need to communicate as if they are. It can also be used in scenarios where routing is not possible for specific reasons.

However, as you’ve discovered, it can sometimes cause issues if it’s not properly understood or managed. In some cases, it can result in unnecessary ARP traffic, or even cause problems like the one you had with your MikroTik-to-Cisco DHCP relay.

So, while it’s included as a default, it’s not always the best option for every situation. It may have been more useful in the past, but in most modern networks, it shouldn’t really be necessary. It’s important to understand what it does and how it affects your network before deciding whether to use it or not.

I’m glad to hear that you learned a lot from this experience. That’s one of the great things about working in networking - there’s always something new to learn, and that is quite valuable.

I hope this has been helpful!

Laz

64

Recently, when I configured the firewall, my hosts in specific subnets were getting duplicated IP issue. After the investigation, I realized it should be caused by the proxy arp enabled for the nat rules, probably identity nat rules.

I did the research and read many articles but still confused about how proxy arp in nat rule will cause the duplicated IP issue.

For example, if i have the following identity nat rules:

nat (inside1, inside2) source static 10.70.10.0 10.70.10.0 destination static 10.70.20.0 10.70.20.0

nat (inside1, wan1) source static 10.70.10.0 10.70.10.0 destination static vpn_pool vpn_pool

How does proxy arp play in the nat rule? Firewall interface claims the source IP or destination IP hence resulted duplicated IP address?

If I add no-proxy-arp at the end, what is difference?

65

Hello Po

Let’s first see how proxy ARP works in the context of normal NAT. When you caonfigure a static NAT, the ASA may proxy ARP for the translated address on the connected interface. For example, if you map 192.168.1.10 to 203.0.113.10 on the OUTSIDE, the ASA will reply to ARP requests for 203.0.113.10 even though the real host doesn’t live there. This is done to make NAT operate transparently.

Now with identity NAT, the real and mapped addresses are the same. But it’s still NAT, so unless you tell it otherwise, it may perform Proxy ARP for that same IP address on the egress interface, where your duplicate IP problem comes in.

For your first NAT rule, identity NAT has been configured between two inside interfaces. ASA may start answering ARPs for the 10.70.10.X addresses on iside2, and for 10.70.20.x addresses on inside1. If real hosts already exist on those subnets, the ASA is essentially responding on their behalf “claiming” their IPs. From the network’s perspective, this appears to be two devices claiming the same IP address, one from the actual host, and another from the ASA.

For your second NAT rule, the same thing can occur. ASA may respond to ARPs on wan1 for addresses in 10.70.10.0/24 (or the vpn_pool range), even though those addresses are real hosts somewhere else.

The ASA is not smart enough to “know” that you are using NAT simply to exempt traffic (which is what Identity NAT is essentially used for). So to it, the static NAT rule looks like a mapping, so by default it says: “I’d better Proxy ARP for that mapped address on the egress interface so upstream devices can reach it.”

The result is that the ASA and the real host both claim ownership of the same IP by responding to the ARP request saying “hey, I have that address!”, resulting in a duplicate detection.

Now, if you append the no-proxy-arp keyword then the ASA will not respond to ARPs for those specific IPs in the NAT command. It doesn’t disable proxy ARP completely, but only for those specific addresses. Does that make sense?

I hope this has been helpful!

Laz

66

Hi Laz,

Thank you for your detailed explanation.

“For example, if you map 192.168.1.10 to 203.0.113.10 on the OUTSIDE, the ASA will reply to ARP requests for 203.0.113.10 even though the real host doesn’t live there.”

This is the part that confused me. Whether the proxy ARP happens on both interfaces and subnets or only for destination interface (bi-direction or uni-direction)?

nat (inside1, inside2) source static 10.70.10.0 10.70.10.0 destination 10.70.20.0 10.70.20.0

Will ASA reply to arp for inside1, inside2 or both interfaces?

As all my hosts in 10.79.20.0/24 were experiencing duplicated IP address issue, this make me think which nat rules should I add no proxy arp as there are many nat rules with 10.79.20.0/24 (inside2) interfaces. Should I add no proxy arp at source or destination interfaces which include inside2 interfaces?

For example, both source and destination interfaces have included inside2

nat (inside1, inside2) source static 10.70.10.0 10.70.10.0 destination 10.70.20.0 10.70.20.0

nat (inside2, wan) source static 10.70.10.0 10.70.10.0 destination ssl-vpn ssl-vpn

I’m not sure how to prevent this issue from happening again in future. Are identity nat rules with proxy arp the root cause? Should I ensure all identity nat rules are configured no-proxy-arp?

Why hosts in 10.79.10.0/24 subnet were not getting similar issue?

67

Hello Po

Hmm, I’m not quite sure what you mean. Each ARP request that takes place on a particular subnet, by default, has a scope within that subnet/network segment. ARPs are generated on interfaces of hosts looking for a particular MAC, and are received/processed on interfaces. Within a LAN segment/subnet that is connected to an ASA interface that has identity NAT enabled, both the host and the ASA interface will respond to ARP requests because of proxy ARP. So in a sense, it is bidirectional, keeping in mind both ARP requests and ARP replies.

If you don’t need proxy ARP to run on your network, then you can probably disable it completely and rely on routing to get the job done. At the very least, you can disable proxy ARP on all of the NAT rules that correspond to the subnet where duplicate addresses are seen, at least as a test to see if it resolves the problem.

Identity NAT in combination with proxy ARP is a common source of duplicate IP addresses on subnets served by an ASA device. I can’t be certain that this is the root cause, but it is very likely.

How is this inside interface different from the one where you see the problem? Compare the configs to see the reason behind the difference.

Let us know how you get along in your troubleshooting and if we can be of any further help!

I hope this has been helpful!

Laz