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.
