Opened 4 years ago

Last modified 3 years ago

#544 new Bug / Defect

Simultaneous multiple VPNs cause route command failure

Reported by: yurivict Owned by:
Priority: major Milestone:
Component: Generic / unclassified Version: OpenVPN 2.3.6 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc:

Description

From the first VPN connection I am trying to connect to the other VPN. It performs the handshake ok, but breaks on an attempt to add routes.

It turns out that OpenVPN adds such routes:
0.0.0.0/1 <NEW-GW>
128.0.0.0/1 <NEW-GW>
in order to introduce the new GW on top of the existing one.

The second VPN tries to repeat the same and fails. The second process should understand that new GW has been already added, and should add the next best available option:
0.0.0.0/2 <NEW-GW>
64.0.0.0/2 <NEW-GW>
128.0.0.0/2 <NEW-GW>
192.0.0.0/2 <NEW-GW>
And so on and so forth, it will be reasonable to be able to do this this at least up to 3-4 (/1 .. /4).

Another very bad problem is that when the second connection failed, it left it in non-functional mode. When I pressed Ctrl-C, the second connection still went ahead and deleted these two gw bypass routes, which it didn't create. And this rendered the first VPN connection unusable.

So there are three problems:

  1. GW bypass route should choose the best available option, up to ~/4
  2. VPN shouldn't tolerate failure of 'route' command, and should dismantle VPN altogether since it isn't functional anyway. So VPN should be either fully "on", or fully "off". Currently OpenVPN leaves VPN dysfunctional when route rails.
  3. OpenVPN process should never attempt to delete routes it did not create

Change History (7)

comment:1 Changed 4 years ago by Gert Döring

Doing "redirect-gateway" on two VPNs at the same time is a non-useful configuration - just don't do it.

Either just route the specific gateway address of the second VPN into the first VPN, or whatever you need into the second VPN, and things will work just fine.

I do agree that we should consider failure to add routes as "fatal" and not go ahead (and remember that we couldn't create the route). Normally we should, but it might be that this isn't working for your particular platform and combination of options - care to share a log file (with 2.3.6, not 2.2.2 as that is quite old)?

comment:2 Changed 4 years ago by yurivict

The version I used is 2.3.6.

The logs wouldn't reveal anything useful beyond what was said. The second connection goes the successful route until /sbin/route says it can't create the route, and it stops (in non-functional state). Then Ctrl-C causes a disaster.

I would also like to note that the idea of using double or even triple VPN is quite popular and gets mentioned quite a bit. So I was amazed to find it failing with OpenVPN when I tried it.

comment:3 Changed 4 years ago by Gert Döring

Version: 2.2.22.3.6

Knowing the OS used would help, for a start... /sbin/route suggests it is not Windows, but it could still be MacOS, FreeBSD, ...

Double-or-triple-VPN is something which would work, but redirecting the default gateway multiple times is not overly useful, and thus, not supported today. It might work if you do not use the "def1" flag to "redirect-gateway" (which is what makes it install the /1 routes)

comment:4 Changed 4 years ago by yurivict

The OS is FreeBSD.

So I should change def1 to def2?

comment:5 Changed 4 years ago by Gert Döring

leave out "def1", then it will save and restore the pre-existing default route - which can have issues in DHCP environments, which is why the def1 hack is there.

comment:6 Changed 4 years ago by Gert Döring

Duplicate of #504 (with more detail here)

comment:7 Changed 3 years ago by debbie10t

Ideal use case for:--pull-filter ignore "redirect-gateway "

Note: See TracTickets for help on using tickets.