Make openvpn not hang when overriding default gateway

[vpn2vpn]

Hi vpners,

When openvn the client executable runs on Linux/Android/Embed as default gateway and the default interface is taken down openvpn hangs.

Wish upon a star:
Could we have a directive that puts back the direct route on SIGUSR1 events?
or
script execution put in a working state on Android and Embed (busybox) [ yeah, that ash thing doesn't work ]

Here's how the lockup happens:
a. This is because the direct route to the remote server disappears with the default interface going down because the route is associated with it.
b. The default gateway override remains because it is associated with the openvpn tun device.
c. For whatever reason, openvpn won't put the direct route back until it has connected.
d. openvpn can't connect, because vpn still overrides the default gateway and without that direct route, vpn packets are recursively routed into the vpn tunnel again going nowhere.

This happens for
1. Linux laptops switching wi-fi networks.
2. A server experiencing ifdown-ifup on the default interface.
3. An Android device switching wi-fi networks, switching to or from WAN or just moving across WAN coverage.

To get out of the lockup, either of these things need to happen:
A. openvpn process has to be terminated and relaunch so that its default gateway override is removed
B. Friendly programmer issues that ip route [remote ip] via [default gateway ip] dev [default gateway interface]
C. One can use script-security 2; restart-up; down down and have a down script that executes B. The down script is executed when SIGUSR1 is about to happen. The up script is not.

Because scripts no work on Android, openvpn and OpenVPN Settings cannot be made reliable on Android.

Smells like a code change unless there is some make-it-work directive construct I don't know about.

-- perhaps some crazy like openvpn run as root and no persist-tun, maybe would work?

Thanks,

[Traffic]

Could you post configs and logs for server and working/broken client (at --verb 4)
Perhaps you have a config problem which can be addressed .. thanks

[vpn2vpn]

I sure will.

I did however confirm that openvpn executable works if persist-tun is removed.
This is true for a WAN device that frequently takes the default interface down.

It is also seems to be the case that running the openvpn executable for an extended period of time (24 h) crashes Android UI, though not the underlying Linux. While openvpn is up, it works great...

[vpn2vpn]

There doesn't seem to be much help in da forum here, but here are some truths:

A. If an OpenVPN connection is overriding the default gateway (0.0.0.0/1), or if another OpenVPN connection is overriding the default gateway and should not be used, then a direct route to the OpenVPN server is required or OpenVPN will freeze/hang/do nada due to recursive or broken routing.

B. OpenVPN adds that direct route AFTER the connection is established. Que?

C. So, the only way out is to add the direct route before OpenVPN is launched in a wrapper script while loop, and use remap-usr1 SIGTERM so that OpenVPN exits on timeout (there is no user script that runs before communication has already happened.)

D. If this is not done on every computer or device where the default gateway device is occasionally brought down, ie. any laptop/tablet/mobile phone to date, OpenVPN will eventually hang/freeze/do nada. This is because unlike all other routes, the direct route is deleted with the default route device (ip route list 0/0.)

Unless I got this all wrong, there seems to be certain room for improvement here.

[Traffic]

There doesn't seem to be much help in da forum here

we asked you to post your configs and logs .. I suppose I could dust off my crystal ball ..

[vpn2vpn]

I fixed this one, too.

You can add the direct route manually before initially launching openvpn. Openvpn logs an error if the route already exists, but keeps going.

Then you can use the up-restart directive with the down script as described in the initial posting, ensuring the direct route is added back when it is lost with like iptables --check.

Then, I added the port-level routing configuration to the up script.

If you want to sometimes override the default gateway and sometimes not you can use multiple certificates since the server's per-client configuration goes by certificate common name.

I think this setup may prevent the Android apps from hanging. OpenVPN Settings is beyond repair but OpenVPN for Android might work a little better. The lack in architecture of OpenVPN is that no script runs before the first packet is sent, and no script runs on SIGTERM but not on SIGUSR1, so maybe there's something that is not fixable. And them apps thinks people will survive with only one connection. More is better.

[Traffic]

Personally, I am unable to confirm your findings:

Here's how the lockup happens:
a. This is because the direct route to the remote server disappears with the default interface going down because the route is associated with it.
b. The default gateway override remains because it is associated with the openvpn tun device.
c. For whatever reason, openvpn won't put the direct route back until it has connected.
d. openvpn can't connect, because vpn still overrides the default gateway and without that direct route, vpn packets are recursively routed into the vpn tunnel again going nowhere.

If you believe this to be a true bug then I recommend you raise a full report:
https://community.openvpn.net/openvpn : Bugs

[vpn2vpn]

Alrighty, here's how to get that OpenVPN executable experience on Android:

Android 4 introduced ksh instead of the previous ash/busybox that had most shell features broken
- ksh is like bash but Google doesn't have to suffer GPL
therefore, you need an executable more recent than 10/2011, check with openvpn --version
If you're on Android 5 you need a different executable, newer than 11/2014.

Your server and client need mssfix 1341 fragment 1341, test with mtu-test directive
Other people's servers that have large 1 KiB++ certificates, you cannot connect to.

scripts must have executable permissions and begin with !#/system/bin/sh -eu
If your openvpn executable cannot launch scripts, it won't work.
directive script-security 2

OpenVPN is broken for connections requiring direct routes, basically most of them. therefore
- use up-restart and down directives
- in down script add your direct route: ip route add vpnserver via defaultinterfacegateway
- before openvpn executable is launched for the first time, you have to add the direct route, too

If you want port level routing (ie. packets to ports on the vpn server goes inside vpn tunnel)
add that in your up script. force anything not udp, or not udp to your vpn server port to use the vpn interface (tun0), use mark a routing table and add SNAT.

Android 4.4+ has a different dns. in your up script add basically:
ndc resolver setdefaultif tun0
ndc resolver setifdns tun0 "" 8.8.8.8
or dns will only work on wi-fi, for all hackers to see.

OpenVPN settings use netmask where you will need cidr. Have fun writing a translation function.

If the OpenVPN connection is not authenticated, you might not know the server ip in your scripts. Have a default. For multiple remotes, it may not be solvable. Or add all of them.

You can have one ovpn file that overrides the default gateway, and a second that just provides additional secure routes: use directives route-noexec and in the route-up script, add any routing you want.

...and it works!

with using the executable, you can have multiple tunnels and any OpenVPN feature ever invented
unfortunately, there is a minute's slowness when going in and out of coverage, and some apps won't immediately get that Internet is back.

For a more restricted experience you can use OpenVPN Connect or OpenVPN for Android. I haven't gotten those to work in real life.

[Skaperen]

d. openvpn can't connect, because vpn still overrides the default gateway and without that direct route, vpn packets are recursively routed into the vpn tunnel again going nowhere.
,

i always set an explicit route to the remote so that the default won't apply. restarting openvpn has been fast for my static setup tests, so that's what i would try if the remote changes (if not, it should just work).