We have moved to a new Sailfish OS Forum. Please start new discussions there.
1 | initial version | posted 2017-02-09 10:48:33 +0200 |
ahem this title is for provocational purposes only.
I am using (open) vpn connections for a long time now - even with SailfishOS and want to reveal some problems which IMHO must be shown because it is a very very nasty security issue - especially in countries where such a bug may cost your life (sorry to say but some of the BRICS -> e.g. the C or R). It is not only a problem of your device it is also a problem of your vpn server side! And it is not only a problem of openvpn - the fritzbox stuff does the same.
Scenario: You have an (open-)vpn server at home and you are visiting a friend with a dual stack network (so he has ipv4 and ipv6). Do not ask your friend (if he is no nerd) if he has ipv6 - he does not know. But several providers just switch v6 on (e.g. Germany's Telekom) do not have ipv4 at all and do ds-lite (Germany: unity media) or you run around a modern conference with a v6-stack only (FOSSDEM - but then it will not work at all...) or dual stack and you cannot trust the other people around like congresses in Germany's late winter time... Probably your LTE-Provider does dual stack too!
assuming your vpn works (so all bugs of the beta are fixed for sailfishos). You configure your network that the default gateway is your tunnel, because you want all your traffic go through the tunnel. You can ping your private machines and a traceroute/tracepath to all known 8.8.8.8 goes through the tunnel. Everything is fine.
Everything? Hm...
What will you see? https://google.com will not go through your tunnel.
For me it does but...
... you must start openvpn direct - this does not work with conman actually - and you need to prepare the openvpn server. And: the same will occur if you do some tunnel to your fritz box or most of the tunnels around with every device you see.
Same problem will occur with facebook, apple or many other sites, probably 20% of all sites now.
Why?
... to be continued ...
2 | No.2 Revision |
ahem this title is for provocational purposes only.
I am using (open) vpn connections for a long time now - even with SailfishOS and want to reveal some problems which IMHO must be shown because it is a very very nasty security issue - especially in countries where such a bug may cost your life (sorry to say but some of the BRICS -> e.g. the C or R). It is not only a problem of your device it is also a problem of your vpn server side! And it is not only a problem of openvpn - the fritzbox stuff does the same.
Scenario: You have an (open-)vpn server at home and you are visiting a friend with a dual stack network (so he has ipv4 and ipv6). Do not ask your friend (if he is no nerd) if he has ipv6 - he does not know. But several providers just switch v6 on (e.g. Germany's Telekom) do not have ipv4 at all and do ds-lite (Germany: unity media) or you run around a modern conference with a v6-stack only (FOSSDEM - but then it will not work at all...) or dual stack and you cannot trust the other people around like congresses in Germany's late winter time... Probably your LTE-Provider does dual stack too!
assuming your vpn works (so all bugs of the beta are fixed for sailfishos). You configure your network that the default gateway is your tunnel, because you want all your traffic go through the tunnel. You can ping your private machines and a traceroute/tracepath to all known 8.8.8.8 goes through the tunnel. Everything is fine.
Everything? Hm...
What will you see? https://google.com will not go through your tunnel.
For me it does but...
... you must start openvpn direct - this does not work with conman actually actually, it cannot handle all possible openvpn configuration statements - and you need to prepare the openvpn server. And: the same will occur if you do some tunnel to your fritz box or most of the tunnels around with every device you see.
Same problem will occur with facebook, apple or many other sites, probably 20% of all sites now.
Why?
... to be continued ...
3 | No.3 Revision |
ahem this title is for provocational purposes only.
I am using (open) vpn connections for a long time now - even with SailfishOS and want to reveal some problems which IMHO must be shown because it is a very very nasty security issue - especially in countries where such a bug may cost your life (sorry to say but some of the BRICS -> e.g. the C or R). It is not only a problem of your device it is also a problem of your vpn server side! And it is not only a problem of openvpn - the fritzbox stuff does the same.
Scenario: You have an (open-)vpn server at home and you are visiting a friend with a dual stack network (so he has ipv4 and ipv6). Do not ask your friend (if he is no nerd) if he has ipv6 - he does not know. But several providers just switch v6 on (e.g. Germany's Telekom) do not have ipv4 at all and do ds-lite (Germany: unity media) or you run around a modern conference with a v6-stack only (FOSSDEM - but then it will not work at all...) or dual stack and you cannot trust the other people around like congresses in Germany's late winter time... Probably your LTE-Provider does dual stack too!
assuming your vpn works (so all bugs of the beta are fixed for sailfishos). You configure your network that the default gateway is your tunnel, because you want all your traffic go through the tunnel. You can ping your private machines and a traceroute/tracepath to all known 8.8.8.8 goes through the tunnel. Everything is fine.
Everything? Hm...
What will you see? https://google.com will not go through your tunnel.
For me it does but...
... you must start openvpn direct - this does not work with conman actually, it cannot handle all possible openvpn configuration statements - and you need to prepare the openvpn server. And: the same will occur if you do some tunnel to your fritz box or most of the tunnels around with every device you see.
Same problem will occur with facebook, apple or many other sites, probably 20% of all sites now.
Why?
... to be continued ...
Part 2 - Dual Stack
Yes, the main problem is dual stack. If you prepare a tunnel for ipv4 then you build up a routing for ipv4. You will not change anything for ipv6. There all routes are still going to the default gateway.
When you do an DNS resolving you get two addresses for e. g. google.com:
~$ host google.com
google.com has address 172.217.23.142
google.com has IPv6 address 2a00:1450:4001:818::200e
...
and modern operating systems try to use ipv6 priorized. For mobile devices it is done by a brutal force method today:
but if a big player address is resolved (google, facebook, apple...) the v6 address will win. And because the v6 resolving is not changed all data will flow through the default gateway for v6 which has nothing to do with your v4 traffic.
... what can I do now?
Part 3 solutions
When designing vpn connections you now have the problem how to make it secure for the end user who thinks that everything is fine.
and Jolla?
... to be continued
4 | No.4 Revision |
ahem this title is for provocational purposes only.
I am using (open) vpn connections for a long time now - even with SailfishOS and want to reveal some problems which IMHO must be shown because it is a very very nasty security issue - especially in countries where such a bug may cost your life (sorry to say but some of the BRICS -> e.g. the C or R). It is not only a problem of your device it is also a problem of your vpn server side! And it is not only a problem of openvpn - the fritzbox stuff does the same.
Scenario: You have an (open-)vpn server at home and you are visiting a friend with a dual stack network (so he has ipv4 and ipv6). Do not ask your friend (if he is no nerd) if he has ipv6 - he does not know. But several providers just switch v6 on (e.g. Germany's Telekom) do not have ipv4 at all and do ds-lite (Germany: unity media) or you run around a modern conference with a v6-stack only (FOSSDEM - but then it will not work at all...) or dual stack and you cannot trust the other people around like congresses in Germany's late winter time... Probably your LTE-Provider does dual stack too!
assuming your vpn works (so all bugs of the beta are fixed for sailfishos). You configure your network that the default gateway is your tunnel, because you want all your traffic go through the tunnel. You can ping your private machines and a traceroute/tracepath to all known 8.8.8.8 goes through the tunnel. Everything is fine.
Everything? Hm...
What will you see? https://google.com will not go through your tunnel.
For me it does but...
... you must start openvpn direct - this does not work with conman actually, it cannot handle all possible openvpn configuration statements - and you need to prepare the openvpn server. And: the same will occur if you do some tunnel to your fritz box or most of the tunnels around with every device you see.
Same problem will occur with facebook, apple or many other sites, probably 20% of all sites now.
Why?
... to be continued ...
Part 2 - Dual Stack
Yes, the main problem is dual stack. If you prepare a tunnel for ipv4 then you build up a routing for ipv4. You will not change anything for ipv6. There all routes are still going to the default gateway.
When you do an DNS resolving you get two addresses for e. g. google.com:
~$ host google.com
google.com has address 172.217.23.142
google.com has IPv6 address 2a00:1450:4001:818::200e
...
and modern operating systems try to use ipv6 priorized. For mobile devices it is done by a brutal force method today:
but if a big player address is resolved (google, facebook, apple...) the v6 address will win. And because the v6 resolving is not changed all data will flow through the default gateway for v6 which has nothing to do with your v4 traffic.
... what can I do now?
Part 3 solutions
When designing vpn connections you now have the problem how to make it secure for the end user who thinks that everything is fine.
and Jolla?
... to be continued
5 | No.5 Revision |
ahem this title is for provocational purposes only.
I am using (open) vpn connections for a long time now - even with SailfishOS and want to reveal some problems which IMHO must be shown because it is a very very nasty security issue - especially in countries where such a bug may cost your life (sorry to say but some of the BRICS -> e.g. the C or R). It is not only a problem of your device it is also a problem of your vpn server side! And it is not only a problem of openvpn - the fritzbox stuff does the same.
Scenario: You have an (open-)vpn server at home and you are visiting a friend with a dual stack network (so he has ipv4 and ipv6). Do not ask your friend (if he is no nerd) if he has ipv6 - he does not know. But several providers just switch v6 on (e.g. Germany's Telekom) do not have ipv4 at all and do ds-lite (Germany: unity media) or you run around a modern conference with a v6-stack only (FOSSDEM - but then it will not work at all...) or dual stack and you cannot trust the other people around like congresses in Germany's late winter time... Probably your LTE-Provider does dual stack too!
assuming your vpn works (so all bugs of the beta are fixed for sailfishos). You configure your network that the default gateway is your tunnel, because you want all your traffic go through the tunnel. You can ping your private machines and a traceroute/tracepath to all known 8.8.8.8 goes through the tunnel. Everything is fine.
Everything? Hm...
What will you see? https://google.com will not go through your tunnel.
For me it does but...
... you must start openvpn direct - this does not work with conman actually, it cannot handle all possible openvpn configuration statements - and you need to prepare the openvpn server. And: the same will occur if you do some tunnel to your fritz box or most of the tunnels around with every device you see.
Same problem will occur with facebook, apple or many other sites, probably 20% of all sites now.
Why?
... to be continued ...
Part 2 - Dual Stack
Yes, the main problem is dual stack. If you prepare a tunnel for ipv4 then you build up a routing for ipv4. You will not change anything for ipv6. There all routes are still going to the default gateway.
When you do an DNS resolving you get two addresses for e. g. google.com:
~$ host google.com
google.com has address 172.217.23.142
google.com has IPv6 address 2a00:1450:4001:818::200e
...
and modern operating systems try to use ipv6 priorized. For mobile devices it is done by a brutal force method today:
but if a big player address is resolved (google, facebook, apple...) the v6 address will win. And because the v6 resolving is not changed all data will flow through the default gateway for v6 which has nothing to do with your v4 traffic.
... what can I do now?
Part 3 solutions
When designing vpn connections you now have the problem how to make it secure for the end user who thinks that everything is fine.
and Jolla?
... to be continued
6 | No.6 Revision |
ahem this title is for provocational purposes only.
I am using (open) vpn connections for a long time now - even with SailfishOS and want to reveal some problems which IMHO must be shown because it is a very very nasty security issue - especially in countries where such a bug may cost your life (sorry to say but some of the BRICS -> e.g. the C or R). It is not only a problem of your device it is also a problem of your vpn server side! And it is not only a problem of openvpn - the fritzbox stuff does the same.
Scenario: You have an (open-)vpn server at home and you are visiting a friend with a dual stack network (so he has ipv4 and ipv6). Do not ask your friend (if he is no nerd) if he has ipv6 - he does not know. But several providers just switch v6 on (e.g. Germany's Telekom) do not have ipv4 at all and do ds-lite (Germany: unity media) or you run around a modern conference with a v6-stack only (FOSSDEM - but then it will not work at all...) or dual stack and you cannot trust the other people around like congresses in Germany's late winter time... Probably your LTE-Provider does dual stack too!
assuming your vpn works (so all bugs of the beta are fixed for sailfishos). You configure your network that the default gateway is your tunnel, because you want all your traffic go through the tunnel. You can ping your private machines and a traceroute/tracepath to all known 8.8.8.8 goes through the tunnel. Everything is fine.
Everything? Hm...
What will you see? https://google.com will not go through your tunnel.
For me it does but...
... you must start openvpn direct - this does not work with conman actually, it cannot handle all possible openvpn configuration statements - and you need to prepare the openvpn server. And: the same will occur if you do some tunnel to your fritz box or most of the tunnels around with every device you see.
Same problem will occur with facebook, apple or many other sites, probably 20% of all sites now.
Why?
... to be continued ...
Part 2 - Dual Stack
Yes, the main problem is dual stack. If you prepare a tunnel for ipv4 then you build up a routing for ipv4. You will not change anything for ipv6. There all routes are still going to the default gateway.
When you do an DNS resolving you get two addresses for e. g. google.com:
~$ host google.com
google.com has address 172.217.23.142
google.com has IPv6 address 2a00:1450:4001:818::200e
...
and modern operating systems try to use ipv6 priorized. For mobile devices it is done by a brutal force method today:
but if a big player address is resolved (google, facebook, apple...) the v6 address will win. And because the v6 resolving is not changed all data will flow through the default gateway for v6 which has nothing to do with your v4 traffic.
... what can I do now?
Part 3 solutions
When designing vpn connections you now have the problem how to make it secure for the end user who thinks that everything is fine.
and Jolla?
... to be continued
7 | No.7 Revision |
ahem this title is for provocational purposes only.
I am using (open) vpn connections for a long time now - even with SailfishOS and want to reveal some problems which IMHO must be shown because it is a very very nasty security issue - especially in countries where such a bug may cost your life (sorry to say but some of the BRICS -> e.g. the C or R). It is not only a problem of your device it is also a problem of your vpn server side! And it is not only a problem of openvpn - the fritzbox stuff does the same.
Scenario: You have an (open-)vpn server at home and you are visiting a friend with a dual stack network (so he has ipv4 and ipv6). Do not ask your friend (if he is no nerd) if he has ipv6 - he does not know. But several providers just switch v6 on (e.g. Germany's Telekom) do not have ipv4 at all and do ds-lite (Germany: unity media) or you run around a modern conference with a v6-stack only (FOSSDEM - but then it will not work at all...) or dual stack and you cannot trust the other people around like congresses in Germany's late winter time... Probably your LTE-Provider does dual stack too!
assuming your vpn works (so all bugs of the beta are fixed for sailfishos). You configure your network that the default gateway is your tunnel, because you want all your traffic go through the tunnel. You can ping your private machines and a traceroute/tracepath to all known 8.8.8.8 goes through the tunnel. Everything is fine.
Everything? Hm...
What will you see? https://google.com will not go through your tunnel.
For me it does but...
... you must start openvpn direct - this does not work with conman actually, it cannot handle all possible openvpn configuration statements - and you need to prepare the openvpn server. And: the same will occur if you do some tunnel to your fritz box or most of the tunnels around with every device you see.
Same problem will occur with facebook, apple or many other sites, probably 20% of all sites now.
Why?
... to be continued ...
Part 2 - Dual Stack
Yes, the main problem is dual stack. If you prepare a tunnel for ipv4 then you build up a routing for ipv4. You will not change anything for ipv6. There all routes are still going to the default gateway.
When you do an DNS resolving you get two addresses for e. g. google.com:
~$ host google.com
google.com has address 172.217.23.142
google.com has IPv6 address 2a00:1450:4001:818::200e
...
and modern operating systems try to use ipv6 priorized. For mobile devices it is done by a brutal force method today:
but if a big player address is resolved (google, facebook, apple...) the v6 address will win. And because the v6 resolving is not changed all data will flow through the default gateway for v6 which has nothing to do with your v4 traffic.
... what can I do now?
Part 3 solutions
When designing vpn connections you now have the problem how to make it secure for the end user who thinks that everything is fine.
and Jolla?
... to be continued
8 | No.8 Revision |
ahem this title is for provocational purposes only.tl;dr - there are problems with ipv6, dns resolving, and design with the new vpn gui/connman.
I am using (open) vpn connections for a long time now - even with SailfishOS and want to reveal some problems which IMHO must be shown because it is a very very nasty security issue - especially in countries where such a bug may cost your life (sorry to say but some of the BRICS -> e.g. the C or R). It is not only a problem of your device it is also a problem of your vpn server side! And it is not only a problem of openvpn - the fritzbox stuff does the same.
Scenario: You have an (open-)vpn server at home and you are visiting a friend with a dual stack network (so he has ipv4 and ipv6). Do not ask your friend (if he is no nerd) if he has ipv6 - he does not know. But several providers just switch v6 on (e.g. Germany's Telekom) do not have ipv4 at all and do ds-lite (Germany: unity media) or you run around a modern conference with a v6-stack only (FOSSDEM - but then it will not work at all...) or dual stack and you cannot trust the other people around like congresses in Germany's late winter time... Probably your LTE-Provider does dual stack too!
assuming your vpn works (so all bugs of the beta are fixed for sailfishos). You configure your network that the default gateway is your tunnel, because you want all your traffic go through the tunnel. You can ping your private machines and a traceroute/tracepath to all known 8.8.8.8 goes through the tunnel. Everything is fine.
Everything? Hm...
What will you see? https://google.com will not go through your tunnel.
For me it does but...
... you must start openvpn direct - this does not work with conman actually, it cannot handle all possible openvpn configuration statements - and you need to prepare the openvpn server. And: the same will occur if you do some tunnel to your fritz box or most of the tunnels around with every device you see.
Same problem will occur with facebook, apple or many other sites, probably 20% of all sites now.
Why?
... to be continued ...
Part 2 - Dual Stack
Yes, the main problem is dual stack. If you prepare a tunnel for ipv4 then you build up a routing for ipv4. You will not change anything for ipv6. There all routes are still going to the default gateway.
When you do an DNS resolving you get two addresses for e. g. google.com:
~$ host google.com
google.com has address 172.217.23.142
google.com has IPv6 address 2a00:1450:4001:818::200e
...
and modern operating systems try to use ipv6 priorized. For mobile devices it is done by a brutal force method today:
but if a big player address is resolved (google, facebook, apple...) the v6 address will win. And because the v6 resolving is not changed all data will flow through the default gateway for v6 which has nothing to do with your v4 traffic.
... what can I do now?
Part 3 solutions
When designing vpn connections you now have the problem how to make it secure for the end user who thinks that everything is fine.
and Jolla?
... to be continued
Part 4 network connection managers
to build up a consistent network controling system desktop and mobile operating systems use some network/connection managers. The desktop systems prefer NetworkManager and for SailfishOS it is connman.
These managers handle the connection to the different networks (wlan, gsm...) and also the background stuff like dhcp handling, switching dns server configurations and reconnecting on moving devices. They also have the possibility to build up different types of vpns. But there are simpler managing systems too, like e.g. the configuration system of openwrt.
If you compare NetworkManager, connman, and openwrt then all of these systems try to put a set of configuration parameters from the configuration gui to the tunnel system. Whereas NetworkManger has a quite complete set of configuration parameters connman just implements parts of the set, as openwrt.
But with openwrt it is possible to leave the configuration empty and include an .ovpn file to just hand this file out to openvpn with no changes. It looks like connman is doing the same but in reality it interprets the file, fills it's own parameter set and starts up openvpn, vpnc, ipsec... The new sailfiish gui makes it possible to set an vpnc file to import but this is a real parameter import and all parameters which are unknown are ignored (without any warning). So it is not possible to just define a .vpnc file and let connman just call it. It is not possible to just use an .ovpn file which works if you use it by a simple devel-su openvpn myfile.ovpn
. The last does not work well because a network managing system must know everything about the network. If you do something without the manager disconnection and undefined network configurations are possible.
But if you are able to put the whole parameter set into the manager you must build on an error less implementation of the manager. It must e. g. handle resolv.conf parameters well (this is buggy with connman -> https://together.jolla.com/question/132993/openvpn-dhcp-option-dns-not-working/). This is needed to resolve internal servers behind the vpn tunnel. This could also be used to resolv v4 hosts only -> another possibillity for handling out v4 stuff only.
Part 5 wishlist
So then my little wishlist: It would be nice to
9 | No.9 Revision |
tl;dr - there are problems with ipv6, dns resolving, and design with the new vpn gui/connman.
I am using (open) vpn connections for a long time now - even with SailfishOS and want to reveal some problems which IMHO must be shown because it is a very very nasty security issue - especially in countries where such a bug may cost your life (sorry to say but some of the BRICS -> e.g. the C or R). It is not only a problem of your device it is also a problem of your vpn server side! And it is not only a problem of openvpn - the fritzbox stuff does the same.
Scenario: You have an (open-)vpn server at home and you are visiting a friend with a dual stack network (so he has ipv4 and ipv6). Do not ask your friend (if he is no nerd) if he has ipv6 - he does not know. But several providers just switch v6 on (e.g. Germany's Telekom) do not have ipv4 at all and do ds-lite (Germany: unity media) or you run around a modern conference with a v6-stack only (FOSSDEM - but then it will not work at all...) or dual stack and you cannot trust the other people around like congresses in Germany's late winter time... Probably your LTE-Provider does dual stack too!
assuming your vpn works (so all bugs of the beta are fixed for sailfishos). You configure your network that the default gateway is your tunnel, because you want all your traffic go through the tunnel. You can ping your private machines and a traceroute/tracepath to all known 8.8.8.8 goes through the tunnel. Everything is fine.
Everything? Hm...
What will you see? https://google.com will not go through your tunnel.
For me it does but...
... you must start openvpn direct - this does not work with conman actually, it cannot handle all possible openvpn configuration statements - and you need to prepare the openvpn server. And: the same will occur if you do some tunnel to your fritz box or most of the tunnels around with every device you see.
Same problem will occur with facebook, apple or many other sites, probably 20% of all sites now.
Why?
... to be continued ...
Part 2 - Dual Stack
Yes, the main problem is dual stack. If you prepare a tunnel for ipv4 then you build up a routing for ipv4. You will not change anything for ipv6. There all routes are still going to the default gateway.
When you do an DNS resolving you get two addresses for e. g. google.com:
~$ host google.com
google.com has address 172.217.23.142
google.com has IPv6 address 2a00:1450:4001:818::200e
...
and modern operating systems try to use ipv6 priorized. For mobile devices it is done by a brutal force method today:
but if a big player address is resolved (google, facebook, apple...) the v6 address will win. And because the v6 resolving is not changed all data will flow through the default gateway for v6 which has nothing to do with your v4 traffic.
... what can I do now?
Part 3 solutions
When designing vpn connections you now have the problem how to make it secure for the end user who thinks that everything is fine.
and Jolla?
... to be continued
Part 4 network connection managers
to build up a consistent network controling system desktop and mobile operating systems use some network/connection managers. The desktop systems prefer NetworkManager and for SailfishOS it is connman.
These managers handle the connection to the different networks (wlan, gsm...) and also the background stuff like dhcp handling, switching dns server configurations and reconnecting on moving devices. They also have the possibility to build up different types of vpns. But there are simpler managing systems too, like e.g. the configuration system of openwrt.
If you compare NetworkManager, connman, and openwrt then all of these systems try to put a set of configuration parameters from the configuration gui to the tunnel system. Whereas NetworkManger has a quite complete set of configuration parameters connman just implements parts of the set, as openwrt.
But with openwrt it is possible to leave the configuration empty and include an .ovpn file to just hand this file out to openvpn with no changes. It looks like connman is doing the same but in reality it interprets the file, fills it's own parameter set and starts up openvpn, vpnc, ipsec... The new sailfiish gui makes it possible to set an vpnc file to import but this is a real parameter import and all parameters which are unknown are ignored (without any warning). So it is not possible to just define a .vpnc file and let connman just call it. It is not possible to just use an .ovpn file which works if you use it by a simple devel-su openvpn myfile.ovpn
. The last does not work well because a network managing system must know everything about the network. If you do something without the manager disconnection and undefined network configurations are possible.
But if you are able to put the whole parameter set into the manager you must build on an error less implementation of the manager. It must e. g. handle resolv.conf parameters well (this is buggy with connman -> https://together.jolla.com/question/132993/openvpn-dhcp-option-dns-not-working/). This is needed to resolve internal servers behind the vpn tunnel. This could also be used to resolv v4 hosts only -> another possibillity for handling out v4 stuff only.
Part 5 wishlist
So then my little wishlist: It would be nice to
[end of long article] This is a wiki. feel free for more design brainstorming
10 | No.10 Revision |
tl;dr - there are problems with ipv6, dns resolving, and design with the new vpn gui/connman.
I am using (open) vpn connections for a long time now - even with SailfishOS and want to reveal some problems which IMHO must be shown because it is a very very nasty security issue - especially in countries where such a bug may cost your life (sorry to say but some of the BRICS -> e.g. the C or R). It is not only a problem of your device it is also a problem of your vpn server side! And it is not only a problem of openvpn - the fritzbox stuff does the same.
Scenario: You have an (open-)vpn server at home and you are visiting a friend with a dual stack network (so he has ipv4 and ipv6). Do not ask your friend (if he is no nerd) if he has ipv6 - he does not know. But several providers just switch v6 on (e.g. Germany's Telekom) do not have ipv4 at all and do ds-lite (Germany: unity media) or you run around a modern conference with a v6-stack only (FOSSDEM - but then it will not work at all...) or dual stack and you cannot trust the other people around like congresses in Germany's late winter time... Probably your LTE-Provider does dual stack too!
assuming your vpn works (so all bugs of the beta are fixed for sailfishos). You configure your network that the default gateway is your tunnel, because you want all your traffic go through the tunnel. You can ping your private machines and a traceroute/tracepath to all known 8.8.8.8 goes through the tunnel. Everything is fine.
Everything? Hm...
What will you see? https://google.com will not go through your tunnel.
For me it does but...
... you must start openvpn direct - this does not work with conman actually, it cannot handle all possible openvpn configuration statements - and you need to prepare the openvpn server. And: the same will occur if you do some tunnel to your fritz box or most of the tunnels around with every device you see.
Same problem will occur with facebook, apple or many other sites, probably 20% of all sites now.
Why?
... to be continued ...
Part 2 - Dual Stack
Yes, the main problem is dual stack. If you prepare a tunnel for ipv4 then you build up a routing for ipv4. You will not change anything for ipv6. There all routes are still going to the default gateway.
When you do an DNS resolving you get two addresses for e. g. google.com:
~$ host google.com
google.com has address 172.217.23.142
google.com has IPv6 address 2a00:1450:4001:818::200e
...
and modern operating systems try to use ipv6 priorized. For mobile devices it is done by a brutal force method today:
but if a big player address is resolved (google, facebook, apple...) the v6 address will win. And because the v6 resolving is not changed all data will flow through the default gateway for v6 which has nothing to do with your v4 traffic.
... what can I do now?
Part 3 solutions
When designing vpn connections you now have the problem how to make it secure for the end user who thinks that everything is fine.
and Jolla?
... to be continued
Part 4 network connection managers
to build up a consistent network controling system desktop and mobile operating systems use some network/connection managers. The desktop systems prefer NetworkManager and for SailfishOS it is connman.
These managers handle the connection to the different networks (wlan, gsm...) and also the background stuff like dhcp handling, switching dns server configurations and reconnecting on moving devices. They also have the possibility to build up different types of vpns. But there are simpler managing systems too, like e.g. the configuration system of openwrt.
If you compare NetworkManager, connman, and openwrt then all of these systems try to put a set of configuration parameters from the configuration gui to the tunnel system. Whereas NetworkManger has a quite complete set of configuration parameters connman just implements parts of the set, as openwrt.
But with openwrt it is possible to leave the configuration empty and include an .ovpn file to just hand this file out to openvpn with no changes. It looks like connman is doing the same but in reality it interprets the file, fills it's own parameter set and starts up openvpn, vpnc, ipsec... The new sailfiish gui makes it possible to set an vpnc file to import but this is a real parameter import and all parameters which are unknown are ignored (without any warning). So it is not possible to just define a .vpnc file and let connman just call it. It is not possible to just use an .ovpn file which works if you use it by a simple devel-su openvpn myfile.ovpn
. The last does not work well because a network managing system must know everything about the network. If you do something without the manager disconnection and undefined network configurations are possible.
But if you are able to put the whole parameter set into the manager you must build on an error less implementation of the manager. It must e. g. handle resolv.conf parameters well (this is buggy with connman -> https://together.jolla.com/question/132993/openvpn-dhcp-option-dns-not-working/). This is needed to resolve internal servers behind the vpn tunnel. This could also be used to resolv v4 hosts only -> another possibillity for handling out v4 stuff only.
Part 5 wishlist
So then my little wishlist: It would be nice to
[end of long article] This is a wiki. feel free for more design brainstorming
11 | No.11 Revision |
tl;dr - there are problems with ipv6, dns resolving, and design with the new vpn gui/connman.
I am using (open) vpn connections for a long time now - even with SailfishOS and want to reveal some problems which IMHO must be shown because it is a very very nasty security issue - especially in countries where such a bug may cost your life (sorry to say but some of the BRICS -> e.g. the C or R). It is not only a problem of your device it is also a problem of your vpn server side! And it is not only a problem of openvpn - the fritzbox stuff does the same.
Scenario: You have an (open-)vpn server at home and you are visiting a friend with a dual stack network (so he has ipv4 and ipv6). Do not ask your friend (if he is no nerd) if he has ipv6 - he does not know. But several providers just switch v6 on (e.g. Germany's Telekom) do not have ipv4 at all and do ds-lite (Germany: unity media) or you run around a modern conference with a v6-stack only (FOSSDEM - but then it will not work at all...) or dual stack and you cannot trust the other people around like congresses in Germany's late winter time... Probably your LTE-Provider does dual stack too!
assuming your vpn works (so all bugs of the beta are fixed for sailfishos). You configure your network that the default gateway is your tunnel, because you want all your traffic go through the tunnel. You can ping your private machines and a traceroute/tracepath to all known 8.8.8.8 goes through the tunnel. Everything is fine.
Everything? Hm...
What will you see? https://google.com will not go through your tunnel.
For me it does but...
... you must start openvpn direct - this does not work with conman actually, it cannot handle all possible openvpn configuration statements - and you need to prepare the openvpn server. And: the same will occur if you do some tunnel to your fritz box or most of the tunnels around with every device you see.
Same problem will occur with facebook, apple or many other sites, probably 20% of all sites now.
Why?
... to be continued ...
Part 2 - Dual Stack
Yes, the main problem is dual stack. If you prepare a tunnel for ipv4 then you build up a routing for ipv4. You will not change anything for ipv6. There all routes are still going to the default gateway.
When you do an DNS resolving you get two addresses for e. g. google.com:
~$ host google.com
google.com has address 172.217.23.142
google.com has IPv6 address 2a00:1450:4001:818::200e
...
and modern operating systems try to use ipv6 priorized. For mobile devices it is done by a brutal force method today:
but if a big player address is resolved (google, facebook, apple...) the v6 address will win. And because the v6 resolving is not changed all data will flow through the default gateway for v6 which has nothing to do with your v4 traffic.
... what can I do now?
Part 3 solutions
When designing vpn connections you now have the problem how to make it secure for the end user who thinks that everything is fine.
and Jolla?
... to be continued
Part 4 network connection managers
to build up a consistent network controling system desktop and mobile operating systems use some network/connection managers. The desktop systems prefer NetworkManager and for SailfishOS it is connman.
These managers handle the connection to the different networks (wlan, gsm...) and also the background stuff like dhcp handling, switching dns server configurations and reconnecting on moving devices. They also have the possibility to build up different types of vpns. But there are simpler managing systems too, like e.g. the configuration system of openwrt.
If you compare NetworkManager, connman, and openwrt then all of these systems try to put a set of configuration parameters from the configuration gui to the tunnel system. Whereas NetworkManger has a quite complete set of configuration parameters connman just implements parts of the set, as openwrt.
But with openwrt it is possible to leave the configuration empty and include an .ovpn file to just hand this file out to openvpn with no changes. It looks like connman is doing the same but in reality it interprets the file, fills it's own parameter set and starts up openvpn, vpnc, ipsec... It ignores parameters it does not know! The new sailfiish gui makes it possible to set an vpnc file to import but this is a real parameter import and all parameters which are unknown are ignored (without any warning). So it is not possible to just define a .vpnc file and let connman just call it. It is not possible to just use an .ovpn file which works if you use it by a simple devel-su openvpn myfile.ovpn
. The last does not work well because a network managing system must know everything about the network. If you do something without the manager disconnection and undefined network configurations are possible.
But if you are able to put the whole parameter set into the manager you must build on an error less implementation of the manager. It must e. g. handle resolv.conf parameters well (this is buggy with connman -> https://together.jolla.com/question/132993/openvpn-dhcp-option-dns-not-working/). This is needed to resolve internal servers behind the vpn tunnel. This could also be used to resolv v4 hosts only -> another possibillity for handling out v4 stuff only.
Part 5 wishlist
So then my little wishlist: It would be nice to
[end of long article] This is a wiki. feel free for more design brainstorming
12 | No.12 Revision |
tl;dr - there are problems with ipv6, dns resolving, and design with the new vpn gui/connman.
I am using (open) vpn connections for a long time now - even with SailfishOS and want to reveal some problems which IMHO must be shown because it is a very very nasty security issue - especially in countries where such a bug may cost your life (sorry to say but some of the BRICS -> e.g. the C or R). R [update] and nowadays also B). It is not only a problem of your device it is also a problem of your vpn server side! And it is not only a problem of openvpn - the fritzbox stuff does the same.
Scenario: You have an (open-)vpn server at home and you are visiting a friend with a dual stack network (so he has ipv4 and ipv6). Do not ask your friend (if he is no nerd) if he has ipv6 - he does not know. But several providers just switch v6 on (e.g. Germany's Telekom) do not have ipv4 at all and do ds-lite (Germany: unity media) or you run around a modern conference with a v6-stack only (FOSSDEM - but then it will not work at all...) or dual stack and you cannot trust the other people around like congresses in Germany's late winter time... Probably your LTE-Provider does dual stack too!
assuming your vpn works (so all bugs of the beta are fixed for sailfishos). You configure your network that the default gateway is your tunnel, because you want all your traffic go through the tunnel. You can ping your private machines and a traceroute/tracepath to all known 8.8.8.8 goes through the tunnel. Everything is fine.
Everything? Hm...
What will you see? https://google.com will not go through your tunnel.
For me it does but...
... you must start openvpn direct - this does not work with conman actually, it cannot handle all possible openvpn configuration statements - and you need to prepare the openvpn server. And: the same will occur if you do some tunnel to your fritz box or most of the tunnels around with every device you see.
Same problem will occur with facebook, apple or many other sites, probably 20% [update] (we are better now, we have, say, 40%) of all sites right now.
Why?
... to be continued ...
Part 2 - Dual Stack
Yes, the main problem is dual stack. If you prepare a tunnel for ipv4 then you build up a routing for ipv4. You will not change anything for ipv6. There all routes are still going to the default gateway.
When you do an DNS resolving you get two addresses for e. g. google.com:
~$ host google.com
google.com has address 172.217.23.142
google.com has IPv6 address 2a00:1450:4001:818::200e
...
and modern operating systems try to use ipv6 priorized. For mobile devices it is done by a brutal force method today:
but if a big player address is resolved (google, facebook, apple...) the v6 address will win. And because the v6 resolving is not changed all data will flow through the default gateway for v6 which has nothing to do with your v4 traffic.
... what can I do now?
Part 3 solutions
When designing vpn connections you now have the problem how to make it secure for the end user who thinks that everything is fine.
and Jolla?
... to be continued
Part 4 network connection managers
to build up a consistent network controling system desktop and mobile operating systems use some network/connection managers. The desktop systems prefer NetworkManager and for SailfishOS it is connman.
These managers handle the connection to the different networks (wlan, gsm...) and also the background stuff like dhcp handling, switching dns server configurations and reconnecting on moving devices. They also have the possibility to build up different types of vpns. But there are simpler managing systems too, like e.g. the configuration system of openwrt.
If you compare NetworkManager, connman, and openwrt then all of these systems try to put a set of configuration parameters from the configuration gui to the tunnel system. Whereas NetworkManger has a quite complete set of configuration parameters connman just implements parts of the set, as openwrt.
But with openwrt it is possible to leave the configuration empty and include an .ovpn file to just hand this file out to openvpn with no changes. It looks like connman is doing the same but in reality it interprets the file, fills it's own parameter set and starts up openvpn, vpnc, ipsec... It ignores parameters it does not know! The new sailfiish gui makes it possible to set an vpnc file to import but this is a real parameter import and all parameters which are unknown are ignored (without any warning). So it is not possible to just define a .vpnc file and let connman just call it. It is not possible to just use an .ovpn file which works if you use it by a simple devel-su openvpn myfile.ovpn
. The last does not work well because a network managing system must know everything about the network. If you do something without the manager disconnection and undefined network configurations are possible.
But if you are able to put the whole parameter set into the manager you must build on an error less implementation of the manager. It must e. g. handle resolv.conf parameters well (this is buggy with connman -> https://together.jolla.com/question/132993/openvpn-dhcp-option-dns-not-working/). This is needed to resolve internal servers behind the vpn tunnel. This could also be used to resolv v4 hosts only -> another possibillity for handling out v4 stuff only.
Part 5 wishlist
So then my little wishlist: It would be nice to
[end of long article] This is a wiki. feel free for more design brainstorming