This said, if I can run some useful tests (XA2 SFR), I’d do with pleasure.
Hi, have you checked that, like with https://ipleak.net/ ? I tested this only eleven days ago and had to roll back because that time CLAT implementation did not take account VPN at all. Maybe it is now fixed? I wrote a note of my ProtonVPN configuration (without CLAT) which currently leaks “only” IPv6, oh dear (please upvote in Proton forum requests to have IPv6 VPN!)
Hi, these changes did not include support for VPN yet. We’ll have to do that later. There are a few loose ends to check first before doing that. The previously done IPv6 leak prevention is one of those.
Looking good so far 
1 Like
I don’t think the XA2, or any other device than the 10iii, does the IPv6 only thing that required this CLAT implementation. But it’s always good to check for new bugs it may have introduced in other devices.
Yes, leaks with IPv6.
I have IPv6 disabled in all VPN configurations.
Tests on https://ipleak.net/ show different IPs, so for that, it seems to work.
I installed these packages on my XA2 due to a reverse-understanding 
of the subject (https://forum.sailfishos.org/t/4-5-0-18-french-operator-sfr-webradio-no-sound/14877/).
It is interresting to notice than afterwards, I could enable VPN again (was not working well since .18).
If nothing related to VPN was changed, it might be a coincidence or some side effect…
I think while implementing this CLAT stuff, Jussi has fixed a number of issues and inconsistencies in connman that may well improve things for lots of other uses and devices. We couldn’t tell you what in particular though 
And here is where my part comes in. As soon as this update is official, I’ll provide a list of all bug reports with network errors and we’ll be able to check if it solved or not.
3 Likes
I reckon that - from .18 - the following, VPN-related packages were replaced (among others) for me when I installed CLAT (and then rolled back to these) :
...
connman-plugin-vpn-l2tp-1.32+git193-1.18.1.jolla.aarch64
connman-plugin-vpn-openconnect-1.32+git193-1.18.1.jolla.aarch64
connman-plugin-vpn-openvpn-1.32+git193-1.18.1.jolla.aarch64
connman-plugin-vpn-pptp-1.32+git193-1.18.1.jolla.aarch64
connman-plugin-vpn-vpnc-1.32+git193-1.18.1.jolla.aarch64
...
If the (replacing) VPN-related connman packages - I did not take record of those - helped to make your buggy VPN connection available again, I think we all will profit one day to get the CLAT integrated (with VPN-support) in SFOS, so let’s keep helping this great project with our testing!
Those haven’t really changed - they’re just built with connman so get the same version number as that.
I encountered a new problem with this version. Sometimes after getting out of Wifi range the clat interface shiws up but the wlan0 interface does not get dropped and there is no internet access at all. Disabling WLAN solves this issue. After enabling wlan everything is still working.
I collected a log if this helps.
Today I tried hotspot with the latest version and it worked.
Long-term test will take place next Friday when I have another week’s night shift
1 Like
1.32+git194.1 (post devel merge of the original CLAT branch) now building. The aim now is to get VPN working over CLAT.
1 Like
I guess this is not related to CLAT changes but I’ll take a look on the logs. Any idea on the timecode when it happened? It would narrow down the search.
1 Like
A note for all: this is highly experimental. In theory it should work but without the possibility to test that it may be just complete either or.
1 Like
A little bit offtopic although I am not participating actively in this testing I am very happy to see this interactive development and testing cycle with the community. It would be great to see this for other areas of the OS that it makes sense → connman modification & test scenarios could be great to test things that have been plaguing the OS when switching between WiFi & Data and so on for example. Great work!
3 Likes
Sorry, if this happens again, i’ll rake a new log and check the time.
Installing the new clat version right now.
I just tested a VPN connection to a NordVPN Server, but there is no change in the ip addresses.
Logs sent to connman-debug@jolla.com: Tested w/ ProtonVPN: leaks IPv4 and IPv6 and DNS. w/ NordVPN: leaks (still, like 4.5.0.18) IPv6. In both, one can now turn on, in Advanced profile “Disable IPv6 Yes”, while before it was not possible, it did not connect. Now it connects w/ VPN but leaks IPv6.
Hotspot works as w/ earlier versions, OK but it takes loooonger time time to get on Internet (seen from the Win11 client) than if using a gulag phone as Hotspot for the same… Cannot tell if this because of CLAT (since before it did not work at all with 4.5.0.18…).
Keep up the good work!
4 Likes
No worries, we might need to tackle that WLAN issue in another scope anyways. There seems to be something to do with the WLAN on the X10 III. Just need to find out what.
The VPN fix was not then complete yet.
And after getting these logs - much appreciated! - it was evident what was wrong. The old implementation to remove routes in ConnMan was made only for host routes and when trying to remove the default route from clat interface when the VPN mode is set it just simply returned “ok” even though nothing could be done. Well, these things are common, apparently I fixed that later on only for IPv6.
There is now 1.32+git194.2 in the build that should address the issue of dropping the clat default route in case VPN is on. The logs show that the process does detect VPN correctly and hopefully now there is an improvement to the use and functionality.
And IPv6 will be unfortunately leaked when running an IPv4 VPN over CLAT that is using the IPv6 as transport. Dropping anything related to IPv6 in that case would, in theory, cripple the network. But one step at a time.
2 Likes
Apparently this is now built and is available for testing.