The ASA’s ARP Behavior

I think anyone who has dealt with the ASA has to admit that it sometimes doesn’t behave as they’d expect.  One of the more memorable times for me was when I used the alias command to do dns translation.  Unfortunately, I didn’t disable proxy arp on the applicable interface.  The technical result was that the ASA responded to ARP requests for the IP address specified as the internal address with the alias command.

Since this was important enough for me to use the alias command to work around dns the issue, it was important enough to cause me some grief.  This manifested itself by creating occasional access issues to this web server.  The problem was inconsistent and almost impossible to track down at a location that I worked at infrequently.

A little after I had report of this intermittent issue, I was working with an ASA in a lab environment to do some strange VPN configurations using a single interface.  I entered a broad static identity nat statement similar to the following example.

static (inside,inside) 0.0.0.0 0.0.0.0

After doing so, network stability was lost.  The instability was not immediate, nor did it only affect the ASA.  Back tracking my steps, I removed the command and stability was restored.  This was when it clicked for me.  The way the ASA deals with arp requests is based on a few factors.  The first is whether or not proxy arp has been disabled.  The default configuration on each interface is as follows.

no sysopt noproxyarp <intf>

So looking at this default command (only visible with “show run all”), it is an obvious double negative.  This is effectively saying that proxy arp is enabled (no noproxyarp = proxyarp).  So what is proxy arp?  What is proxy arp on an ASA might actually be a better question.  Proxy arp in a router allows the router to respond to arp requests on an interface when there is a route to the destination out another interface.  This often makes things automagically work even when there are configuration errors.  This, however, is not how proxy arp works in the ASA.

The purpose for proxy arp in the ASA allows it to respond to arp requests for addresses other than the interface address.  A router does this as well, but the ASA’s scope is not exactly the same.  The ASA often needs to respond to addresses other than the interface address.  Unlike a router, this need isn’t tied to the route table.  An ASA needs to respond to arp requests based on the addresses it is using with nat (static or dynamic).

For example, an interface might use 1.1.1.1/24.  In addition, it might use 1.1.1.2 with a static translation to represent an internal host.  In this case, the interface would need to respond to arp requests for 1.1.1.1 (normal arp) and 1.1.1.2 (proxy arp).  This is the difference in the view of proxy arp from the perspective of an ASA as opposed to a router.  The ASA responds based on the global, static and alias commands.  Routers respond based on the route table.

So when is proxy arp necessary on the ASA?  The answer to this is simple.  Proxy arp should be enabled when the address space of the interface and nat translations (global or static) are shared.  If the addresses used by the global and static commands are routed as opposed to shared, proxy arp can be disabled with the following command–sysopt noproxyarp <intf>

So how can we get ourselves into trouble?  More importantly how does the ASA actually work?  The first point that should be understood is that the ASA only responds to arp requests for the IP addresses assigned the interfaces if we have proxy arp disabled.  However, it is important to remember that the default is that proxy arp is enabled on all interfaces.

So when does the ASA respond to arp requests to IP addresses other than the interface address?  The first thing that I must reiterate is that all of these scenarios are without disabling proxy arp.  With that point being made, there are a few cases.  The first is with the global command.  If we issue the global command on an interface and specify an address or addresses, the ASA will respond to arp requests for all of the included addresses (as long as proxy arp has not been disabled).

//respond to arp requests for 2.2.2.2
global (outside) 1 2.2.2.2

//respond to arp requests for 3.3.3.3-3.3.3.5
global (outside) 2 3.3.3.3-3.3.3.5

In my experience, this works with the inside interface as well and it doesn’t even have to be associated with a relevant NAT statement.  It will even respond if we can figure out how to get the request to an address space that isn’t shared (you can test with secondary addressing on an upstream router).

The next example is when we have a static statement.

//respond to arp requests for 1.1.1.1 on outside
static (inside,outside) 1.1.1.1 192.168.1.1

//respond to 192.168.1.1 on inside
static (outside,inside) 192.168.1.1 1.1.1.1

//respond to arp requests for anything on inside (probably not good)
static (inside,inside) 0.0.0.0 0.0.0.0 netmask 0.0.0.0

The final command that causes the ASA to respond for arp requests to addresses other than the interface address is the “alias” command.  This command is used for dnat and dns translation.  Most of the documentation that recommend its use, correctly recommend disabling proxy arp.  If you fail to disable proxy arp, the following examples describe the behavior.

//responds to arp requests for 1.1.1.1 on outside
alias (outside) 1.1.1.1 2.2.2.2

//responds to all arp requests on inside
alias (inside) 0.0.0.0 0.0.0.0 netmask 0.0.0.0

The key with the alias command is to realize it will cause the interface that is indicated to respond to arp requests for any IP address that is specified immediately following the parenthesis.  Also keep in mind that the mask should be applied to this address.

The ASA is a really good firewalling appliance.  If you work with it enough, you will find a few things that are a bit counterintuitive.  However, if you struggle through these issues, you will begin to understand it at a new level.  This article outlined some of the scenarios that can change the arp behavior of the ASA.  If you know of any other scenarios or commands that affect the arp process, please comment them below.

About Paul Stewart, CCIE 26009 (Security)

