Cisco ASA 8.4/8.6 - Proxy ARP Gotcha
You may observe the ASA incorrectly proxy ARPing for an IP address resulting in connectivity issues .
Within 8.4(2) and 8.6(1) the following NAT changes were introduced.This basically states that Proxy ARP is enabled by default on both static and identity based NAT statements.
Identity NAT configurable proxy ARP and route lookup
In earlier releases for identity NAT, proxy ARP was disabled, and a route lookup was always used to determine the egress interface. You could not configure these settings. In 8.4(2) and later, the default behavior for identity NAT was changed to match the behavior of other static NAT configurations: proxy ARP is enabled, and the NAT configuration determines the egress interface (if specified) by default. You can leave these settings as is, or you can enable or disable them discretely. Note that you can now also disable proxy ARP for regular static NAT.
For pre-8.3 configurations, the migration of NAT exempt rules (the nat 0 access-list command) to 8.4(2) and later now includes the following keywords to disable proxy ARP and to use a route lookup: no-proxy-arp and route-lookup. The unidirectional keyword that was used for migrating to 8.3(2) and 8.4(1) is no longer used for migration. When upgrading to 8.4(2) from 8.3(1), 8.3(2), and 8.4(1), all identity NAT configurations will now include the no-proxy-arp and route-lookup keywords, to maintain existing functionality. The unidirectional keyword is removed.
We modified the following commands: nat static [no-proxy-arp] [route-lookup] (object network) and nat source static [no-proxy-arp] [route-lookup] (global).
Note : Based on the above this gotcha may present itself after upgrading a ASA5500 series firewall from 8.2(x) and prior to 8.4(2).
It is also worth noting that Proxy ARP on a per interface basis is also enabled by default. This can be confirmed via running the command,
ciscoasa# sh run all sysopt | i proxy
no sysopt noproxyarp outside
no sysopt noproxyarp inside
no sysopt noproxyarp dmz
Cause / Solution
Lets look at an example. We have a NAT configuration, consisting of only 2 manual NAT rules,
nat (any,any) source static obj-192.168.1.3 obj-192.168.1.3 destination static obj-172.16.1.10 obj-172.16.1.10
nat (inside,outside) source static obj-192.168.1.10 obj-192.168.1.10 destination static obj-220.127.116.11 obj-18.104.22.168
The expected behavior is for the ASA to Proxy ARP for an IP address on its mapped interface. However based on the NAT statements above, at the point the ASA sees the ARP request for the MAC address for 192.168.1.3 it looks through the NAT entries for a statement that contains a destination of 192.168.1.3 on the mapped interface 'inside'.
However as (any,any) is being used within the first NAT rule, this NAT entry is hit resulting in the ASA proxy ARPing for 192.168.1.3.
To resolve this you have 2 options :
- Either remove the (any,any) and define the actual mapped interface i.e (any, outside).
- Add the 'no-proxy-arp' command to the manual NAT rule containing (any,any), shown below,
nat (any,any) source static obj-192.168.1.3 obj-192.168.1.3 destination static obj-172.16.1.10 obj-172.16.1.10 no-proxy-arp
Theres more !
MAC Learning CHANGE
To resolve the issues above CIsco introduced CSCuc11186 within a number of code versions, including 9.1(7). In short this changes the way that the ASA learns and populates its ARP cache. The ASA will refuse to populate its ARP cache should the NAT statement contain addresses that overlap with the external interface subnet. This typically occurs due to using 'any' objects.
This can be resolved by,
- adding 'no-proxy-arp' to your identity NAT statements.
- removing the use of 'any' based objects
MAC Learning Restored
Now the 'fix' above caused a lot of issues, which Cisco recognized. This resulted in the new behavior being removed (CSCuy28710) within 9.1(7.2), 9.2(4.7) and 9.4(2.7).