Recently had a request where I needed to setup a IPSEC VPN tunnel (no problem) but NAT the internal traffic to a new range to go over the tunnel and for it not too interfere with the normal NAT Translation going out to the internet.

Bit of background information:

MPLS Network with over 100+ sites
Each site has a 192.168.X.X range (e.g. 192.168.22.X and 192.168.44.X)
Centralized HSRP Failover Cisco Firewalls on a 10.20.X.X range

Each site has a server on the .200 address so 192.168.22.200 and 192.168.44.200.

These servers needed to be NAT’d to a 10.60.0.X range to go over the VPN to 10.29.13.X/24

To keep things fairly tidy I kept the NAT translations in some sort of pattern so for example:

192.168.22.200 would become 10.60.0.22
192.168.44.200 would become 10.60.0.44

I created the tunnel and tested it using a loopback adapter on the routers with a 10.29.13.x address just to confirm the IPSEC tunnel is working successfully.

We have an IP range of 64 public address that had a NAT translation of all stores IP’s to 1 of them for easy management.

192.168.0.0 0.0.255.255 mapped to –> 2.2.2.60 for example

NAT Translation for store to global IP:

ip nat pool SNAT-STORES 2.2.2.60 2.2.2.60 netmask 255.255.255.192

ip nat inside source route-map SNAT-STORES pool SNAT-STORES mapping-id 101 overload

NOTE: mapping-id is for statefull NAT on the HSRP router pair ๐Ÿ™‚

Access-lists:

IP access list extended PBRNAT
permit ip 192.168.0.0 0.0.255.255 10.29.13.0 0.0.0.255

Access List PBRNAT is just to specify when the NAT translation should happen which is when any of the 192.168.0.0 addresses try to access the other side of the VPN (10.29.13.0/24). Note you need to use the original un-nat’d address in order to get the match.

IP access list extended SNAT-STORES
5 deny ip 192.168.0.0 0.0.255.255 10.29.13.0 0.0.0.255
10 permit ip 192.168.25.0 0.0.0.255 anyย 
20 permit ip 192.168.104.0 0.0.0.255 any
30 permit ip 192.168.107.0 0.0.0.255 any
40 permit ip 192.168.101.0 0.0.0.255 any
50 permit ip 192.168.105.0 0.0.0.255 any

Notice the deny statement under SNAT-STORES which is important as you need to set the criteria for when you want the NAT translation to be true. You do not want the global NAT translation to happen when trying to access the other side of the VPN (10.29.13.0/24).
Route maps needs to be created as they are used in the NAT translation rule and used for mapping to the access-lists.

route-map PBRNAT permit 10
match ip address PBRNAT

route-map SNAT-STORES permit 10
match ip address SNAT-STORES

Few of the NAT Translations

ip nat inside source static 192.168.112.200 10.60.0.112 route-map PBRNAT redundancy HSRP-Internal
ip nat inside source static 192.168.114.200 10.60.0.114 route-map PBRNAT redundancy HSRP-Internal
ip nat inside source static 192.168.115.200 10.60.0.115 route-map PBRNAT redundancy HSRP-Internal
ip nat inside source static 192.168.116.200 10.60.0.116 route-map PBRNAT redundancy HSRP-Internal
ip nat inside source static 192.168.117.200 10.60.0.117 route-map PBRNAT redundancy HSRP-Internal
ip nat inside source static 192.168.118.200 10.60.0.118 route-map PBRNAT redundancy HSRP-Internal

The interesting traffic for the VPN would be

permit ip 10.60.0.0 0.0.0.255 10.29.13.0 0.0.0.255

10.60.0.0 = Local Side (NAT’d addresses)
10.29.13.0 = Remote VPN Side

Just to show it working I pinged 10.29.13.21 from 192.168.22.200

VPNNAT-1
Primary Cisco Router showing the correct NAT Statement:

VPNNAT-2

Sorry if this appears to be a bit rushed I am off on holiday tomorrow and wanted to get done before I go while its still fresh ๐Ÿ™‚

 

Leave a Reply

Your email address will not be published. Required fields are marked *