So my big plan was to simply configure the new ASA the same as the old with a few difference—namely the IPs assigned to the inside and outside interfaces. That way I could add the new ASA to the network, hanging off of our core switch just like the old one, and test that the config (L2L and IPSec VPN, NAT translation, routing, etc.) works. It'd look a little like this when I was done:
I tend to really, really dwell on things before I implement them though. Sometimes it's a bad thing, as in it takes me longer to complete a task, and other times it saves my bacon. This would be one of those times, because before I just threw the firewall on the network I stopped and thought, In what way could this backfire and cause disruption to the production network? More specifically I was wondering if there was any way that the new ASA would/could respond to requests meant for the old ASA. That's when I began to think about proxy arp, and developed a splitting headache (totally coincidental, I'm sure). I popped onto the Cisco support forums to craft a lengthy post, and when I didn't get responses fast enough for my liking I went to the Cisco IRC channel and asked. I got the following replies:
Random1: never use proxy arp
Random2: turn it off
You win some, you lost some on IRC, amirite? I lost and got the IRC-equivalent of "Nick Burns, Your Company's Computer Guy". I tried to ask some clarifying questions and got radio silence so I went out and did a little more reading on my own. It's not a hard concept in the end, but few people seem to have the ability to clearly explain how it works and its implications, so I'm gonna try because I can do soooo much better. That was sarcasm.
Here's the rundown on proxy arp:
It exists on networking devices to allow them to pass traffic on to interfaces/networks other than the one on which the traffic was received. Confusing? Yeah, try reading about it on Cisco's site. Basically if for some reason your host at 192.168.1.10 wants to ARP for its destination host at 18.104.22.168 instead of the default gateway, the router would get that ARP and if it has an interface with a destination to the same network as 22.214.171.124 it would respond to the ARP request with its own MAC and forward it along.
ASAs do the same sort've thing, but instead of being based on a routing table it's based on NAT statements, whether static or dynamic, and aliases. In a lot of standard ASA configurations, especially for smaller businesses, you'll have an IP address on your outside interface that also servers as your global NAT address for internal IPs. This is a scenario in which you would need to have proxy arp enabled. I checked our existing ASA config with the show run all command and sure enough, we have disabled noproxyarp, which means proxy arp is enabled. That makes sense of course. We're doing a standard config and if we didn't have proxy arp on, we would not be able to pass traffic to any of our publicly accessible hosts (like web servers) and VPN wouldn't work either. Clearly the suggestion to "turn if off" was pretty short-sighted.
Now, this is not the case in every situation. If you're routing from your upstream to your ASA—say, your ISP is routing to your outside interface instead of ARPing—then you can turn proxy arp off. If your NATs live on a different network from the IP of your interface you can turn if off then as well. That's not the case in our house though.
What does this mean for me? It means my very simple plan is no longer so simple. I can turn off proxy arp and not put in any NAT statements on the new ASA and test that I can at least reach it from outside, but that won't help with the more complex scenarios such as testing NAT translation and routing to the internal network and across networks. I'm either going to have to configure it and pull the trigger, hoping it works, or figure something else out. Maybe time to check out GSN3 again?