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