Connecting to a remote server through a VPN when the local network subnet address conflicts with a remote network

It is possible to solve this using NAT; it's just not very elegant.

So under the assumption you couldn't solve this by having internal nets which have so uncommon network numbers as to never actually come into conflict, here's the principle:

As both the local and remote subnet have identical network numbers, traffic from your client will never realize it has to go through the tunnel gateway to reach its destination. And even if we imagine it could, the situation would be the same for the remote host as it is about to send an answer.

So stay with me and pretend that as of yet, there are no side issues as I write that for full connectivity, you would need to NAT both ends inside the tunnel so as to differentiate the hosts and allow for routing.

Making some nets up here:

• Your office network uses 192.0.2.0/24
• Your remote office uses 192.0.2.0/24
• Your office network VPN gateway hides 192.0.2.0/24 hosts behind the NATed network number 198.51.100.0/24
• Your remote office network VPN gateway hides 192.0.2.0/24 hosts behind the NATed network number 203.0.113.0/24

So inside the VPN tunnel, the office hosts are now 198.51.100.x and remote office hosts are 203.0.113.x. Let's furthermore pretend all hosts are mapped 1:1 in the NAT of their respective VPN gateways. An example:

• Your office network host 192.0.2.5/24 is statically mapped as 198.51.100.5/24 in the office vpn gateway NAT
• Your remote office network host 192.0.2.5/24 is statically mapped as 203.0.113.5/24 in the remote office vpn gateway NAT

So when host 192.0.2.5/24 in the remote office wants to connect to the host with the same ip in the office network, it needs to do so using the address 198.51.100.5/24 as destination. The following happens:

• At the remote office, host 198.51.100.5 is a remote destination reached through the VPN and routed there.
• At the remote office, host 192.0.2.5 is masqueraded as 203.0.113.5 as the packet passes the NAT function.
• At the office, host 198.51.100.5 is translated to 192.0.2.5 as the packet passes the NAT function.
• At the office, return traffic to host 203.0.113.5 goes through the same process in the reverse direction.

So whilst there is a solution, there are a number of issues which must be addressed for this to work in practice:

• The masqueraded IP must be used for remote connectivity; DNS gets complex. This is because endpoints must have a unique IP address, as viewed from the connecting host.
• A NAT function must be implemented both ends as part of the VPN solution.
• Statically mapping hosts is a must for reachability from the other end.
• If traffic is unidirectional, only the receiving end needs static mapping of all involved hosts; the client can get away with being dynamically NATed if desirable.
• If traffic is bidirectional, both ends need static mapping of all involved hosts.
• Internet connectivity must not be impaired regardless of split- or non-split VPN.
• If you can't map 1-to-1 it gets messy; careful bookkeeping is a necessity.
• Naturally one runs the risk of using NAT addresses which also turn out to be duplicates :-)

So solving this needs careful design. If your remote office really consists of road warriors you add a layer of problems in that:

• they never know beforehand when they end up on overlapping net ids.
• the remote office gateway NAT would need to be implemented on their laptops.
• the office gateway would need two VPNs, one NAT-free and one NATed, to cover both scenarios. Otherwise, in the event someone were to pick one of the subnets you chose for the NAT method, things wouldn't work.

Depending on your VPN client you might be able to automatically select one VPN or the other depending on the network address of the local segment.

Observe that all mentioning of NAT in this context denotes a NAT function which so to speak takes place within the tunnel perspective. Processwise, the static NAT mapping must be done before the packet "enters" the tunnel, i.e. before it is encapsulated in the transport packet which is to take it across the internet to the other VPN gateway.

This means that one must not confuse the public ip addresses of the VPN gateways (and which in practice may also be NAT:ed, but then wholly outside the perspective of transport to the remote site through VPN) with the unique private addresses used as masquerades for the duplicate private addresses. If this abstraction is difficult to picture, an illustration of how NAT may be physically separated from the VPN gateway for this purpose is made here:
Using NAT in Overlapping Networks.

Condensing the same picture to a logical separation inside one machine, capable of performing both the NAT and VPN gateway functionality, is simply taking the same example one step further, but does place greater emphasis on the capabilities of the software at hand. Hacking it together with for example OpenVPN and iptables and posting the solution here would be a worthy challenge.

Softwarewise it certainly is possible:
PIX/ASA 7.x and Later: LAN-to-LAN IPsec VPN with Overlapping Networks Configuration Example
and:
Configuring an IPSec Tunnel Between Routers with Duplicate LAN Subnets

The actual implementation therefore depends on a lot of factors, the operating systems involved, associated software and its possibilities not the least. But it certainly is doable. You would need to think and experiment a bit.

I learned this from Cisco as seen by the links.

If you need a temporary dirty workaround to a single or a handful known server ips, the simplest solution should be the static client side routing option.

In my case I added my desired destination server (192.168.1.100) to my routing table on my linux client via:

route add 192.168.1.100 dev tun0

Afterwards, remove this static route with the route delete command.

yup this is the worst. for me it happened all the time from hotel rooms, before it vpn admins realized they should use more obscure ip ranges. 10.0.0.0/24 and 10.1.1.1/24 are the worst. if you can help it never ip a wireless network like that.

so the answer is "fix" the wap to use a different internal network (ie 10.255.255.0/24) and then give you a diff lease (ie ip in a range that can route back to corp vpn), or if you have no / cant get admin on wap, just go to starbucks. or 20 minutes of wardriving :)

if this is just in a lab setting, just use different ranges.