ASA 8.4(3)+, NAT Behavior, and Remote Access VPN

I upgraded from 8.3(1) to 8.4(3) and all seemed well until someone mentioned that no one could make connections from the inside network to the VPN client pool addresses. When I trace the TCP SYN connections and look at the frame headers, I can see that the initial packet goes to the ASA inside interface, then the ASA forwards it to an internal router that it has a static route for for the internal net space ... and the router punts it back to the ASA because it has a route to it for the VPN pool address ... and so on until the TTL expires. I don't think this was the case prior to the upgrade.

Opened a TAC but haven't resolved it yet. Wanted to see if anyone had the same experience. The remote access users can connect to internal nets fine, it's just figuring out how to get connections initiated from the inside to work.

After some research, I'm guessing it has something to do with how the ASA gives precedence to NAT rules over its routing table starting with 8.4(2):

http://packetpushers.net/understanding-when-a-cisco-asa-nat-rule-can-override-the-asa-routing-table/

Thoughts? I'm not planning to post a config here or anything, but just as a general question.

Find more posts tagged with

Comments

xXErebuS

Are these twice NAT statements then yes.... it will essentially route the packet to the interface associated with the NAT translation... for example....

DMZ 1 contains a 10.10.10.0/24 network that gets nat'd to 192.168.73.0/24 to your inside clients
DMZ 2 contains a 10.10.10.0/24 network that is nat'd to 192.168.74.0/24 to your inside clients

Your twice NAT statements do not have ROUTE LOOKUP command....

Packet destined to 192.168.73.24 gets destination translated to 10.10.10.X send to DMZ 1 Egress and looks for a route statement that says 10.10.10.0/24

Packet destined to 192.168.74.24 gets destination translated to 10.10.10.x send to DMZ 2 Egress and looks for a route statement that says 10.10.10.0/24

192.168.72.0/24 is the DMZ 1 link so you would have a route statement that says something like:

route 1 10.10.10.0 255.255.255.0 192.168.72.X 1

Now here comes the tricky part - DMZ 2 link is 192.168.75.0/24 so you need another statement that says pretty much the same thing:

route 2 10.10.10.0 255.255.255.0 192.168.75.X 1.... but it wont let you so what you need to do is make it a secondary:

route 1 10.10.10.0 255.255.255.0 192.168.72.X 1
route 2 10.10.10.0 255.255.255.0 192.168.75.X 2

I was lucky enough when I upgraded that the "biggest" network DMZ interface was all 100% nat'd so I literally put

route 1 0.0.0.0 0.0.0.0 PUBLIC IP 1
route 2 0.0.0.0 0.0.0.0 DMZ NEXT HOP 2

Hope this makes sense

wintermute000

If only Cisco allowed VTI tunnels on ASAs like IOS it would make the routing and NAT a heck of a lot clearer.
It seems like the best feature and routing/NAT flexibility comes with IOS but for raw grunt you need an ASA. (exhibit 1: DMVPN)

xXErebuS

wintermute000 wrote: »

If only Cisco allowed VTI tunnels on ASAs like IOS it would make the routing and NAT a heck of a lot clearer.
It seems like the best feature and routing/NAT flexibility comes with IOS but for raw grunt you need an ASA. (exhibit 1: DMVPN)

I think its more clear now; your routing what internally is REAL to REAL basically...

cisco_trooper

Yeah, the new syntax is actually better once you get used to it. Using the pre-8.3 configurations with ACLs all over the place was a retarded way to do it. It is much better now that you don't have to track down ACLs for such simple configuration requirements.