ASA VPN with Address Overlap

More and more, the Internet is being used as a connection to business partners. Typically this requires building an IPSec Tunnel between two VPN capable endpoints. For me the device of choice is the Cisco ASA. Since we are connecting to a business partner, we likely have no choice of device on the other end. Furthermore, since we are connecting to an already established network there could be issues with IP address overlap. In this article, we address the configuration of a VPN with IP address overlap. 

This article addresses both 8.2 and earlier configurations as well as 8.3 and 8.4 configurations. If you have a desire to get a deeper understanding of the changes in the 8.3/8.4 versions, I encourage you to compare the configuration to that of the more familiar 8.2. For this article, we will be solving the problem of building a VPN between our enterprise network and an outside business partner that has an overlapping 192.168.1.x/24 address space. The secure tunnel will be established between the two firewalls in the image below.

From the perspective of the business partner, our network will look like it is 192.168.2.x/24.  Therefore the ouside party doesn’t even need to know that we are using 192.168.1.x/24. To access the partner’s 192.168.1.x/24 network, we will send traffic to 192.168.3.x, where x is the host we desire to reach on their 192.168.1.x/24 network.

Since NAT has very different configuration syntax starting in 8.3, this article is broken into two sections.

Example of VPN with Overlapping addresses:

ASA 8.2 Syntax

ASA 8.3 and later Syntax


VPN with Overlapping Addresses (NAT 8.2 Syntax)

ciscoasa# show run
: Saved
:
ASA Version 8.2(1)
!
<snip for brevity>
!
interface Vlan1
  nameif inside
  security-level 100
  ip address 192.168.1.1 255.255.255.0
!
interface Vlan2
  nameif outside
  security-level 0
  ip address 1.1.1.2 255.255.255.0
!
interface Ethernet0/0
  switchport access vlan 2
!
<snip for brevity>
!
//crypto acl–attached to crypto map
access-list L2LAccessList extended permit ip 192.168.2.0 255.255.255.0 192.168.1.0 255.255.255.0
!
//policy nat acl–attached to static
access-list SRC_Translation extended permit ip 192.168.1.0 255.255.255.0 192.168.3.0 255.255.255.0
!
<snip for brevity>
!
global (outside) 1 interface
nat (inside) 1 0.0.0.0 0.0.0.0
!
//policy nat translation
//translates a source of
//192.168.1.x/24 to
//192.168.2.0/24 only when
//the destination is 192.168.3.0/24
static (inside,outside) 192.168.2.0 access-list SRC_Translation
!
//outbound packets going to
//192.168.3.0/24 should have
//the destination changed
//to 192.168.1.0/24
static (outside,inside) 192.168.3.0 192.168.1.0 netmask 255.255.255.0
!
route outside 0.0.0.0 0.0.0.0 1.1.1.1 1
!
<snip for brevity>
!
//vpn configuration
crypto ipsec transform-set myset esp-aes esp-sha-hmac
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4608000
crypto map mymap 10 match address L2LAccessList
crypto map mymap 10 set peer 1.1.1.1
crypto map mymap 10 set transform-set myset
crypto map mymap 10 set reverse-route
crypto map mymap interface outside
crypto isakmp enable outside
crypto isakmp policy 65535
authentication pre-share
encryption aes
hash sha
group 2
lifetime 86400
!
<snip for brevity>
!
tunnel-group 1.1.1.1 type ipsec-l2l
tunnel-group 1.1.1.1 ipsec-attributes
pre-shared-key cisco
!
class-map inspection_default
match default-inspection-traffic
!
!
<snip for brevity>
!

VPN with Overlapping Addresses (NAT 8.3 and later Syntax)

ciscoasa# show run
: Saved
:
ASA Version 8.4(2)
!
!
interface Ethernet0/0
  switchport access vlan 2
!
interface Ethernet0/1
!
!
interface Vlan1
  nameif inside
  security-level 100
  ip address 192.168.1.1 255.255.255.0
!
interface Vlan2
  nameif outside
  security-level 0
  ip address 1.1.1.2 255.255.255.0