Paul is a Network and Security Engineer, Trainer and Blogger who enjoys understanding how things really work. With over 15 years of experience in the technology industry, Paul has helped many organizations build, maintain and secure their networks and systems.
This entry was posted in CCIE Security, Certification, Security, Technology and tagged , , . Bookmark the permalink.

17 Responses to The ASA’s ARP Behavior

  1. Ryan J Alder says:

    I just had to post a thank you. We gave someone access to an ASA against our better judgement and all of a sudden internal LAN traffic broke because the ASA started arping for all the internal IPs that it had NAT entries for. We were tearing our hear out and googling all over the place and this is the only page I found that explained things.

    This was the line we needed:
    sysopt noproxyarp inside

    Simple command but took forever to find out about it. Problem solved! Thank You!

  2. Fahad says:

    Scenario is quite simple (ASA 8.2). 1 inside 1 outside. I created a static NAT for the outside hosts to be available to inside hosts. Now on the outside I have some servers connected to the same VLAN as of the outside network. Now I see a problem wherein the server in the outside are having intermittent issue communicating with themselves. Would it a possibility of a proxy ARP issue there?

    • Yes, if the outside IP address is shared with an actual IP address on a host. However, I’m struggling to think of a scenario that you would ever need to do that. If you want to prove or disprove it, Wireshark can help. Load it on one of the servers and make sure all of the IP communication is going to the appropriate host’s Mac address.

  3. John says:

    We are upgrading from an ASA5510 to an ASA5580. Right now all of our switches point to the internal IP on the 5510 with a static default route. I want to move the current internal IP from the 5510 to the 5580. When the IP address is changed on the 5580 will it send out a gratuitous arp so that the switches will update the MAC for the IP of the default route? As of right now I am planning of flushing the arp table for the interface the default gateway resides on on each switch. I would like to avoid this and make the cutover as seamless as possible.

    Thank you.

    • Wow, that’s quite an upgrade. To answer your question, I do believe it will send a gratuitous arp when the IP address changes. I just confirmed this behavior on my ASA5505 with 8.4(2). I saw the gratutious arps in Wireshark. The interesting thing is it only done this with the address change. Bouncing the interface didn’t produce this behavior. With that being said, I would always recommend you confirm it in your environment. I suspect that this will only work for the address specified on the interface (not global, nat, or statics that may respond to proxy arp requests).

      I also found another article that you might find interesting on this.
      https://supportforums.cisco.com/community/netpro/security/firewall/blog/2010/10/27/asapix-proxy-arp-vs-gratuitous-arp

      • John says:

        Awesome. I read through that article and completely missed the she mentioned that when an interface IP changed the ASA will send out a gratuitous arp.

        Thanks for testing that and the quick response.

  4. Guda says:

    Hi Paul,

    Great post. I’m facing a wierd scenario in which the unique NAT address space is routed on a different interface. Will the ASA proxy arp on the outside interface in this scenario? or Do we need a static arp entry on the outside interface?

    static (inside,outside) 2.2.2.3 192.168.1.1 netmask 255.255.255.255
    route inside 2.2.2.0 255.255.255.0 x.x.x.x

    • The commands you have listed will cause the outside interface to respond for requests to 2.2.2.3. That is the proxy-arp function in that context. All IP traffic sent to 2.2.2.3 will be sent to the inside address of 192.168.1.1. After entering that static, 192.168.1.1 will be represented on the outside as 2.2.2.3. In that case, I don’t see what the function of your route statement would be.

  5. Jeff says:

    Thanks Paul – great walkthrough. Solved our exact problem in 30 seconds.

  6. Stu Jordan says:

    Thanks Paul. Good read.

  7. Rafael Jimenez says:

    I have an ASA5505 with 8.4(5). Im using vlans (outside, inside, dmz) with the interfaces asociated to the respective vlan.
    The e0/0 and e0/1 are in the outside vlan (switchport access vlan ….). The e0/0 is connected to the isp modem. The e0/1 is connected to a linux server with a public ip in the same outsidenetwork. I have another linux server in the dmz interface (a static nat exist).
    The users in the inside network are able to reach the internet only if both servers are powered off. How can I check if this is a apr proxy issue?

  8. lancellot says:

    Hi Paul,

    hope you could help me on this,

    scenario is that, I have static NAT for one of my internal host.

    e.g.

    outside = 5.5.5.5

    dmz = 1.1.1.1 and host is 1.1.1.2

    nat is static (1.1.1.2 ->192.168.1.1), now at this point sysopt proxyarp is enable

    and I cannot establish a connection to the internal host 1.1.1.2 from outside (192.168.1.1)

    I can see the syn arrives on the ASA, however if I disable the proxy-arp it works.

    reason for asking is, I would like to know why it works when disabling proxy-arp (but this should work if the proxy-arp was enabled, correct?)

    btw: this is on 8.4 version
    regards,
    Lancellot

  9. Bhavesh says:

    Very Good Article

  10. Dhruv says:

    Hi Paul, you mentioned in the article that Proxy ARP is not required if NAT IP used is not from the subnet used in the External Interface. Also Upstream router should have route for NAT IP address pointing towards ASA. What is the logic for the route ?

    Dhruv

Leave a Reply