REPRODUCIBILITY (% or how often): Once
BUILD ID = OS VERSION (Settings > About product): 3.4.0.22
HARDWARE (Jolla1, Tablet, XA2,…): Sony XA2
UI LANGUAGE:English USA
REGRESSION: (compared to previous public release: Yes, No, ?):
DESCRIPTION:
VPN is losing credentials and after re-entering credentials, SFOS states that it is connected, however traffic is not going through the VPN
PRECONDITIONS:
Setup VPN through ProtonVPN ovpn file (working in prior version of SFOS)
STEPS TO REPRODUCE:
- Upgrade to SFOS v3.4.0.22
- Re-enter VPN credentials that worked in previous version
- SFOS reports that it is connected however traffic is not protected
EXPECTED RESULT:
ACTUAL RESULT:
ADDITIONAL INFORMATION:
I checked the new “set as default route” option in 3.4.0.22 and it the VPN was set as the default
1 Like
try to use the utilities app of for sfos, where it says restart the connectivity wlan, network and so on.
hope it helps
delocoyo, I think I may have found the problem. When I upgraded to 3.4.0.22, it may have re-enabled IPv6. I’m going to disable IPv6 and retest. I’ll let you know how it goes.
So it turns out the problem was that IPv6 was re-enabled after the upgrade and it was leaking my real IP. I disabled it and Bob’s your Uncle! Anyway, I’m sorry for the false alarm and thank you for your help! 
1 Like
how did you disable the ipv6?
Disable IPv6 using the following commands: devel-su sysctl -w net.ipv6.conf.all.disable_ipv6=1 and devel-su sysctl -w net.ipv6.conf.default.disable_ipv6=1
But I have found that after a reboot it, it loses the settings and re-enables IPv6. So, I have to issue the commands again 
Here is the full thread if you are interested. https://together.jolla.com/question/163103/how-to-protonvpn-on-sailfish-os/
1 Like
You can store these settings in a file in /etc/sysctl.d. Then they will survive a reboot.
2 Likes
Why false alarm? I would expect both IPs to be protected?
So I do not see this as ‘solved’ but worked around (so maybe reset the solution flag and link in OP to your workaround?). Let Jolla be aware of this.
martinh,
I found the sysctl.d folder (under: /etc/sysctl.d/) and added the first 4 lines to ipv6-settings.conf. However, IPv6 comes back after a reboot 
Can you tell me how I have offended the IPv6 Gods and how appease them? 
GNU nano 2.8.5 File: ipv6-settings.conf
Disable IPv6 to stop VPN leaks
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
Enable IPv6 tempaddress and prefer it
net.ipv6.conf.default.use_tempaddr = 2
net.ipv6.conf.all.use_tempaddr = 2
Disable icmp redirects
net.ipv6.conf.default.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
[ File 'ipv6-settings.conf' is unwritable ]
^G Get Help ^O Write Out ^W Where Is ^K Cut Text ^J Justify ^C Cur Pos
^X Exit ^R Read File ^\ Replace ^U Uncut Text^T To Spell ^_ Go To Line
Can you please clearly explain which four lines (I see three lines) has worked to solved the problem with reboot? Thank you
Hey Tinybit,
I wasn’t able to solve the reboot issue
I an pretty sure you know how to handle devel-su and nano and comment lines.
But from your post I see you used normal user to list content of /etc/sysctl.d/ipv6settings.conf.
And the new added lines look bold as the other comment lines which seems strange to me.
Another possible reason could be cr/lf issue in case you edited that file via ssh on Windoze?
I’m using a Debian based flavor called Parrot. And yeah, I used the admin account to edit the file and a normal user account to take the screenshot. So, I don’t know why the text got crazy when I copied and pasted into the forum but… c’est la vie.
And just for the record, I don’t use Windoze, sir! 
Allright! 
So then I do not know! 
And here are two more guesses:
- remove the multiple blank lines in between and leave only one (do not think so but just experience…)
- move the ‘disable ipv6’ section behind the ‘enable ipv6’ section
Just a few comments:
- I’ld rather not edit a configuration file managed by a system package, in this case
# rpm -qf ipv6-settings.conf
droid-config-h3113-0.2.65-1.17.40.jolla.armv7hl
In the best case it will be overwritten during upgrade, in the worst case an update will fail.
- A new file in that folder should end in
.conf, e.g.:
# cat > /etc/sysctl.d/ipv6_off.conf
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
CTRL-D to send EOF to cat and exit.
- To test your changes, use e.g.
# sysctl --system
...
* Applying /etc/sysctl.d/ipv6_off.conf ...
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
Post edited: It’s not systemctl --system but sysctl --system.
1 Like
Thanks. Makes sense.
But that still does not explain why those changes were not accepted 
We need an update on solution , otherwise I’ll have to re-flash back to 3.3 as not willing to use phone without VPN 
OK, here is what I did:
1.) Put the ipv6-settings.config file back to “stock”
2.) Created the ipv6_off.conf file in the /etc/sysctl.d directory as ROOT
3.) Ran the systemctl --system command as ROOT
4.) Rebooted
Unfortunately, my IPv6 address is still leaking through the VPN
1 Like
That’s hard to debug remotely. Some things come to mind…
# sysctl -a --pattern "disable_ipv6"
- … and
ifconfig?
On my device wlan0 still has a (link local) ipv6 address even with net.ipv6.conf.all.disable_ipv6 = 1.
- What does “Unfortunately, my IPv6 address is still leaking through the VPN” actually mean? How did you test that?
I’m not using openvpn here but it simply opens a tun or tap interface and routes traffic through that device, as e.g. ssh can do. You can check, if traffic to a certain address is properly routed by calling e.g.
# host www.google.com 9.9.9.9
Using domain server:
Name: 9.9.9.9
Address: 9.9.9.9#53
Aliases:
www.google.com has address 172.217.18.100
www.google.com has IPv6 address 2a00:1450:4001:801::2004
and with these addresses:
# ip route get 172.217.18.100
172.217.18.100 via 192.168.178.20 dev wlan0 src 192.168.178.46
cache
and
# ip route get 2a00:1450:4001:801::2004
#
Obviously the ipv4 address to Google is routed via wlan0 on my device and no route for ipv6. For you with enabled VPN it should be a tap or tun device, e.g. tun0.
1 Like
