TravelingPacket – A blog of network musings

I thought I would blog on this. It could be useful for someone who might have an IOS router instead of an ASA and need to create a IPSEC Site-to-Site VPN to a remote peer, then NAT VPN traffic to a different address or subnet if needed, or the local subnets conflict with each other.

Here is a nice little Visio to kind of show what I am going for with the traffic:

Because of duplicate subnets on both sides, I need to nat traffic going to 172.90.0.20 from 192.168.10.10, otherwise traffic should flow normally. How can I achieve conditional nat? By using a route-map and then natting only the traffic in the Route-map. So, lets get our VPN setup first. Remember, we add the NAT network or host IP to our interesting traffic ACL that will be used to define our Phase2

These are my commands:

ip access-list extended VPN-to-Remote
 permit ip host 10.255.232.10 host 172.20.0.192

crypto isakmp policy 50
 encr 3des
 authentication pre-share
 group 2
 lifetime 28800

crypto isakmp key … address 1.1.1.1 no-xauth

crypto ipsec transform-set Transform esp-3des esp-sha-hmac

crypto map Crypto 6 ipsec-isakmp
 set peer 1.1.1.1
 set transform-set Transform
 match address VPN-to-Remote

That pretty much gets the VPN up and going. Now for the interesting part – we need to create a new ACL, match my private 192.168.10.10 address and the destination address of the remote server, then match that ACL in my Route-map.

ip access-list extended Nat-for-VPN
 permit ip host 192.168.10.10 host 172.20.0.192

route-map VPN-to-REMOTE permit 10
 match ip address Nat-for-VPN
!

Great! So, we now have the route-map created.. so now what? We need to create a NAT statement that references my Route-Map. Then of course with any VPN we need to modify the “NO-NAT” ACL to include the traffic for both the 192.168.10.10, and the 10.255.232.10 to my remote destination.

ip nat inside source static 192.168.10.10 10.255.232.10 route-map VPN-to-HCN extendable

ip access-list extended NO-NAT
 deny   ip host 10.255.232.10 host 172.20.0.192
 deny   ip host 192.168.10.10 host 172.20.0.192

Now, if we try to access the remote side, does it work? Yes it does, but lets check to see if our nat is really working. It is! As you can see, 192.168.10.10 going to 172.20.0.192 is being natted into 10.255.232.10, but all other traffic gets natted out of the WAN interface.

Lets just check for translations of 10.255.232.10

Bingo, everything works great. Lets make sure that we are getting hits on our Route-Map.