[LAC-TF] Fwd: Re: [OPSEC] IPv6 implications on IPv4 nets: IPv6 RAs, IPv4's VPN "leakage"

[Fernando Gont]

FYI.

Super interesante.


-------- Original Message --------
Subject: Re: [OPSEC] IPv6 implications on IPv4 nets: IPv6 RAs, IPv4's
VPN "leakage"
Date: Fri, 14 Sep 2012 20:14:22 +0200
From: Gert Doering <gert at space.net>
To: Fernando Gont <fgont at si6networks.com>
CC: Gert Doering <gert at space.net>, Andrew Yourtchenko
<ayourtch at cisco.com>,  "'opsec at ietf.org'" <opsec at ietf.org>

Hi,

On Thu, Sep 13, 2012 at 08:17:09PM -0300, Fernando Gont wrote:
> On 09/13/2012 03:15 PM, Gert Doering wrote:
>> OpenVPN before 2.3 has no idea what IPv6 is (in client-server
>> mode).
> 
> That's the impression that I got... but since I didn't play much
> with openvpn (other than getting my vpn "up and running"), I didn't
> want to make any sort of claim...
> 
> That said, I get the following banner: OpenVPN 2.2.1 i686-linux-gnu
> [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] [MH] [PF_INET6] [IPv6
> payload 20110424-2 (2.2RC2)] built on Mar 30 2012
> 
> -- not sure what the PF_INET6 and "IPv6 payload 20110424-2
> (2.2RC2)" mean.

That's "you got a debian package that has most of the IPv6 goodies in
it already" :-) - both openvpn-over-IPv6 (PF_INET6) and IPv6-over-openvpn
have been available as patch sets for about two years now.  Debian
included
them in their package, and I think you could enable it on Gentoo.

>> Plus, while IPv6 communication can be redirected to the tunnel
>> (by just pushing a 2000::/3 route), more specific IPv6 routes
>> pointing elsewhere will still be honoured, including "connected
>> /64" networks.
> 
> Yes. And there could be default routers with different priorities,
> too.
> 
> That's why I had claimed that "even if the vpn software supports
> v6, the attack might still work".

Yes.  Blocking "VPN evasion" traffic for IPv6 is more tricky than for
IPv4,
if the hosts supports RAs with more specific routes - even if you block
access to the local /64, someone might sneak in a /128 via RA from fe80.

I'm really wondering (thinking out loud now) how to block local IPv6
communication in a reasonably portable way... using routing is tricky,
using firewalling is even more tricky (as it's optional on all supported
operating systems, and the BSDs even have more than one option each...).


>> To make "--redirect-gateway block-local" (which does "all IPv4
>> communication MUST go through the server!")
> 
> Without looking too close into the software, it looks that for the
> v4 case, openvpn simply installs an additional default route, which
> for some reason takes precedence over the existing one?

For IPv4, what OpenVPN does depends a bit on the flags given to
--redirect-gateway, but there are two possible scenarios:

A.
 - 1. find out what the current default gateway is
 - 2. install /32 route for OpenVPN server to gateway
 - 3. delete default route
 - 4. install default route to tunnel
 - 5. on disconnect, re-install original default route

or B.
 - 3. override default route with two /1 routes (0.0.0.0/1 and 128/1)

in addition, "block-local" does
 - 3a. find out what the local LAN's netmask is, split into two
more-specific
       subnets, route those into the tunnel (so local connectivity is
blocked
       by the OpenVPN server dropping those packets)

this is not resilient against more-specific IPv4 routes either, but in
IPv4, these usually do not happen "magically" by unsolicited packets.


>> work for IPv6 on all supported platforms is quite a bit of work,
>> so it has not yet been done - it's likely to happen for OpenVPN
>> 2.4, but for now the priorities have been "get out 2.3 with at
>> least some basic IPv6 support, well-tested and working across
>> all client platforms".
> 
> So far, I'm simply disabling v6 if I need to rely on the VPN to
> work as expected/intended.

That can certainly be done, but I'm one of those that *want* to use IPv6,
if only to find places of brokenness that need to be fixed :-)

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A.
Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279