VPN traffic leaks in IPv6/IPv4 dual-stack networks/hosts

Folks,

FYI. This is might affect Linux users employing e.g. OpenVPN:
<http://tools.ietf.org/html/draft-gont-opsec-vpn-leakages>.

For a project such as OpenVPN, a (portable) fix might be non-trivial.
However, I guess Linux might hook some iptables rules when establishing
the VPN tunnel, such that e.g. all v6 traffic is filtered (yes, this is
certainly not the most desirable fix, but still probably better than
having your supposedly-secured traffic being sent in the clear).

P.S.: Not sure if this is the right list to send this note. Please
advice of a more appropriate one and/or feel free to forward this note
if deemed appropriate...

Thanks,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

On Tue, 2012-11-27 at 11:54 -0300, Fernando Gont wrote:

Folks,

FYI. This is might affect Linux users employing e.g. OpenVPN:
<http://tools.ietf.org/html/draft-gont-opsec-vpn-leakages>.

For a project such as OpenVPN, a (portable) fix might be non-trivial.
However, I guess Linux might hook some iptables rules when establishing
the VPN tunnel, such that e.g. all v6 traffic is filtered (yes, this is
certainly not the most desirable fix, but still probably better than
having your supposedly-secured traffic being sent in the clear).

P.S.: Not sure if this is the right list to send this note. Please
advice of a more appropriate one and/or feel free to forward this note
if deemed appropriate...

This seems a user space issue to me.

accept_ra on linux is set to 1, meaning that as soon as forwarding is
enabled, RA are ignored.

Hi, Eric,

On 11/27/2012 01:04 PM, Eric Dumazet wrote:

quoted

P.S.: Not sure if this is the right list to send this note. Please
advice of a more appropriate one and/or feel free to forward this note
if deemed appropriate...

This seems a user space issue to me.

accept_ra on linux is set to 1, meaning that as soon as forwarding is
enabled, RA are ignored.

I don't follow. Why would RAs be ignored if accept_ra is set to 1??

Cheers,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

On Tuesday 2012-11-27 15:54, Fernando Gont wrote:

Folks,

FYI. This is might affect Linux users employing e.g. OpenVPN:
<http://tools.ietf.org/html/draft-gont-opsec-vpn-leakages>.

For a project such as OpenVPN, a (portable) fix might be non-trivial.

If the VPN server does not even advertise to-be-secured IPv6 prefixes, 
any client-side fix is questionable. Disabling all of IPv6 on the client 
just because no IPv6 prefixes were sent is bogus.. it is like disabling 
all my IPv4 internet just because the server only gave me one IPv6 route 
into $internal_company_network.

On Tuesday 27 of November 2012 13:07EN, Fernando Gont wrote:

quoted

accept_ra on linux is set to 1, meaning that as soon as forwarding
is
enabled, RA are ignored.

I don't follow. Why would RAs be ignored if accept_ra is set to 1??

Value of 1 means "Accept Router Advertisements if forwarding is 
disabled.", see Documentation/networking/ip-sysct.txt

                                                        Michal Kubeček

On 11/27/2012 01:10 PM, Jan Engelhardt wrote:

quoted

For a project such as OpenVPN, a (portable) fix might be non-trivial.

If the VPN server does not even advertise to-be-secured IPv6 prefixes, 
any client-side fix is questionable. 

If the VPN is supposed to secure all traffic, and the VPN just fails to
support v6, then for me, it's questionable to have your traffic leak out
the VPN just because of that lack of IPv6 support.

But YMMV, of couse.

Cheers,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

On Wednesday 2012-11-28 20:57, Fernando Gont wrote:

On 11/27/2012 01:10 PM, Jan Engelhardt wrote:

quoted

quoted

For a project such as OpenVPN, a (portable) fix might be non-trivial.

If the VPN server does not even advertise to-be-secured IPv6 prefixes, 
any client-side fix is questionable. 

If the VPN is supposed to secure all traffic, and the VPN just fails to
support v6, then for me, it's questionable to have your traffic leak out
the VPN just because of that lack of IPv6 support.

Well, what I am saying is that a server may not
be conveying "all", but only "0.0.0.0/0".

On 11/28/2012 05:06 PM, Jan Engelhardt wrote:

quoted

If the VPN is supposed to secure all traffic, and the VPN just fails to
support v6, then for me, it's questionable to have your traffic leak out
the VPN just because of that lack of IPv6 support.

Well, what I am saying is that a server may not
be conveying "all", but only "0.0.0.0/0".

In such scenarios, doing nothing about IPv6 would be an oversight/error,
since IPv4 and IPv6 do not operate isolated from each other.

Cheers,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

On Wednesday 2012-11-28 21:14, Fernando Gont wrote:

On 11/28/2012 05:06 PM, Jan Engelhardt wrote:

quoted

quoted

If the VPN is supposed to secure all traffic, and the VPN just fails to
support v6, then for me, it's questionable to have your traffic leak out
the VPN just because of that lack of IPv6 support.

Well, what I am saying is that a server may not
be conveying "all", but only "0.0.0.0/0"[0/0].

In such scenarios, doing nothing about IPv6 would be an oversight/error,

Without additional input from the user, e.g. by means of a config 
setting, the software itself cannot distinguish between an 
oversight/error and a deliberate configuration.

On 11/28/2012 06:37 PM, Jan Engelhardt wrote:

quoted

On 11/28/2012 05:06 PM, Jan Engelhardt wrote:

quoted

quoted

If the VPN is supposed to secure all traffic, and the VPN just fails to
support v6, then for me, it's questionable to have your traffic leak out
the VPN just because of that lack of IPv6 support.

Well, what I am saying is that a server may not
be conveying "all", but only "0.0.0.0/0"[0/0].

In such scenarios, doing nothing about IPv6 would be an oversight/error,

Without additional input from the user, e.g. by means of a config 
setting, the software itself cannot distinguish between an 
oversight/error and a deliberate configuration.

Exactly. So fail on the safe side, and disable IPv6. Most users
forwarding all IPv4 traffic are meaning to secure all their traffic with
the VPN.

If you do nothing about v6, then it just takes a local attacker to
trigger v6 connectivity (or the user to connect to a dual-stacked
network) for the supposedly-secure traffic to go out in the clear.

Many people don't realize that v6 and v4, while being to different
protocols, are sticked together by means of the DNS. And the
aforementioned issue will come up as a surprise in most scenario.

Not to mention that nowadays, you will miss virtually nothing on the
Internet by having v6 off.

Thanks,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

On Thursday 2012-11-29 03:29, Fernando Gont wrote:

Not to mention that nowadays, you will miss virtually nothing on the
Internet by having v6 off.

Don't judge others by your own standards..

On 11/29/2012 12:15 AM, Jan Engelhardt wrote:

On Thursday 2012-11-29 03:29, Fernando Gont wrote:

quoted

Not to mention that nowadays, you will miss virtually nothing on the
Internet by having v6 off.

Don't judge others by your own standards..

You don't know me enough to make claims about my standards.

Whenever you please, please come up with a list of services (by domain
name) that are not available on v4, then talk.

And, in any case, what I mentioned still holds true: preventing VPN
leaks follows the principle of "least surprise".

I said what I had to say...

Cheers,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1