answered
2017-12-29 21:10:55 +0200
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.
Having no default gateway routing through the tunnel is not necessarily a bug in SFOS. Having a proper configuration which mandates all traffic trough the tunnel and no corresponding routing on the client would make this a SFSO bug. I'll remove the bug tag; please re-add it if you are sure this is a SFOS bug.
Maus ( 2017-10-15 16:17:39 +0200 )editI can confirm that this is a bug in SFOS. My OpenVPN server is configured to push a default route via the VPN tunnel to the client (
ghling ( 2017-10-16 16:15:12 +0200 )editpush "redirect-gateway def1 bypass-dhcp"
). This works on every other device except Sailfish (had the issue both on my Jolla C and now on my Xperia X) where the default route is not set. Furthermore, privilege downgrading (best practice to drop the privileges of the connection to user and group "nobody") does not to work either. It is not only ignored but causes the connection attempt with the server to fail.