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 –> 126.96.36.199 for example
NAT Translation for store to global IP:
ip nat pool SNAT-STORES 188.8.131.52 184.108.40.206 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 🙂
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
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 🙂