NATting for VPN traffic only

[James Dykes]

I have a client with an ASA 5505 who has several networks he's trying to get communicating over a VPN tunnel with a remote office. One of the networks is not working because it's also in use on the management interface of the other side of the tunnel and neither side seems willing to re-IP their internal space.

Their proposed solution is to NAT the conflicting network on the firewall on this side to a different subnet before passing it across the tunnel. How do I implement a NAT that only the VPN tunnel uses while keeping the rest of the traffic that comes across this device un-NATted?

The network in question is 192.168.0.0/24. Their desired NAT target is 172.16.0.0/24. ASA config is attached.

[anshubathla]

suggested Solution

1.Define any unsued network( neither used on you side nor in remote side.) and make a route for this new network towards outside interface.

2.And then define a dynamic Nat statement to convert your inside network to a single IP of unused nework which is defined in step 1

Illustrative eg

access-list vpn_nat extended permit ip 192.186.0.0 255.255.255.0 172.16.0.0 255.255.255.0

nat (inside) 6 access-list vpn_nat

   global (outside) 6

Also and very important that you have to change the encryption domain access-list source with the natted IP but for the particalur destination ie 172.16.0.0/16

Plesae review this carefully before implementing

[James Dykes]

Here are the rules I added to the firewall config:

global (outside) 6 172.16.0.254

nat (inside) 6 access-list vpn_nat

access-list vpn_nat extended permit ip 192.168.0.0 255.255.255.0 172.16.0.0 255.255.255.0

access-list outside_1_cryptomap_1 extended permit ip 172.16.0.0 255.255.255.0 10.1.7.0 255.255.255.0

access-list inside_nat0_outbound extended permit ip 172.16.0.0 255.255.255.0 10.1.7.0 255.255.255.0

Traffic from 192.168.0.0 is not being NATted before it hits the Phase 2 rules. What am I missing?

[rrockey]

Hi James,

You would have to change the VPN_NAT acl

access-list vpn_nat extended permit ip 192.168.0.0 255.255.255.0 172.16.0.0 255.255.255.0

to

access-list vpn_nat extended permit ip 192.168.0.0 255.255.255.0 10.1.7.0 255.255.255.0

because this the traffic you are plannign to NAT.

Also add the following:

no access-list inside_nat0_outbound extended permit ip 172.16.0.0 255.255.255.0 10.1.7.0 255.255.255.0

Let me know if it helepd.

Ronnie

[James Dykes]

I'm not seeing any hits on the vpn_nat ACL and traffic is still passing across the tunnel as 192.168.0.0 after making your recommended changes.

Thanks,

James

[Jouni Forss]

Hi,

If you still have these configurations

global (outside) 6 172.16.0.254

nat (inside) 6 access-list vpn_nat

access-list vpn_nat extended permit ip 192.168.0.0 255.255.255.0 10.1.7.0 255.255.255.0

access-list outside_1_cryptomap_1 extended permit ip 172.16.0.0 255.255.255.0 10.1.7.0 255.255.255.0

Then you will have to change the network mask of the source network in the NAT ACL

access-list vpn_nat extended permit ip 192.168.0.0 255.255.0.0 10.1.7.0 255.255.255.0

You have a /24 mask in the original. But you seem to have several 192.168.x.x/yy networks behind the ASA as seen by the "route" configuration lines

route inside 192.168.0.0 255.255.255.0 192.168.133.1 1

route inside 192.168.1.0 255.255.255.0 192.168.133.1 1

route inside 192.168.2.0 255.255.255.0 192.168.133.1 1

route inside 192.168.7.0 255.255.255.0 192.168.133.1 1

route inside 192.168.100.0 255.255.255.0 192.168.133.3 1

route inside 192.168.101.0 255.255.255.0 192.168.133.3 1

So you would need to define the source addresses for the VPN NAT as mask /16 to include all those /24 networks

- Jouni

[Jouni Forss]

Also one VERY important thing related to your NAT setup

You have several Static NAT statements towards the "outside" interface on your ASA

These WILL override the Dynamic Policy PAT configuration you mentioned. In other words they would apply to any "outside" bound traffic before the Dynamic Policy NAT and therefore not get forwarded to the L2L VPN.

IF ANY of the mentioned Static NAT configurations source hosts need to use the L2L VPN then you will HAVE to configure Static Policy NAT for them.

Even more, you will have to do it in this order

• Configure the Static Policy NAT
• Remove the original Static NAT
• Configure the original Static NAT again

