ASA Bi-directional (overlapping) NAT example configuration

VERSION 4  transparent
In some network situations (usually due to two different networks becoming interconnected) there might be a situation where there are overlapping IP subnets. If the ip duplication cannot be resolved by re-numbering one of the subnets, NAT is required to provide connectivity between them.

Consider the following example where the 10.10.10.0/24 network exists on both the inside and the outside interfaces of the firewall. The 10.10.10.0/24 network on the outside of the firewall is reachable via an IPSEC Lan-to-Lan tunnel:

bidirectional-NAT-example

In ASA version 8.3 and later, connectivity between the two subnets can be established by having the inside subnet reach the outside subnet by sending packets to the 10.10.30.0/24 network, and the outside subnet connect to the inside subnet by sending packets to the 10.10.20.0/24 subnet.

object network insideReal
  subnet 10.10.10.0 255.255.255.0
object network insideMapped
  subnet 10.10.20.0 255.255.255.0
object network outsideReal
  subnet 10.10.10.0 255.255.255.0
object network outsideMapped
  subnet 10.10.30.0 255.255.255.0

nat (inside,outside) source static insideReal insideMapped destination static outsideMapped outsideReal
And the packet-tracer output, showing a sample packet being translated and allowed through the ASA:
ASA83# packet-tracer input inside icmp  10.10.10.1 8 0  10.10.30.1
Phase: 3
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (inside,outside) source static insideReal insideMapped destination static outsideMapped outsideReal
Additional Information:
NAT divert to egress interface outside
Untranslate 10.10.30.1/0 to 10.10.10.1/0
Phase: 8
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (inside,outside) source static insideReal insideMapped destination static outsideMapped outsideReal
Additional Information:
Static translate 10.10.10.1/0 to 10.10.20.1/0
And the packet captures on the inside and outside interfaces showing the bidirectional translation, when the inside host 10.10.10.1 sends a packet to the outside mapped ip of 10.10.30.1:
ASA83# show cap
capture out type raw-data interface outside [Capturing – 260 bytes]
  match icmp any any
capture in type raw-data interface inside [Capturing – 260 bytes]
  match icmp any any
ASA83#         
ASA83#
ASA83# show cap in
 
2 packets captured
 
   1: 20:38:54.419640 10.10.10.1 > 10.10.30.1: icmp: echo request
   2: 20:38:54.421563 10.10.30.1 > 10.10.10.1: icmp: echo reply
2 packets shown
ASA83#
ASA83# show cap out
 
2 packets captured
 
   1: 20:38:54.419778 10.10.20.1 > 10.10.10.1: icmp: echo request
   2: 20:38:54.421548 10.10.10.1 > 10.10.20.1: icmp: echo reply
2 packets shown
ASA83#
ASA83#

Note that the ASA will need to have a route to not only the local LAN segment, but the remote LAN segment, and the ASA does not allow duplicate routing entries. To add this duplicate route, increase the metric for the route facing out the outside interface, which will satisfy the ASA requirement that the routes be different:

route inside 10.10.10.0 255.255.255.0 10.0.0.2 1
route outside 10.10.10.0 255.255.255.0 192.168.2.5 2

Both routes are valid and operational; remember, the ASA has the     concept of routes applied on a particular interface (that is why you     specify the interface nameif when you add the route statement).     Also, the NAT translations can override the routing table, which is key in this example.

With a NAT configuration like this, the NAT translations     override the global routing table, and will virtually forward the     packets destined to 10.10.20.x or 10.10.30.x to the egress interface first, without consulting the global routing table. Then, only the routes     associated with that interface the packet was forwarded to are used     to find the next hop.

If packets don’t match these translations, (when a “global” routing decision is needed) for a packet destined     to the 10.10.10.x network (a packet sourced from a DMZ for example,     that does not match either of these translations), the global routing table is consulted and the route with the lower metric will     always win, and in this case it will be routed to the inside     interface.

This “route-override” behavior of translations can be modified with the ‘route-override’ argument to manual NAT rules, see this documentation for more information (find in page for ‘route-override’):
http://www.cisco.com/en/US/docs/security/asa/asa84/configuration/guide/nat_rules.html

Leave a comment