I have a basic OpenVPN connection that I use with several pi's. All of these pi's use various versions of Raspbian without the GUI (the lite version). And they all work great. The same configuration on pi with the UI does not work.
Here is the routing on a pi (Lite - no GUI) that works as expected when connected to OpenVPN:
default via 192.168.3.254 dev wlan0 src 192.168.3.84 metric 303 10.70.0.0/24 dev tap0 proto kernel scope link src 10.70.0.132 metric 206 :-) xx.xx.xx.xx via 192.168.3.254 dev wlan0 192.168.3.0/24 dev wlan0 proto kernel scope link src 192.168.3.84 metric 303
Here is the routing on the GUI version (bad):
:-( default via 10.70.0.1 dev tap0 src 10.70.0.133 metric 206 default via 192.168.3.254 dev wlan0 src 192.168.3.96 metric 303 10.70.0.0/24 dev tap0 proto kernel scope link src 10.70.0.133 metric 206 192.168.3.0/24 dev wlan0 proto kernel scope link src 192.168.3.96 metric 303
Sometime within 10 seconds after establishing its connection, the
xx.xx.xx.xx via 192.168.3.254 dev wlan0
line disappears and that offending route line (one with frown above) appears which effectively severs the connection to the server because that xx IP address is the server's route which must be routed over the wlan0 interface.
Secondly, that additional default gateway cannot be deleted. 'ip route del ...' reports no errors upon trying to delete it (blank return) but it will absolutely not go away. Manual attempts to add the xx.xx.xx.xx route back are successful, but then after some period of time (seconds, minutes, or hours) it just inexplicably disappears.
There are no routes being pushed by the OVPN server, no default gateways, no nothing. Here is part of the client's connection log:
Sun Sep 30 16:13:41 2018 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA Sun Sep 30 16:13:41 2018 [server] Peer Connection Initiated with [AF_INET]xx.xx.xx.xx:1197 Sun Sep 30 16:13:42 2018 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1) Sun Sep 30 16:13:42 2018 PUSH: Received control message: 'PUSH_REPLY,ping 10,ping-restart 120,peer-id 2,cipher AES-256-GCM' Sun Sep 30 16:13:42 2018 OPTIONS IMPORT: timers and/or timeouts modified Sun Sep 30 16:13:42 2018 OPTIONS IMPORT: peer-id set Sun Sep 30 16:13:42 2018 OPTIONS IMPORT: adjusting link_mtu to 1657 Sun Sep 30 16:13:42 2018 OPTIONS IMPORT: data channel crypto options modified Sun Sep 30 16:13:42 2018 Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key Sun Sep 30 16:13:42 2018 Data Channel Decrypt: Cipher 'AES-256-GCM' initialized with 256 bit key Sun Sep 30 16:13:42 2018 TUN/TAP device tap0 opened Sun Sep 30 16:13:42 2018 TUN/TAP TX queue length set to 100 Sun Sep 30 16:13:42 2018 Initialization Sequence Complete
Using route-noexec produces the same results. This issue smells like a network manager that is running on the GUI version of Raspbian and interfering, but looking at the running services does not seem to give any indication of a network manager - at least not by any name I'm familiar with.