The reason why it would be done like this is the fact that IF we leave the original Static NAT in place and configure Static Policy NAT, the original Static NAT will still be matches first because it was configured before the Static Policy NAT.

When you first configure the Static Policy NAT and then remove and add the original Static NAT, then the Static Policy NAT would be before the Static NAT in the configurations. Static Policy NAT would match for your VPN traffic first and rest of the traffic/connections would match the normal/original Static NAT configuration

Lets take one example of such a change.

Original Static NAT

static (inside,outside) XXX.XXX.133.49 192.168.133.49 netmask 255.255.255.255

Static Policy NAT

access-list STATIC-PNAT-192.168.133.49 permit ip host 192.168.133.49 10.1.7.0 255.255.255.0

static (inside,outside) 172.16.0.49 access-list STATIC-PNAT-192.168.133.49

Remove and Add the Original Static NAT

no static (inside,outside) XXX.XXX.133.49 192.168.133.49 netmask 255.255.255.255

static (inside,outside) XXX.XXX.133.49 192.168.133.49 netmask 255.255.255.255

This should enable the correct NAT operation for any of the hosts with Static NAT configurations. Hosts without Static NAT should be fine with the original Dynamic Policy PAT configuration.

Naturally if none of the Static NATed hosts need to access the L2L VPN Connection then you dont have to take these steps.

Hope this helps

Remember to mark the reply(s) as correct answer if they answered the question/solved the case.

Ask more if needed

- Jouni

[James Dykes]

Jouni:

The only network that needs to be NATted because of an IP conflict on the other side is 192.168.0.0/24. The other networks are working fine under the existing configuration.

Thanks,

James

[Jouni Forss]

Ah sorry, I was only looking at the previous posts and not the actual original post.

So I guess the remote site has NATed their 192.168.0.0/24 network to 10.1.7.0/24?

And you are NATing your 192.168.0.0/24 to 172.16.0.0/24?

Can you provide the current version of your configuration?

- Jouni

[James Dykes]

Our side has 192.168.0.0/24 as a subnet behind load balancers.

Their side has 192.168.0.0/24 on the admin interface of their Cisco.

So when we try to send VPN traffic over the tunnel from 192.168.0.0/24 to 10.1.7.0/24, it gets there fine, but we don't see traffic back because their firewall routes 192.168.0.0/24 to the admin port.

Neither side wants to re-IP.

The config is attached to the thread with the following additions:

global (outside) 6 172.16.0.254

nat (inside) 6 access-list vpn_nat

access-list vpn_nat extended permit ip 192.168.0.0 255.255.255.0 10.1.7.0 255.255.255.0

access-list outside_1_cryptomap_1 extended permit ip 172.16.0.0 255.255.255.0 10.1.7.0 255.255.255.0

Thanks,

James

[Jouni Forss · Accepted solution]

Hi,

Basically the Dynamic Policy PAT configuration should work for the L2L VPN connection because Dynamic Policy PAT is processed before Dynamic PAT/NAT configurations.

Only NAT configurations that can override this Dynamic Policy NAT are

• NAT0 / NAT Exempt configuration
• Static Policy NAT/PAT
• Static NAT/PAT

And since we determined that the the only problem is with the network 192.168.0.0/24 and since it has no Static NAT/PAT or Static Policy NAT/PAT configurations, then the Dynamic Policy PAT should be applied. Unless some NAT0 configuration still exists to cause problems.

The easiest way to determine which rules are being hit for a particular traffic is to use the "packet-tracer" command on the ASA

packet-tracer input inside tcp 192.168.0.100 12345 10.1.7.100 80

For example to simulate a random HTTP connection to the remote site

This should tell us for example

• Where the packet would be routed
• Would it pass the interface ACL
• What NAT would be applied to it
• Would it match any L2L VPN configuration
• and many more

So can you take an example output of the mentioned command twice and copy/paste the second output here. I ask to get the ouput twice because in the event that the actual L2L VPN negotiations would go through the first time issuing this command would only bring the L2L VPN up while the second command could already show complete information of what actually happened to the simulated packet.

Also, judging by the NAT format you have chosen (Dynamic Policy PAT), I presume that only your site is connecting to the remote site? Since Dynamic Policy PAT (or normal Dynamic PAT) doesnt enable bidirectional connection establishment. Connections can only be opened from your site to the remote site (naturally return traffic goes through automatically because of existing connections and translations)

- Jouni

[James Dykes]

I've got it working. There was a line in the original configuration no-NATting 192.168.0.0 traffic. Removing that line got it to pass the packet-tracer tests and the client has confirmed they're able to ping across the tunnel now.

Thanks,

James