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, …).

7 COMMENTS

  1. 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

  2. Dears ,

    how can i do this :

    i have a specific LANs (B1 ,B2 ,…etc) need to contact one server (A1) but must use a same one IP (B) to be able to contact the server , while they have to contact other servers (A2 ,A3 , etc) using their original IPs (B1 ,B2 ,…etc) .

    noting that there is only one router with only 1 LAN interface and 1 WAN interface (so all LANs will use the same WAN interface to reach the new server A1 and also to reach the other servers A2, A3 , …) .

    Conclusion : I need to apply NATing (actually it will be PAT) on some specific LANs while contacting a specific one destination only , otherwise no NAT is needed while contacting any other destination .

  3. Hey Fabio – Great article, not found anywhere I tried hard, not even at Cisco .
    Thanks a lot man..

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.