[Bug] OpenVPN Default Route directive from server ignored

answered 2017-10-15 15:40:46 +0300

Maus
2032 ●20 ●42 ●54

updated 2017-10-15 15:55:45 +0300

OpenVPN does not set a default route without a (remote, local) configuration that tells it to do so. I see that some address ranges are routed through the tunnel, and these are likely set on your client by an OpenVPN server push command. It is possible to let the server send a push command that causes all traffic to go through the tunnel. I'd guess that the server configuration doesn't do that with your connection intentionally. For example, the VPN server may not be a full internet router, but only lets you access those networks covered by the push commands.

To force the remote VPN server into being a generic internet gateway, use redirect-gateway def1 in your local configuration file.

answered 2017-10-15 16:04:34 +0300

pullrequest
1 ●1

Hi tobru,

I am on the community-build and had the same behavior. I do not know whether this works in the official version as well.

Attention: This is an intervention in the system and should only be executed if you know what you are doing. No liability for anything.

To replace the standard nameserver with the vpn-pushed-nameserver, I had to edit the connman service to start connman with the --nodnsproxy option.

answered 2017-10-16 16:47:03 +0300

ghling
4414 ●58 ●89 ●96

updated 2017-10-17 09:45:47 +0300

I have re-added the "bug" tag as this seems to be a bug in SFOS. The VPN client ignores the redirect-gateway def1 directive it receives from the server upon connection, which should set a new default route. Other routes pushed by the server are added as intended.

From the Server log:

SENT CONTROL [vpn-client3]: 'PUSH_REPLY,route 10.10.10.0 255.255.255.0,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 10.10.12.14,route 10.10.11.1,topology net30,ping 10,ping-restart 120,ifconfig 10.10.11.30 10.10.11.29,peer-id 1' (status=1)

ip r output (of the relevant, pushed routes) on the phone:

10.10.10.0/24 via 10.10.11.29 dev vpn0

10.10.11.1 via 10.10.11.29 dev vpn0

10.10.11.29 dev vpn0 proto kernel scope link src 10.10.11.30

10.10.12.14 dev vpn0 scope link

Adding the option in the .conf file on the phone before importing it as suggested here did not solve this issue for me on the Xperia X (read: did not add the new default route upon connecting).

answered 2017-11-29 12:45:26 +0300

Corvinux
391 ●6 ●7 ●9

updated 2017-11-29 13:05:22 +0300

@tobru What I've found out is that you just need to reboot you phone after you have imported your ".ovpn" file and then normally connect to your vpn provider, BTW, I'm using expressvpn*.ovpn" on my Sony Xperia X, SailfishOS 2.1.3.7 (Kymijoki) and it will default route to vpn0.

[root@SailfishX nemo]# ip r
default dev vpn0  scope link
.... via .... dev vpn0 
.... dev vpn0  scope link 
.... dev vpn0  proto kernel  scope link  src .... 
.... via .... dev wlan0 
...0/24 dev wlan0  proto kernel  scope link  src .... 
.... dev wlan0  scope link

answered 2017-11-29 16:31:42 +0300

Pasko
937 ●11 ●26 ●27

Hi.

While I've been suspecting that the default route is set wrongly during VPN setup I must also say that using tcpdump in my Xperia X only shows traffic from my device to the VPN server and not anywhere else. Not even DNS querys which I also route through the VPN tunnel.

In my setup I also use redirect-gateway def1 (server and client) as well as push "dhcp-option DNS 172.26.0.1" (only in the server)

However, I don't use the beta VPN software provided by Jolla. I use SecureFishNet from openrepos, which is also based in connmand.

This is the tcpdump test I made, showing no traffic going outside the VPN:

[root@Sailfish nemo]pkcon refresh
[root@Sailfish nemo]pkcon install tcpdump
[root@Sailfish nemo]tcpdump -i rmnet_data0 host not 'server_ip_address'

In my case rmnet_data0 is the device associated with my cellular data PDP Context. If you change rmnet_data0 with vpn0 you should see ALL traffic going inside the VPN.

You may also try changing rmnet_data0 with wlan0 if you're using a WiFi network.

Summarizing:

1.- I think the default route issue is at least 'misguiding' :D

2.- I don't see any traffic going outside the vpn0 interface (including DNS queries).

Regards.

answered 2017-12-29 21:10:55 +0300

Juma7C9
11 ●2 ●3

https://github.com/Juma7C...

updated 2017-12-29 21:12:52 +0300

I think the problem depends on the internals of Connman. As stated in an answer to a similar problem, the default gateway gets assigned to the first service, as can be seen using connmanctl services.

Indeed, doing some tests I got:

[root@Sailfish openvpn]# connmanctl services
*AO home_wlan            wifi_94fd2e0368ad_686f6d655f776c616e_managed_psk
* R openvpn              vpn_ar2_mysite_dom_merproject_org
*   openvpn              vpn_par_mysite_dom_merproject_org
*   openvpn              vpn_sbg_mysite_dom_merproject_org
*A  I WIND               cellular_222883670243541_context1
    Vodafone-30452127    wifi_94fd2e0368ad_566f6461666f6e652d3330343532313237_managed_psk
[...]

[root@Sailfish openvpn]# ip route
default via 192.168.1.254 dev wlan0 
[vpn_remote_ip] via 192.168.1.254 dev wlan0 
192.168.1.0/24 dev wlan0  proto kernel  scope link  src 192.168.1.73 
192.168.1.254 dev wlan0  scope link 
192.168.128.1 via 192.168.128.13 dev vpn0 
192.168.128.13 dev vpn0  proto kernel  scope link  src 192.168.128.14 

[root@Sailfish openvpn]# connmanctl move-before vpn_ar2_mysite_dom_merproject_org wifi_94fd2e0368ad_686f6d655f776c616e_managed_psk
Moved vpn_ar2_mysite_dom_merproject_org before wifi_94fd2e0368ad_686f6d655f776c616e_managed_psk
[root@Sailfish openvpn]# connmanctl services
* R openvpn              vpn_ar2_mysite_dom_merproject_org
*AR home_wlan            wifi_94fd2e0368ad_686f6d655f776c616e_managed_psk
*   openvpn              vpn_par_mysite_dom_merproject_org
*   openvpn              vpn_sbg_mysite_dom_merproject_org
*A  I WIND               cellular_222883670243541_context1
    Vodafone-30452127    wifi_94fd2e0368ad_566f6461666f6e652d3330343532313237_managed_psk
[...]

[root@Sailfish openvpn]# ip route
default dev vpn0  scope link 
[my_vpn_ip] via 192.168.1.254 dev wlan0 
192.168.1.0/24 dev wlan0  proto kernel  scope link  src 192.168.1.73 
192.168.1.254 dev wlan0  scope link 
192.168.128.1 via 192.168.128.13 dev vpn0 
192.168.128.13 dev vpn0  proto kernel  scope link  src 192.168.128.14

By the way, the patch proposed on 01.org seems not to have been included upstream, as there is no mention of the redirect-gateway option. This means that adding a redirect-gateway in the client conf or pushing it by the server should have no effect, as long as Connman is involved.

A possible solution would be to add a GUI switch asking the user if he/she wishes to redirect all the traffic via the VPN, and if it so push the relative service on the top of the Connman's list.

As it is now, the chances the vpn will be used as the default gw are quite random, as I found out adding some different servers, all serving the same configuration (apart from different address ranges): some systematically got to be the default gateway, some others never. As it turns out it was because the former got pushed on the list on top of the wifi service, the latter below it.