Opened 9 years ago
Closed 5 years ago
#544 closed Bug / Defect (worksforme)
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:
- GW bypass route should choose the best available option, up to ~/4
- 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.
- OpenVPN process should never attempt to delete routes it did not create
Change History (10)
comment:1 follow-up: 8 Changed 9 years ago by
comment:2 Changed 9 years ago by
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 9 years ago by
| Version: | 2.2.2 → 2.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:5 Changed 9 years ago by
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:8 follow-up: 9 Changed 5 years ago by
Replying to Gert Döring:
Doing "redirect-gateway" on two VPNs at the same time is a non-useful configuration - just don't do it.
This is the best advice.
comment:9 follow-up: 10 Changed 5 years ago by
Replying to tincantech:
Replying to Gert Döring:
Doing "redirect-gateway" on two VPNs at the same time is a non-useful configuration - just don't do it.
This is the best advice.
Multiply-connected VPNs begin to make a lot of sense once the degree of paranoidness exceeds certain threshold. Not me, but there are a lot of such people.
comment:10 Changed 5 years ago by
| Resolution: | → worksforme |
|---|---|
| Status: | new → closed |
Replying to yurivict:
Multiply-connected VPNs begin to make a lot of sense once the degree of paranoidness exceeds certain threshold.
Even so, you can only redirect your gateway to *one* VPN.
You can have "one VPN in a different VPN", which might or might not satisfy the paranoia requirements, but in that case you point VPN gateway #2 into VPN #1, and the default only goes to VPN #2.
Or you can have two VPNs active at the same time, but in this case you need to decide on "which route goes where". So, doing "redirect-gateway" twice will never cause what you assume it does.
Anyway, since I'm still waiting for the log file with the very specific details of what OpenVPN did, and what "disaster" specifically means, and the OpenVPN version in this ticket is over 5 years old, I'll just close this ticket now.
If you want us to consider a code change, provide a log file of the then-current version (2.4.8).
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)?