Connected but no internet

[eson57]

Importing config file went fine, and settings app says "Connected" but I still don't have internet connection. How can I debug? Here's my config file and details from settings app.

[javitonino]

Hi, and thanks for the report!

This is currently a limitation of this plugin (mainly to a mistake on my part since I was testing for my personal setup). It will never route all traffic through a VPN, only traffic corresponding to the VPN network itself (in your case, since the address it's a /32, no traffic will go through the VPN).

Let me work on a quick patch (hopefully later today) and I'll let you know when it's ready to test. A good general solution to routing may take longer, but I think there's a quick solution for the common case of sending all traffic through the VPN.

[javitonino]

Ok, so this is more complicated than I thought :cry: The way connman (Sailfish network manager) and WireGuard want to do routing is quite different. As an extra complication, the iproute command that Sailfish ships is quite old, and doesn't allow all the features WG uses.

Anyway, I found something that should work and can be integrated. While I work on integrating it into the package, can you try doing it manually?

It goes like this:

• Connect to the VPN
• Check the interface name assigned to the VPN (likely vpn0). You can do so by running wg show as root, for example.
• Run the following commands as root (replacing interface name if needed):

  wg set vpn0 fwmark 1234
  ip route add 0.0.0.0/0 dev vpn0 table 1234
  ip rule add not fwmark 1234 table 1234

That should send all traffic through the VPN (except the encrypted VPN traffic itself, which goes as normal).

To undo this, you can disconnect the VPN and run the same commands changing add for del (or just restart the phone):

ip route del 0.0.0.0/0 dev vpn0 table 1234
ip rule del not fwmark 1234 table 1234

I'm not sure if that will work in all devices. Support for the ip rule command seems to be dependent on the kernel, which in turn depends on the AOSP sources. So it'd be nice to know if it works for you and which device are you using.

Let's see if we can figure this out :crossed_fingers:

[Logic-gate]

Just a heads up. Prior to your patch--even afterwards--with every failed config import crash or failed connection attempt, a new interface was created. At one point yesterday I had 100+ interfaces. Chances are, some users will have a similar experience. If so, for i in $(wg show | gre p 'interface:' | awk '{print $2}'); do ip link delete de v $i; done which will delete all vpn# interfaces.

[eson57]

@javitonino Sorry, that didn't work on my X10III, SF 4.4.0.72. Everything looked normal till the last command ip rule add not fwmark 1234 table 1234 then nothing happened.

[eson57]

for i in $(wg show | gre p 'interface:' | awk '{print $2}'); do ip link delete de v $i; done

@Logic-gate There's an unwanted space in your script. ;)

[Logic-gate]

That's weird. There are two unwanted spaces. I was using sailhub, might have been clipped.

for i in $(wg show | grep 'interface:' | awk '{print $2}'); do ip link delete dev $i; done

[javitonino]

I think I've made some progress with this, I think there were two separate issues.

On the one hand, if you had multiple DNS servers, they were not correctly imported. And then, the routing problems we discussed above. I released new versions of both the UI plugin and the connman plugin to try to address those.

After updating, you should restart connman-vpn (systemctl restart connman-vpn) and either reimport the config, or go to advanced settings of the VPN connection and change the DNS config so that the server addresses are separated by spaces (not commas). Also make sure that Use as default route is checked.

With all that done, I think it should work (it works for me on the same device and a similar setup).

If not, some troubleshooting ideas (it might be interesting to run these with the VPN connected and disconnected to look for differences):

Check if you have connectivity to the VPN server (by IP), to some other IP, and to some other host (by domain, to check DNS):

ping 193.187.91.203
ping 1.1.1.1
ping google.com

Also check that the routes are correct by running /sbin/ip route. With the VPN connected you should see a default route through the VPN device (default dev vpn0 scope link) and a route to the VPN server through your normal gateway (193.187.91.203 via 10.0.2.2 dev wlan0).

Finally, you can also check the WireGuard stats with wg show. If everything works, you should see a recent handshake and some amount of transfer both ways.

[eson57]

Thank you so much, it works very well. Much faster than the openvpn connection, from the same provider, I've been using for several years. :-)