Feb
20
2013

Using route maps for conditional NAT

As explained in a previous article, NAT is the process of modifying IP address information in IP packet headers, while route maps are mainly used to redistribute and manipulate routes (OSPF, BGP, EIGRP, and so on).

The question is obvious… What is the relationship between these two features?

Static NAT configuration with the route-map option can be used to implement destination-based NAT scenarios where the same inside local address needs to be translated to more than one inside global address, depending on where the traffic is destined.

How to define the conditional NAT? See you below:

Using-route-maps-for-conditional-NAT-main

Suppose that for several reasons (overlapping, reservation, …) the client source address (in SiteA) must be translated depending on the destination address. For instance:

When the client (172.16.0.5) on siteA tries to connect to the server Web (10.0.1.100), the source ip address will be translated in 172.16.100.5

Using-route-maps-for-conditional-NAT-siteB

 

When the client (172.16.0.5) on siteA tries to connect to the server SSH (192.168.2.100) the source ip address is translated in 172.16.200.5

Using-route-maps-for-conditional-NAT-siteC

 

Step #1: Define the interfaces:

interface FastEthernet0/1
 ip address 10.255.255.2 255.255.255.252
 ip nat outside

interface FastEthernet0/0
 ip address 172.16.0.1 255.255.255.0
 ip nat inside

Step #2: Define two ACL to identify two flows:

ip access-list extended client-serverweb
 permit ip host 172.16.0.5 host 10.0.1.100
ip access-list extended client-serverssh
 permit ip host 172.16.0.5 host 192.168.2.100

Step #3: Apply the ACL in the route maps:

route-map route-client-serverweb permit 10
 match ip address client-serverweb

route-map route-client-serverssh permit 10
 match ip address client-serverssh

To verify route maps:

Ciscozine#show route-map 
route-map route-client-serverssh, permit, sequence 10
  Match clauses:
    ip address (access-lists): client-serverssh 
  Set clauses:
  Policy routing matches: 0 packets, 0 bytes
route-map route-client-serverweb, permit, sequence 10
  Match clauses:
    ip address (access-lists): client-serverweb 
  Set clauses:
  Policy routing matches: 0 packets, 0 bytes
Ciscozine#

Step #4: Define the conditional NAT

ip nat inside source static 172.16.0.5 172.16.100.5 route-map route-client-serverweb
ip nat inside source static 172.16.0.5 172.16.200.5 route-map route-client-serverssh

How works these statements?

The first part ip nat inside source static 172.16.0.1 172.16.100.1 defines a static source NAT; the conditional NAT is made by the route-map route-client-serverweb.

The complete entry ip nat inside source static 172.16.0.5 172.16.100.5 route-map route-client-serverweb tell: translate the source ip address 172.16.0.5 to 172.16.100.1 only when the source ip address 172.16.0.5 tries to connect to the server web 10.0.1.100, otherwise does not translate the source ip address.

The same concept for the second entry.

Like ‘standard’ static source NAT, translation exists in the NAT translation table as soon as you configure static NAT command, and it remains in the translation table until you delete the static NAT command.

Ciscozine#sh ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
--- 172.16.100.5       172.16.0.5         ---                ---
--- 172.16.200.5       172.16.0.5         ---                ---
Ciscozine#

Note: Notice that for the same source ip (Inside local) there are different translations (Inside global)!

If the client makes some traffic:

Ciscozine#sh ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
icmp 172.16.100.5:22   172.16.0.5:22      10.0.1.100:22      10.0.1.100:22
icmp 172.16.200.5:23   172.16.0.5:23      192.168.2.100:23   192.168.2.100:23
tcp 172.16.200.5:22558 172.16.0.5:22558   192.168.2.100:22   192.168.2.100:22
tcp 172.16.100.5:33016 172.16.0.5:33016   10.0.1.100:80      10.0.1.100:80
--- 172.16.100.5       172.16.0.5         ---                ---
--- 172.16.200.5       172.16.0.5         ---                ---
Ciscozine#

the access-list will be matched:

Ciscozine#show ip access-lists
Extended IP access list client-serverssh
10 permit ip host 172.16.0.5 host 192.168.2.100 (3 matches)
Extended IP access list client-serverweb
10 permit ip host 172.16.0.5 host 10.0.1.100 (3 matches)
Ciscozine#

It is possible enable the debug ip nat detailed to analyze NAT:

Example #1: the client is connecting to the server web; the statement in the route map route-client-serverweb is matched and the nat occurs:

Feb 18 22:21:00.139: NAT: map match route-client-serverweb
Feb 18 22:21:00.139:  mapping pointer available mapping:0
Feb 18 22:21:00.139: NAT: New entry added to map hash table
Feb 18 22:21:00.139: NAT: i: tcp (172.16.0.5, 48516) -> (10.0.1.100, 80) [14216]     
Feb 18 22:21:00.139: NAT: s=172.16.0.5->172.16.100.1, d=10.0.1.100 [14216]
Feb 18 22:21:00.143: NAT*: o: tcp (10.0.1.100, 80) -> (172.16.100.1, 48516) [56566]
Feb 18 22:21:00.143: NAT*: s=10.0.1.100, d=172.16.100.1->172.16.0.5 [56566]
Feb 18 22:21:00.143: NAT: i: tcp (172.16.0.5, 48516) -> (10.0.1.100, 80) [14217]     
Feb 18 22:21:00.143: NAT: s=172.16.0.5->172.16.100.1, d=10.0.1.100 [14217]

Example #2: the client is connecting to the server ssh; the statements in the route map route-client-serverssh is matched and the nat occurs:

Feb 18 22:21:45.463: NAT: map match route-client-serverssh
Feb 18 22:21:45.463:  mapping pointer available mapping:0
Feb 18 22:21:45.463: NAT: New entry added to map hash table
Feb 18 22:21:45.463: NAT: i: tcp (172.16.0.5, 21500) -> (192.168.2.100, 22) [6272]     
Feb 18 22:21:45.463: NAT: s=172.16.0.5->172.16.200.1, d=192.168.2.100 [6272]
Feb 18 22:21:45.467: NAT*: o: tcp (192.168.2.100, 22) -> (172.16.200.1, 21500) [45025]
Feb 18 22:21:45.467: NAT*: s=192.168.2.100, d=172.16.200.1->172.16.0.5 [45025]
Feb 18 22:21:45.467: NAT: i: tcp (172.16.0.5, 21500) -> (192.168.2.100, 22) [6273]     
Feb 18 22:21:45.467: NAT: s=172.16.0.5->172.16.200.1, d=192.168.2.100 [6273]

Remember: These type of conditional NAT works will all “ip nat insice source” type (dynamic, PAT, …).

Summary
Article Name
Using route maps for conditional NAT
Description
Static NAT configuration with the route-map option can be used to implement destination-based NAT scenarios where the same inside local address needs to be translated to more than one inside global address, depending on where the traffic is destined.
Author
  • JK

    Great Article! Detailed and to-the-point at the same time!

  • Njofra

    Awesome!!!!

  • localhostrich

    Hi, can I implement Nat based on destination without route-map?
    For example:

    ip nat inside source list PingTest-Destination1 pool Destination1
    ip nat inside source list PingTest-Destination2 pool Destination2

    ip nat pool Destination1 10.10.10.10 10.10.10.10 prefix-length 24
    ip nat pool Destination2 10.10.10.20 10.10.10.20 prefix-length 24

    ip access-list extended PingTest-Destination1
    permit icmp host 172.16.1.1 host 192.168.0.1 echo

    ip access-list extended PingTest-Destination2
    permit icmp host 172.16.1.1 host 192.168.0.2 echo