!
!
//object groups to be used
//in nat configuration (below)
object network obj-192.168.1.0
  subnet 192.168.1.0 255.255.255.0
object network obj-192.168.2.0
  subnet 192.168.2.0 255.255.255.0
object network obj-192.168.3.0
  subnet 192.168.3.0 255.255.255.0
object network obj_any
  subnet 0.0.0.0 0.0.0.0
!
//crypto ACL
access-list L2LAccessList extended permit ip 192.168.2.0 255.255.255.0 192.168.1.0 255.255.255.0
!
//policy nat acl remnant of
//upgrade–no longer needed
access-list SRC_Translation extended permit ip 192.168.1.0 255.255.255.0 192.168.3.0 255.255.255.0
!
!
//policy nat translation
//translates a source of
//192.168.1.x/24 to
//192.168.2.0/24 only when
//the destination is 192.168.3.0/24
nat (inside,outside) source static obj-192.168.1.0 obj-192.168.2.0 destination static obj-192.168.3.0 obj-192.168.1.0
!
//translate destinations of
//192.168.3.0/24 to 192.168.1.0/24
//reference the objects above
object network obj-192.168.1.0
  nat (outside,inside) static 192.168.3.0
!
//PAT all other traffic to
//interface IP
object network obj_any
  nat (inside,outside) dynamic interface
route outside 0.0.0.0 0.0.0.0 1.1.1.1 1
!
!
!
//VPN Configuration
crypto ipsec ikev1 transform-set myset esp-aes esp-sha-hmac
crypto map mymap 10 match address L2LAccessList
crypto map mymap 10 set peer 1.1.1.1
crypto map mymap 10 set ikev1 transform-set myset
crypto map mymap 10 set reverse-route
crypto map mymap interface outside
crypto ikev1 enable outside
crypto ikev1 policy 65535
authentication pre-share
encryption aes
hash sha
group 2
lifetime 86400
!
!
tunnel-group 1.1.1.1 type ipsec-l2l
tunnel-group 1.1.1.1 ipsec-attributes
ikev1 pre-shared-key *****
!
!
: end
ciscoasa#

VPN configurations alone have many challenges. Layering on the additional challenges of overlapping addressing forces the understanding of the order of processing. This is required to correctly identify the traffic for encryption.  The examples above should serve as good starting points for anyone that needs to build a VPN and must deal with the challenges of overlapping networks.

About Paul Stewart, CCIE 26009 (Security)

Paul is a Network and Security Engineer, Trainer and Blogger who enjoys understanding how things really work. With over 15 years of experience in the technology industry, Paul has helped many organizations build, maintain and secure their networks and systems.
This entry was posted in Network, Security, Technology and tagged , , , , , . Bookmark the permalink.

