But we sure made some nices suggestions to fix the problem from both sides. 
Weren’t there problems with Android Apps ignoring the VPN in former SFOS-Versions? That seems to be fixed at least for https.
Hey.
sorry for the late reply.
I have put the redirect-gateway line in my client config and now the traffic is indeed routed through the vpn. Thank you very much.
Is there a way to add this config line to the sailfish vpn-gui (maybe even manually through altering configfiles?).
I really don’t understand why those configs work on my other devices without this line, but well, fair enough.
I just realized a difference in the routing table when connecting through the sailfish-gui vs connecting by invoking openvpn from the command line (both using the same .ovpn file):Both routing tables are identical, except for the routing setup through the gui tries to setup and route all traffic through “vpn0”, while when invoking from the command line, a tun0 device is created and all traffic and routes are configured for tun0.While routing through vpn0 does not work (the traffic to networks outside the vpn is simply blocked), all works well through the tun0 device.Why is the gui utilizing vpn0 in favor to tun0, and how to fix this?
To ask in brief:
What is the difference between tun0 and vpn0?
And why is the tun0 device used when invoking openvpn from the command line, but vpn0 when invoking through the GUI? As described above, while tun0 works this doesn’t appear to be the case for vpn0?
vpn0 is presumably just an ifrenamed interface name for tun0, or more precisely, as ifrename is unavailable on stock SFOS, it’s renamed by ip link set tun0 name vpn0. It shouldn’t be functionally different.
I really don’t get the point.
The tun0 config works while the vpn0 config doesn’t.
Edit:
Whoops.
I just realized I’m missing the 128.0.0.0 route. How do I add that one? And what does it do at all?
As I said before, I’ve imported the same .ovpn file into the gui that works flawlessly from the command line…
It sets a route via tun0 for all target addresses starting with bit 1 set, which replaces half of the default route by being more specific. There should be a corresponding route for the other half, those with leading zeroes. This is a clever way of overriding a default route without altering it. The additional routes can be removed later, thus restoring the previous default route.
1 Like
All right , thanks for the explaination.
So it seems the sfos gui is not setting the routes properly?
Is this a bug or am I doing something wrong?
The SFOS GUI implementation replaces the default route, it does not override it.
On the other hand, in the GUI case (top image), you see a route to 0.0.0.0 without mask via vpn0 without a gateway (gw is 0.0.0.0 without the G flag). This is odd. It probably breaks any traffic except to those addresses having a more specific rule; or in other words, it may break the default route.
Thank you very much.
Yes, it breaks any traffic except for that routed to the connected vpn.
I played around a bit a figured out that this route is beeing set by the vpn-GUI when checking the standard-gateway option.
I have then unchecked this option and set two additional routes manually, to 0.0.0.0 and to 128.0.0.0 as in the command-line vpn.
Now I’m kind of half way through!
All traffic is indeed now routed through the vpn! At least, when I’m on a standard ipv4 internet connection.
When using an ipv6 connection (e.g. my wifi connection) the ipv6 adress of my phone is still visible. Is there any way to hide my ipv6 address/ mask it with my ipv4 address?
Btw the ipv6 ip is also visible when connected from the command line.
OpenVPN servers can be configured to be gateways for both IPv4 and IPv6 traffic at the same time, even default gateways. I set up some dual protocol gateways. They can even be set up to offer this service via IPv4 or IPv6 on the tunnel layer and tunnel IPv4 and IPv6, so whatever you have available, it’ll just work.
Client-side, it looks like this:
<connection>
remote 2abc:def1::add 1194 udp
[other connection specific configs]
</connection>
<connection>
remote 1.2.3.4 1194 udp
[other connection specific configs]
</connection>
It’s even easier to just provide a remote hostname that resolves to IPv4 and IPv6, but as you seem to be cautious, you would “leak” this DNS lookup then.
Thank you very much! I will read a bit further and play around a bit once I find the time
Hi! I hadn’t paid attention to this thread but I also had a lot of problems with OpenVPN since 3.2 (c.f. TJC thread)
On my side, if I only set the routes as “User routes” in the GUI, browser traffic doesn’t go through the VPN.
If I set routes only in the config file, there is no traffic at all in the browser.
What currently works for me is, in the .ovpn file:
route 0.0.0.0 128.0.0.0
route 128.0.0.0 128.0.0.0
And in the GUI:
0.0.0.0 / 128.0.0.0 / 10.8.0.1
128.0.0.0 / 128.0.0.0 / 10.8.0.1
With this setup, when I look at the “Details” of the connection, I see 2 additional “User route” and 2 additional “Server route”, and web traffic goes correctly through the VPN
I ended up with this config after many unsuccessful tries and I have to admit that I didn’t take enough time to understand deeply how it is supposed to be configured, please let me know if you see something obviously wrong 
This is exactly the setting I did except for a different gateway.
Edit: I didn’t set any dedicated server routes, just the push redirect -gateway settings mentioned above.
Hi,
were you able to resolve this issue?
I use ONE openvpn server config serving 1 Linux box and 2 Sailfish phones. The client configurations are the same (except for the certificates), however, I cannot ping from my server to the phones.
Pinging the Linux box works both ways.
I am stuck here.
If you ping members of a VPN, you should exclusively use their VPN addresses, not their public ones.
Good idea, thank you, however I ping only the VPN adresses.
Server has got 10.8.0.1 and the clients (mostly Linux boxes) 10.8.0.3, 10.8.0.2, etc.
What I found when I check for the routes (route -n command) in the Xperia (latest public release (4.0)) is that there is one line with only 0.0.0.0 adresses - for IP, gateway, and netmask - that seems to be odd.
By the way, the same phenomenon can be found in my older Jolla 1 phone running version 3 of Sailfish OS.
Martin.
Hi.
Your problem with ping may be the consequence of blocking by the firewall inside your Jolla devices.
Take a look at the files inside the folder:
/etc/connman/firewall.d
I’m not familiar with firewall configurations, but there’s a file called:
10-block-icmp-firewall.conf
Maybe this can help you with your issues.
I’ve modified the file:
00-devmode-firewall.conf
so that I can ssh into my devices through the VPN connection. I added the following lines:
[vpn]
IPv4.INPUT.RULES = -p tcp -m tcp --dport 22 -j ACCEPT
IPv6.INPUT.RULES = -p tcp -m tcp --dport 22 -j ACCEPT
At the end of the file and restarted connman.service to make then work.
Best regards.
I could stop the DNS leak by opening general Android settings
apkd-launcher com.android.settings/com.android.settings.Settings
and then entering the DNS (doh.mullvad.net in my case) in the network settings. But it does not accept IP addresses there. Only domain names.
1 Like