I recently upgraded a customer ASA from v8.2 to 9.0 and while doing that I found out that some (yeah!) of the static NAT translations didn´t work after the upgrade. Skilled ASA-upgraders knows that this happens a lot. That´s why we (yes I hereby include myself in the ´skilled´-group) more often than not start our post-upgrade with a ´clear configure nat´and rebuild everything from scratch (and paper notes). I did the same this time, with the only different that some services wasn´t reachable after me finishing my work.
It took me a while to find out that the common thing with the non-working translations was that they were using one of the public subnets the ISP had assigned to the customer while all translations that used another public ip subnet worked flawlessly. I isolated the problem by changing IP of one of the nat-statements to another IP in the other range and it ofcourse worked!
So, what was this all about? I know from one of the late friday nights when I read the ‘ASA CLI configuration guide’ (it´s great, everyone should read it!) that Cisco recommends what when using multiple public ip ranges the ISP should route the secondary subnet to the ASA interface address.
But, I also know several customers that doesn´t follow these guidelines for historical reasons. Instead the ISP puts the second subnet as a secondary address on the interface facing the customer. And it has worked great, for years!
Until now. Thanks to a colleague I got aware of the fact that Cisco in version 8.4.3 made the ARP-behaviour of non-connected subnets more restricted. There was a command added ‘arp permit-nonconnected‘. This is documented here and here.
So, what is the recommendations? I recommend:
- If possible, do not use more than one subnet range of public ip addresses. If you do and it is because of a migration-from-one-range-to-another-has-stuck-halfways, please finish the work.
- Make sure that the ISP does not configure the ranges as secondaries (See above). If they need to change config, ask them to do it during a maintenance window and change the firewall configuration accordingly, at the same time.
- If the ISP uses secondaries, add the command ‘arp permit-nonconnected’ to the configuration.
Thanks a lot, it happens to me once during an upgrade and at the moment the only way i did it work was asking to the ISP to route the other segment. 🙂 glad i found you blog.
I have a situation where I have 2 ISPs, and a DMZ with a routed subnet of Public IPs on the secondary. Incoming connections to the DMZ server work, however all internet traffic from the DMZ server passes through the primary ISP. Is there a way to pass the traffic from the particular server through the secondary ISP?
Thanks – this worked for me.