42 Responses to ASA VPN with Address Overlap

  1. Keith Jones says:

    Paul, the recent articles you have posted on ASA configuration tips have been a tremendous help to me. We only install ASA firewalls for our clients, so a lot of these articles have been very helpful for future scenarios.

    This article brings about another question for me. The address conflict I run into the most is with a Remote VPN, where the user is at home, but their home Ip addressing is the same subnet as their office subnet, so usually 192.168.1.0 /24 on both ends. The remote VPN tunnels I typically set up direct the users local traffic to the LAN they are at (typically home or a hotel), and remote traffic through the VPN so that web browsing ect. is not directed through the tunnel.

    Is this able to be overcome in a similar manner?

    • That is a very good question. I actually may write an article about that particular issue in the future. In short, yes you can solve that problem in a similar way. The challenge is that the corporate network is then represented with a different IP address range. Therefore, everything either needs to know the translated addresses or use DNS (with DNS rewrite working properly). Do to these challenges, I try to avoid translating the corporate network for remote access clients.

      The way I try to solve this problem is inserting host routes for important IP addresses in the clients routing table. This can be done by exploiting split tunneling. Split tunneling is meant to define the protected networks and gives the administrator the ability to allow some traffic to go directly to the Internet. The way it works is that a split tunnel acl is built that includes hosts, networks, or even the default network (0.0.0.0 0.0.0.0) to be protected. If you don’t want users going directly to the Internet, include an instance of 0.0.0.0 0.0.0.0 in the standard acl. Then include any subnets and hosts. Including hosts using the syntax of “host x.x.x.x” of important ip addresses that are likely to overlap will cause the VPN client to insert host routes into the PC’s routing table. You can see this with “route print” from a command prompt in Windows.

      • Jim Thornton says:

        Great articles! I have a Site to Site connection set up and I am trying to connect to a server at the remote site using a Remote Access VPN connection into our local network. I configured a Standard ACL for an address at the remote site and it shows up when I establish a VPN client connection in the Route Print but I am not able to RDP to the server. I am able to RDP to the server when I am in the office. Any suggestions?

      • I worked on something similar to that a while back. In 8.2 and earlier, I think you need a “nat (outside) 0 access-list ACL”. The ACL should specify traffic in both directions (RA to L2L and L2L to RA). The L2L VPN would also need to match the remote access to remote L2L range in its ACL. You would also need to have the command “same-security-interface permit intra-interface” command. This is all from memory, so there may be a bit more to it than that. In any case, this is one of the more difficult configurations.

  2. Seppo says:

    Thanks for the great article. I have one question though. Scenario is this: customer have many L2L tunnels to business partners and of course there is overlapping networks between two partner’s. We made policy nat for the newest partner but now policy nat conflicts with static nat. There is bunch of servers mapped with static nat to public ip’s. Over the tunnel(to business partner) they can connect everything else but not to those servers. Is there anyway around this problem? (btw same problem is here with longer explanation: http://arstechnica.com/civis/viewtopic.php?f=10&t=1121735) I know that port forward will do the trick but that’s not the cure for our customer.

    • I know this is probably not what you want to hear, but in my case we have tried to nat everything to a non-RFC1918 that was owned by our customer. Then we only had to worry about destination overlap. I don’t know of an elegant solution to your problem. You could do something really ugly like policy nat it in a router before it gets to the ASA. Then you could use a completely separate set of translations in the firewall. Very ugly.

  3. Rod says:

    Hi, great article. Have a maybe stupid question though.. Is the configurations above made to the ASA of the inside network? And then I need to apply a mirrored config to the Business Partner ASA?

    • There’s no such thing as a stupid question. That is a good question. The nat configuration on the business partner ASA would depend on how the global addresses relate to their internal network. If they need changed as the enter and leave their network, they would need to configure their nat accordingly. The crypto logic on the ASA is on the outside of the ASA. therefore if the business partner is using an ASA, the crypto configuration will be a mirror image to the enterprise ASA.

  4. tarj says:

    Hello Sir

    my client using same ip on both sites. need to create tunnel between them, i saw this nat policy based which can help me to solve problem. but i am using one side ASA and other side router. then how i can do that.

    • If you are the one that controls the ASA, that is similar to what I explain here. I actually labbed this between an ASA and IOS device when I wrote this article. So the real question is which device needs to fix this–the ASA, router or both. That depends on what device you control and who wants to talk to a ‘fake’ ip destination. I need to do an IOS variant of this article soon.

  5. Drs says:

    Why is the following necessary ?
    object network obj-192.168.1.0
    nat (outside,inside) static 192.168.3.0

    Isn’t it covered by
    nat (inside,outside) source static obj-192.168.1.0 obj-192.168.2.0 destination static obj-192.168.3.0 obj-192.168.1.0

    • Jastreb says:

      I also agree it isn’t necessary because it’s already covered by previous nat command. Those commands should be removed.

  6. Alan says:

    Hi Paul

    If I had a restricted number of hosts that need to communicate with the remote site, that also has a restricted number of hosts, would policy nat be the best thing to use or should I just statically map [static (inside,outside)] ?

    • There’s a few ways that you can accomplish that. The decision to static nat or policy nat depends on if the translations need some qualifying value. For example, if HostA goes to a VPN, use IP address x.x.x.x. However, if same HostA goes to the internet, use IP address z.z.z.z.

      So for the context of static vs policy nat, I would think in those terms. In regards to only allowing some hosts, you can configure NAT based on this article. Then use ACLs to control the traffic. This could be done in the following locations–

      1) Ingress where the source hosts exists
      2) applied to the tunnel group with vpn-filter
      3) Ingress on the public interface on the remote end (with “no sysopt permit-vpn”)
      4) Egress on the interface where the destination hosts live

      You can also tightly restrict the NAT. This, in conjunction with the crypto acl will have an impact on what is sent into the tunnel. It is worth noting that this would behave differently for 8.2 and post 8.4 code.

      • Alan says:

        Hi Paul
        The hosts in question do also need access to the Internet which would indeed require them to use a different NAT address [PAT actually in this case]
        Cheers!
        Al.

  7. Erdal says:

    hi. Am I getting it wrong or there is a typo?
    //crypto ACL
    access-list L2LAccessList extended permit ip 192.168.2.0 255.255.255.0 192.168.1.0 255.255.255.0
    Should it not be from 192.168.2.0/24 to 192.168.3.0/24 the crypto acl?

    • Paul Stewart, CCIE 26009 (Security) says:

      The crypto ACL should work. The reason is that the destination would be changed prior to encryption by the following–

      static (outside,inside) 192.168.3.0 192.168.1.0 netmask 255.255.255.0

      This would make anything going from inside to outside with a destination of 192.168.3.x have a new destination of 192.168.1.x

      The crypto would be applied after this process.

  8. linka says:

    Hello,
    Why I can not pinging 192.168.2.1 (address after nat) interface from the partner site over the vpn tunnel?

  9. shuja says:

    Hi Paul

    i would like to say thank you for this post. Can you explain why do you have to add this statement nat (outside,inside) static 192.168.3.0…I have successfully configured the vpn tunnel by not using the statement above..Please see my config for ASA1 and ASA2 respectively

    ASA Version 8.4(2)
    !
    hostname ciscoasa
    enable password 8Ry2YjIyt7RRXU24 encrypted
    passwd 2KFQnbNIdI.2KYOU encrypted
    names
    !
    interface GigabitEthernet0
    shutdown
    no nameif
    no security-level
    no ip address
    !
    interface GigabitEthernet1
    nameif outside
    security-level 0
    ip address 193.201.205.2 255.255.255.252
    !
    interface GigabitEthernet2
    shutdown
    no nameif
    no security-level
    no ip address
    !
    interface GigabitEthernet3
    nameif inside
    security-level 100
    ip address 192.168.1.1 255.255.255.0
    !
    interface GigabitEthernet4
    shutdown
    no nameif
    no security-level
    no ip address
    !
    interface GigabitEthernet5
    shutdown
    no nameif
    no security-level
    no ip address
    !
    ftp mode passive
    object network LAN
    subnet 192.168.1.0 255.255.255.0
    object network LOCAL-MAP
    subnet 192.168.10.0 255.255.255.0
    object network REMOTE-MAP
    subnet 192.168.20.0 255.255.255.0
    access-list out-in extended permit ip any any
    access-list l2l extended permit ip object LOCAL-MAP object REMOTE-MAP
    nat (inside,outside) source static LAN LOCAL-MAP destination static REMOTE-MAP REMOTE-MAP
    !
    object network LAN
    nat (inside,outside) dynamic interface
    access-group out-in in interface outside
    route outside 0.0.0.0 0.0.0.0 193.201.205.1 1
    crypto ipsec ikev1 transform-set TEST esp-3des esp-sha-hmac
    crypto map MAP 1 match address l2l
    crypto map MAP 1 set peer 193.201.204.2
    crypto map MAP 1 set ikev1 transform-set TEST
    crypto map MAP interface outside
    crypto ikev1 enable outside
    crypto ikev1 policy 10
    authentication pre-share
    encryption 3des
    hash sha
    group 2
    lifetime 600
    telnet timeout 5
    ssh timeout 5
    console timeout 0
    tunnel-group 193.201.204.2 type ipsec-l2l
    tunnel-group 193.201.204.2 ipsec-attributes
    ikev1 pre-shared-key *****
    !
    class-map inspection_default
    match default-inspection-traffic
    !
    !
    ciscoasa#

    **************************************************************************
    ASA Version 8.4(2)
    !
    hostname ASA2
    enable password 8Ry2YjIyt7RRXU24 encrypted
    passwd 2KFQnbNIdI.2KYOU encrypted
    names
    !
    interface GigabitEthernet0
    shutdown
    no nameif
    no security-level
    no ip address
    !
    interface GigabitEthernet1
    nameif outside
    security-level 0
    ip address 193.201.204.2 255.255.255.252
    !
    interface GigabitEthernet2
    shutdown
    no nameif
    no security-level
    no ip address
    !
    interface GigabitEthernet3
    nameif inside
    security-level 100
    ip address 192.168.1.1 255.255.255.0
    !
    interface GigabitEthernet4
    shutdown
    no nameif
    no security-level
    no ip address
    !
    interface GigabitEthernet5
    shutdown
    no nameif
    no security-level
    no ip address
    !
    ftp mode passive
    object network LOCAL-MAP
    subnet 192.168.20.0 255.255.255.0
    object network REMOTE-MAP
    subnet 192.168.10.0 255.255.255.0
    object network LOCAL
    subnet 192.168.1.0 255.255.255.0
    access-list out-in extended permit ip any any
    access-list l2l extended permit ip object LOCAL-MAP object REMOTE-MAP
    nat (inside,outside) source static LOCAL LOCAL-MAP destination static REMOTE-MAP REMOTE-MAP
    !
    object network LOCAL
    nat (inside,outside) dynamic interface
    access-group out-in in interface outside
    route outside 0.0.0.0 0.0.0.0 193.201.204.1 1
    crypto ipsec ikev1 transform-set TEST esp-3des esp-sha-hmac
    crypto map MAP 1 match address l2l
    crypto map MAP 1 set peer 193.201.205.2
    crypto map MAP 1 set ikev1 transform-set TEST
    crypto map MAP interface outside
    crypto ikev1 enable outside
    crypto ikev1 policy 10
    authentication pre-share
    encryption 3des
    hash sha
    group 2
    lifetime 600
    telnet timeout 5
    ssh timeout 5
    console timeout 0
    tunnel-group 193.201.205.2 type ipsec-l2l
    tunnel-group 193.201.205.2 ipsec-attributes
    ikev1 pre-shared-key *****
    !
    class-map inspection_default
    match default-inspection-traffic
    !
    !
    ASA2#

  10. Marcelo Rosas says:

    Hello,
    Is it possible do simultaneously source and destination nat at a Cisco Switch 6500?

  11. Awais says:

    Awais Afzal

    nat (inside,outside) source static LOCAL LOCAL-MAP destination static

    this command use in ASA version 8.4 static inside any client to outside asa interface ip address

    some different command use but error face overlap ip adder will face

    object netwrok test
    network XXXX
    nat (inside,outside) static inside ip and then outside ip add but face overlap ip add
    how to resolve it

    • I don’t have a good answer to your question. The ASA must have some way to differentiate. So what we are really doing is stacking nat rules from least specific to more specific. It in any of those case it fails to work, I don’t know of a method to resolve that.

  12. Zahid says:

    Very useful article.

    I used tunnel group with vpn-filter to restrict my business partner to only access certain ports on my particular host and my question is what would be the destination is my vpn-filter acl either it will be actual host(192.168.0.x) or translated host(192.168.3.x)?

  13. Zahid says:

    Very useful article.

    I used tunnel group with vpn-filter to restrict my business partner to only access certain ports on my particular host and my question is what would be the destination is my vpn-filter acl either it will be actual host(192.168.1.x) or translated host(192.168.2.x)?

  14. Pingback: Cisco Meraki switches and security devices

  15. Nathan says:

    Hello Paul,

    I was confused at first. I was assuming that the business partner side would have a mirrored configuration. It didn’t make sense to me that way. Finally a colleague pointed out that the inside was the only side performing the NAT.

    Is that the case?

  16. humplanet says:

    Hello Paul
    thanks for the great article. this may somewhat apply to your article. I am working with a client running pre 8.3(8.2(5) to be exact). the client’s business partner have a site to site vpn tunnel, they want the client to do a one to one nat for a couple of local database server ip addresses and all other traffic to nat using a static address. is there anything special I must do to perform on nat and acls to perform this task? thanks again

  17. Jeff Parton says:

    With in place, where I am getting lost is that both locations may have a computer with the IP address of, let’s say, 192.168.1.56. If I ping this address on the Corporate side, it will reply from the local printer, how would this configuration allow me to get to the printer at the partners side with the same IP address? Forgive me if my ignorance of the subject is too much.

  18. Jeff says:

    Please ignore my previous post, I missed a part of your article that explains this.

  19. Jeff says:

    With several VLANs at both sites on the same subnets (phones, etc) will I need to do this for each individual subnet (separate VPN for each) or can I add the different subnets to the existing objects?

    • If you have a lot of overlap to deal with, this can get fairly complex fairly quickly. If you can standardize as much as possible that would certainly help. Most likely you will have to create some configuration including some new object groups. As you map this out, think about the configuration constructs and how you might group the commonality (object groups, and in some cases with broader subnets specified).

      • Jeff says:

        I found that adding ACLs to the existing crypto_maps allowed multiple VPNs to be established when access to a specific subnet was requested. As example, My VPN for the phone subnet worked but only showed 1 active VPN for the ACL for the phone. When I added access to the “server” vlan to both sides, the VPN count raised by one when a resource (dns query) requested information. It stayed active until the timeout hit, then went inactive until the resource was requested again. This second VPN used the same information and settings as the first VPN. I hope I stated this correctly. It worked awesomely.

  20. Chekol says:

    What do I have to do to manage(ssh) to the inside interface of the remote ASA. over this new tunnel.
    management-inside is enabled and I can remotely ssh to each ASA over remote vpn or another site to site VPN but not with this vpn I just built with the instruction above.

    • Management-access inside is the primary command to enable this. You would also have to have SSH permitted to the ip address that the ASA views as the source through the tunnel (ssh inside). In addition to this, the subnet that the inside interface is on must be compatible with crypto acl’s, split tunnel acl’s, NAT configuration and routing configuration.

  21. Khan says:

    policy nat translation
    //translates a source of
    //192.168.1.x/24 to
    //192.168.2.0/24 only when
    //the destination is 192.168.3.0/24
    nat (inside,outside) source static obj-192.168.1.0 obj-192.168.2.0 destination static obj-192.168.3.0 obj-192.168.1.0
    !
    //translate destinations of
    //192.168.3.0/24 to 192.168.1.0/24
    //reference the objects above
    object network obj-192.168.1.0
    nat (outside,inside) static 192.168.3.0

    since this is site to site IPSEC VPN, i need to know that at which point in the above statement performed the NAT0 to by pass the VPN traffice from the Global NAT rule, as mentioned below

    /PAT all other traffic to
    //interface IP
    object network obj_any
    nat (inside,outside) dynamic interface
    route outside 0.0.0.0 0.0.0.0 1.1.1.1 1

  22. Pingback: VPN with Overlapping Addresses

  23. Niels K. says:

    May I ask why you have to use two different networks for the NAT (one that represents the outside to the inside and vice versa) and why not one network is enough? So only 192.168.2.0/24 instead of 192.168.2.0/24 and 192.168.3.0/24.

  24. Pingback: L2l Vpn | cheapautoinsuranceinva.com

  25. Martin Rivera says:

    Paul, thanks for this terrific article.
    Now I do have a small challenge, my Site2Site VPN is to add the remote PC’s to an existing Windows DC, but the PC’s at the remote site are not able to resolve the DNS name for the DC. How can I overcome this? Thanks so much!

  26. Jeff says:

    You can try to use HOST file entry?? x.x.x.x DCNAME

  27. Daven says:

    Thank you for the great article! I did have a question or something I’m still not getting by reading the very helpful comments. I have a asa running 8.2 software. I need to allow a single host (host a) to be translated through the site to site VPN on the remote end. Host a already has a static translation used for other operations. If I tried policy nat (the ugly solution) would that be canceled out by the order of operations (nat exemption, static nat, static pat then policy nat) anyway? what is an elegant way to do this without effecting existing operations?
    Thank you,

Comments are closed.