Posted on Friday, 1st April 2005 by sean
I’ve done a bit of work on NAT lately:
I’m just going to finish up with the use of a route-map in NAT instead of the traditional access-list.
As an administrative note, while adding new contact information on the lower right (Skype and AIM), I noticed that my email address had the wrong domain. Silly me. If you emailed me before and I didn’t get back to you, my sincere apologies.
Again, using the following network for testing:
The first situation is using route-maps to allow multiple access-lists to be used.
access-list 101 permit tcp any any access-list 102 permit icmp any any ! route-map natmebaby permit 10 match ip address 101 ! route-map natmebaby permit 20 match ip address 102
This route-map permits tcp and icmp, but in separate clauses. Now, to create a pool and do the NAT:
ip nat pool mypool 192.168.1.64 192.168.1.69 prefix-length 24 ip nat inside source route-map natmebaby pool mypool
This creates a pool from 192.168.1.64 to .69, and NATs anything matching the natmebaby route-map (TCP and ICMP traffic).
From r1, I initiated a telnet connection to Bob on port 22, and also pinged it. On R0 I then saw:
r1# r0#show ip nat trans Pro Inside global Inside local Outside local Outside global tcp 192.168.1.64:11000 192.168.15.2:11000 192.168.1.10:22 192.168.1.10:22 icmp 192.168.1.64:7720 192.168.15.2:7720 192.168.1.10:7720 192.168.1.10:7720 icmp 192.168.1.64:7721 192.168.15.2:7721 192.168.1.10:7721 192.168.1.10:7721 icmp 192.168.1.64:7722 192.168.15.2:7722 192.168.1.10:7722 192.168.1.10:7722 icmp 192.168.1.64:7723 192.168.15.2:7723 192.168.1.10:7723 192.168.1.10:7723 icmp 192.168.1.64:7724 192.168.15.2:7724 192.168.1.10:7724 192.168.1.10:7724
Trying it the traditional way:
access-list 103 permit ip any any no ip nat inside source route-map natmebaby pool mypool ip nat inside source list 103 pool mypool ... telnet and ping from r1 ... r0#show ip nat translations Pro Inside global Inside local Outside local Outside global --- 192.168.1.65 192.168.15.2 --- ---
Here, the traditional method only creates one translation entry for all connections, while using a route-map gives more detail.
Since the route-map method generates multiple translation entries, it can be used when there are multiple outside interfaces. NAT Support for Multiple Pools Using Route Maps describes the problem well. If you have two NAT pools and are using multiple ip nat inside source list commands, the first translation will stick, and if another flow uses the other interface, the wrong address will be used.
route-maps ensure that the decision of the source address to translate to is done on a per flow basis rather than once.
Another interesting use is route -maps and static NAT, where the set ip next-hop action is used in the route-map. For now, I won’t lab it up, but it’s an interesting read.