I’m sure the new ASA NAT statements has confused a load of people. I myself is one of them. Today I encountered a problem with setting up a site to site VPN tunnel between two ASA using the 8.4 code. Site A & B.
On Site A I have one subnet and one inside interface. On site B, I have two sub-interfaces behind the ASA with two subnets. I had setup the tunnel correctly and was able to confirm both phase 1 and 2 are functioning.
Here’s the funny part. On Site B, I was able to reach the subnet behind site A without any issues using ping. I was unable to however ping/ssh/asdm the inside interface of site A, everything else works fine. This is despite having the statement “management-access interface” on both the ASAs.
From site A however, I was only able to reach one of the subnets. I was unable to reach the second subnet. I was also unable to ssh/asdm/ping the internal interfaces on this ASA via the tunnel.
This had me puzzled as I was observing packets being encrypted and decrypted across the tunnels properly. Upon checking the debug logs, I saw a weird entry “Routing failed to locate next-hop”. I thought this was strange, as I had all the routes on my ASA and the VPN tunnels didn’t require static routes. I also made sure I had the “reverse route” injection enabled.
After some long googling I found the problem! Apparently ASA 8.4 had introduced a new “route-lookup” keyword for identity nat.
You will need to add “route-lookup” to the end of your static identity NAT in order to bypassing NAT for the interface.
ASA's Management-Access Interface IP address is 192.168.1.1. ! Overlapping NAT statement: nat (inside,outside) source static obj-192.168.1.0 obj-192.168.1.0 destination static obj-vpn obj-vpn ! New Statement: nat (inside,outside) source static obj-192.168.1.0 obj-192.168.1.0 destination static obj-vpn obj-vpn route-lookup
For reference, you may refer to the bug reported here: