VPN - need for NAT exemption

[matthewceroni]

This post is more of a knowledge question more than a something isn't working question. I am trying to understand the need for NAT exemption when passing traffic over a IPSEC VPN tunnel.

So the general setup for an ASA is to NAT all traffic going out the outside interface. This allows the internal network to access the internet. In articles I have read it says that for VPN traffic you need to NAT exempt that rule. From what I have read on that is it because you can't modify the ESP header without breaking IPSEC. That all seemed to make sense to me (the flow would be the packet would be encapsulated in IPSEC headers and then the NAT rule would try to be applied, and it would fail).

However I was looking at a setup of an older ASA we have that has a fair amount of IPSEC tunnels. Instead of NAT exempting the traffic there is a Dynamic Policy NAT setup. What this effectively does it make all traffic on side B of the IPsec tunnel appear as if it is coming from one IP address. This is done as we have a lot of VPN tunnels with customers and we don't want to conflict with IPs on their network.

So my question is why in this case does the NAT work? Is it that this rule takes place before the traffic is encapsulated via IPSEC? Whereas the rule that NATs all internet bound traffic happens after it is encapsulated? Would anyone be able to point me in the direction of a flow chart that shows when certain actions take place on an ASA?

Thanks in advance

[Jouni Forss]

Hi,

I would say that the command "packet-tracer" is your best friend if you want to look at what operations and in what order the ASA does to the traffic. You can also do this through the graphical user interface ASDM if you dont want to use the CLI.

With regards to the NAT and VPN, the NAT is always done BEFORE the traffic gets matched to the VPN configurations.

So lets say you have the following ACL to match the L2L VPN traffic

access-list CRYPTOMAP permit ip 10.10.10.0 255.255.255.0 192.168.10.0 255.255.255.0

And the following NAT configurations

global (outside) 1 interface

nat (inside) 1 10.10.10.0 255.255.255.0

This would result in a situation where your traffic from 10.10.10.0/24 towards 192.168.10.0/24 would first get PATed to the "outside" interface IP address and therefore wouldnt match the L2L VPN rules.

If you added the configuration

access-list INSIDE-NAT0 permit ip 10.10.10.0 255.255.255.0 192.168.10.0 255.255.255.0

nat (inside) 0 access-list INSIDE-NAT0

Then the NO NAT would be done and the traffic would match the L2L VPN ACL and get forwarded to the VPN connection

Alternatively if you changed the L2L VPN ACL to

access-list CRYPTOMAP permit ip host 192.168.10.0 255.255.255.0

And the remote site would do the same in mirror image the L2L VPN would work just fine and traffic would match the L2L VPN even after the NAT.

Here is an example of the "packet-tracer" command on my own ASA. Though this is for a newer software with different NAT format (source and destination NAT supported in same NAT configuration line). Also the ACL vs. NAT processing has changed order.

ASA# packet-tracer input LAN tcp 10.0.0.10 12345 10.10.10.100 3389

Phase: 1

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   0.0.0.0         0.0.0.0         WAN

Phase: 2

Type: UN-NAT

Subtype: static

Result: ALLOW

Config:

nat (LAN,WAN) source static LAN LAN destination static REMOTE REMOTE no-proxy-arp route-lookup

Additional Information:

NAT divert to egress interface WAN

Untranslate 10.10.10.100/3389 to 10.10.10.100/3389

Phase: 3

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   10.0.0.0        255.255.255.0   LAN

Phase: 4

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 5

Type: NAT

Subtype:

Result: ALLOW

Config:

nat (LAN,WAN) source static LAN LAN destination static REMOTE REMOTE no-proxy-arp route-lookup

Additional Information:

Static translate 10.0.0.10/12345 to 10.0.0.10/12345

Phase: 6

Type: HOST-LIMIT

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 7

Type: VPN

Subtype: encrypt

Result: DROP

Config:

Additional Information:

Result:

input-interface: LAN

input-status: up

input-line-status: up

output-interface: WAN

output-status: up

output-line-status: up

Action: drop

Drop-reason: (acl-drop) Flow is denied by configured rule

As you can see the VPN Phase comes after all the NAT and ACL checks of the ASA.

- Jouni