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.

Reference :

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- obj- destination static obj- obj-
nat (inside,outside) source static obj- obj- destination static obj- obj-

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 it looks through the NAT entries for a statement that contains a destination of 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

To resolve this you have 2 options :

  1. Either remove the (any,any) and define the actual mapped interface i.e (any, outside).
  2. Add the 'no-proxy-arp' command to the manual NAT rule containing (any,any), shown below,

nat (any,any) source static obj- obj- destination static obj- obj- no-proxy-arp

Additional Caveats

Theres more !


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).



Tags: ASA, Cisco, ProxyARP, NAT

About the Author


R Donato

Rick Donato is the Founder and Chief Editor of He currently works as a Principal Network Security Engineer and has a keen interest in automation and the cloud.

You can find Rick on Twitter @f3lix001