OpenVPN with MacOS X Client and same subnets in local and remote net

Question

I have a homenetwork 192.168.1.0/24 with gateway 192.168.1.1 and a remote network with the same parameters. Now I want to create a OpenVPN tunnel between those networks.

I have no problems with Windows, because Windows routes everything to 192.168.1.0/24 except 192.168.1.1 throught the tunnel.

On Mac OS X however I see the following line in the Details window:

2010-05-10 09:13:01 WARNING: potential route subnet conflict between local LAN [192.168.1.0/255.255.255.0] and remote VPN [192.168.1.0/255.255.255.0]

When I list the routes I get the following:

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            192.168.1.1        UGSc       13        3    en1
127                localhost          UCS         0        0    lo0
localhost          localhost          UH         12     3589    lo0
169.254            link#5             UCS         0        0    en1
192.168.1          link#5             UCS         1        0    en1
192.168.1.1        0:1e:e5:f4:ec:7f   UHLW       13       17    en1   1103
192.168.1.101      localhost          UHS         0        0    lo0
192.168.6          192.168.6.5        UGSc        0        0   tun0
192.168.6.5        192.168.6.6        UH          1        0   tun0

My Interfaces are

en1 - My local Wifi network
tun0 - The tunnel interface

As can be seen from the routes above there is no entry for 192.168.1.0/24 that routes the traffic through the tunnel interface.

When I manually route a single IP like 192.168.1.16 over the tunnel gateway 192.168.6.6, this works.

Q: How do I set up my routes in MacOS X for the same behaviour as on windows, to route everything except 192.168.1.1 through the tunnel, but leave the default gateway to be my local 192.168.1.1 ?

EDIT: I reopened the question because it could not be fully answered the first time.

The VPN-Client machine does not need to access its own subnet, except for the router, and TCP packages should take the tunnel except for the tunnelled packages themselves.

Solution 1

I don't think routing is supposed to work like that. Essentially, your two networks are the same as far as IPv4 is concerned. The VPN doesn't change that. You don't use routers to connect two parts of the same network; you need bridges for that.

I've never done this, but I think you have a few options.

• Configure the OpenVPN gateways in a bridged mode. As long as there are no IP conflicts (one machine on each network with the same IP, eg 192.168.1.100) this should work. If you're using DHCP, you'll need to deal with potential overlap; you don't want two DHCP servers on the same network.

  According to the link, you have two options for IP allocation:

  • Let OpenVPN manage its own client IP address pool using the server-bridge directive, or
  • configure the DHCP server on the LAN to also grant IP address leases to VPN clients.
    

• Configure one network to another network address. Just change 192.168.1/24 on one network to 192.168.7/24 (or some other address). This will definitely work, and you'll only have to reconfigure one network.

• Subnet the 192.168.1/24 into two /25 networks (eg, 192.168.1.0/25 and 192.168.1.128/25). This will also definitely work, but you'll have to reconfigure both networks. (For reference, the netmask on a /25 is 255.255.255.128).

Solution 2

I had the exact some problem. Adding the following script invocation in my ovpn connection setup file solved it:

route-delay 2
route-up /Users/user/.local/bin/vpn-routes

Where the script re-assigns the default route manually, as shown below:

#!/bin/bash

/sbin/route delete default
/sbin/route delete 0/1
/sbin/route add default $route_net_gateway

This worked just fine until I've upgrade to Mountain Lion. I've upgrade to the latest Tunnelblick beta release but the script above seems to not work (I think because of permission issues, still looking into this)

Solution 3

I found that this is a very accessible question (from a SEO perspective), and the solution that worked well for me is found here: https://gist.github.com/taldanzig/4628573

Only one command is required. I am on MacOS Mojave 10.14.6 using Tunnelblick with an OpenVPN config, on a LAN on which the same address 192.168.1.5 is used by a local device (smart TV or something, for example) and by the device I want to connect to services on in the VPN remote LAN.

So, simply issue ifconfig while connected to the VPN to find the name of the VPN interface, in this case utun3. Then,

sudo route add -host 192.168.1.5 -interface utun3

There seems to be no need to delete existing routes to this address, and connectivity to this host is immediate, no reconnecting is required. Neither does there seem to be any need to clean this route up later, I suppose it just disappears when the interface goes away when the connection is lost.

This is very handy when you are on the go and cannot easily change the subnet of the remote network or local network to deconflict them or find a different VPN tech that doesn't exhibit this problem.

Comments

[quack quixote]

don't feel like you have to accept an answer if it doesn't really solve your problem. i think our comment discussion on my answer clarified what you're attempting to do; consider refining your question post from that discussion. that will bump it back to the front page and perhaps get some fresh eyes on the problem.

[Daniel]

+1 Good ideas, but as I already said, it works on my windows client exactly like that. I have no problem reconfiguring my home network, but was just interested how to configure MacOS X to achive the same behaviour as windows is able to.

[Daniel]

Thats exactly what I want to achive. Since I am alone in my local subnet (theres only me and my router), I really would like to achive exactly that.

[quack quixote]

@Daniel: sorry, i'm not an OSX guy, so i'm having trouble coming up with the actual route commands. according to this post it appears something like route -nv add -net 192.168.1 -interface tun0 might work for the 192.168.1/24, and maybe route -nv add -host 192.168.1.1 -interface en0 for the router... but i'm not sure. presumably these should leave your default gateway setting alone.

[Daniel]

Accepted for being the most correct answer, even if it didn't solve my problem. thanks anyway.

[Daniel]

Yes, seems like the only solution to this problem. Upvoted for future generations.