47

This is a Canonical Question about solving IPv4 subnet conflicts between a VPN client's local network and one across the VPN link from it.

After connecting to a remote location via OpenVPN, clients try to access a server on a network that exists on a subnet such as 192.0.2.0/24. However, sometimes, the network on the client's LAN has the same subnet address: 192.0.2.0/24. Clients are unable to connect to the remote server via typing in its IP because of this conflict. They are unable to even access the public internet while connected to the VPN.

The problem is that this subnet 192.0.2.0/24 needs to be routed by the VPN, but it also needs to be routed as the client's LAN.

Does anyone know how to mitigate this issue? I have access to the OpenVPN server.

Falcon Momot
  • 24,975
  • 13
  • 61
  • 92
John Russell
  • 573
  • 1
  • 5
  • 5
  • 3
    You can try setting a static route for the /32 address of the host you're trying to reach and use the VPN peer as your gateway and see what happens. – SpacemanSpiff Oct 26 '13 at 23:33
  • if the vpn concentrator honors client routes, then your perimeter security may need some help. i get access to accounting lan, add route to engineering range, and i can then connect no problem. crappy firewalls like sonicwall do this – nandoP Oct 27 '13 at 00:05
  • @SpacemanSpiff: While this *could* solve the issue on the client side, the server would still be unable to reply, because it would see the connection as coming from its own network, not from a VPN client. – Massimo Dec 24 '15 at 22:10

9 Answers9

27

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.

Aydin K.
  • 371
  • 3
  • 4
  • 2
    This is a perfect solution, and an even perfect timing! :) – Yuval A Feb 28 '17 at 13:12
  • How long does this persist? Until you disconnect? Until reboot? – carbocation Jul 31 '17 at 23:23
  • 2
    On my linux system (xfce with ubuntu/mint) the settings is "lost" after a vpn disconnect and yes, after a reboot as well. You can verify if the setting is active with the route command (there will be an entry having the ip and the tun0 device usually at the bottom) – Aydin K. Aug 09 '17 at 15:40
  • 3
    The OSX version of route takes the interface differently so instead of `dev tun0` you need `-interface tun0` – Allison Jan 04 '18 at 18:22
25

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.

ErikE
  • 4,676
  • 1
  • 19
  • 25
  • Could NAT work also with many VPN connections and their translations? I did not completely understand the case here. I have a thread here http://unix.stackexchange.com/q/284696/16920 about *How to Do Site-To-Site VPN with Overlapping Subnets Unix-Way?* – Léo Léopold Hertz 준영 May 21 '16 at 21:26
5

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.

nandoP
  • 2,001
  • 14
  • 15
5

The Answer from Aydin K. is for linux. If your want the same funtionality for windows, you can type

route ADD 192.168.1.10 <IP of tunnel adapter>

or

route ADD 192.168.1.10 IF <interface id>

you can get the interface id with the command:

route print
OllowainT
  • 51
  • 1
  • 1
4

I'm on a mac running El Capitan. While the suggestions above didn't work for me they led me to a working solution:

  1. before starting VPN, execute ifconfig

  2. start the VPN, do ifconfig and note which is the new interface. In my case it was ppp0 with an ip address of 192.168.42.74

    ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
    inet 192.168.42.74 --> 192.0.2.1 netmask 0xffffff00

  3. type in: 

    sudo route add 192.168.1.79  192.168.42.74

I tested first with a ping and then I proved it worked by accessing the git server.

When I tried using dev ppp0 for the end of the route command as mentioned above, it complained.

Thomas
  • 4,155
  • 5
  • 21
  • 28
Robert Chapman III
  • 41
  • 2
2

I have a simple solution that I'm using at a co-working space that has a conflicting IP range (10.x)

I connected to the network with my mobile phone, then I shared the network connection via bluetooth with my laptop. I can now use the VPN for my remote employer.

I'm sure this will work just the same via USB if you need a faster connection.

Aaron Ramirez
  • 29
  • 1
1

If you just need to hit a few one or two ip addresses, add route statement to your ovpn configuration file like this:

route 192.168.1.10 255.255.255.255

route 192.168.1.11 255.255.255.255

It will add a route for just those Ip's when you connect your vpn and remove it when the vpn it disconnected.

Worked for me on Windows anyway.

Jesse Regier
  • 11
  • 1
0

if you have same ip block both local and remote networks and want to access only remote block local && remote network address : 192.168.2.0/24 following options for windows 10 worked for me

add these options to OpenVPN certificate file

route-metric 3
route 192.168.2.0 255.255.255.0

why? Real ethernet interface have metric 0

TAP vpn interface has metric 256

we must increase TAP interface's priority

alfa
  • 1
  • 1
0

Just as a reminder: this whole issue is due to years of IPv4 address shortage, and extensive use of private IP range behind NAT to workaround this shortage !

The ideal and definitive solution to this issue is quite straightforward (albeit it can, and will, takes some time to be globally rolled-out) : IPv6...

In an IPv6 world, there's no public IP shortage (and there won't be, event in a few decade). So there no reason not to have a public IP on each and every device of every network. And if you need network isolation, keep filtering with a firewall, but without ugly NAT...

CuriousFab
  • 121
  • 2