[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: VPN traffic leaks in IPv6/IPv4 dual-stack networks/hosts
On Sun, Dec 02, 2012 at 10:21:32AM -0500, Greg Troxel wrote:
> But on the other hand I agree with Darren's points. This is a policy
> matter, and NetBSD as an OS should be neutral, allowing users to set
> policy. So I'd say that VPN packages (as opposed to what's in the
> NetBSD base system) should handle this, offering a configuration option.
> I disagree with Fernando's characterization that IPv6 traffic not going
> in a VPN (or being blocked0 when a v4 VPN is configuration is
> necessarily a bug. For the totally-controlling corporate policy types,
> yes, but for many no. So I'd say that it's a bug for a VPN package not
> to make this configurable; perhaps that's what he meant.
I think the reason to bring this to an OS-specific list is that this
is surprisingly *hard* for a VPN package to actually achieve.
So, assume you are in the world of strict corporate policies, and want
to ensure that "all IPv6 traffic only goes to the VPN". With "policy based"
IPSEC implementations, this is fairly easy, but you need kernel support
for that. OpenVPN, OTOH, does "this goes to VPN!" by putting up a route
to the tun/tap interface. This starts being problematic as soon as you
have more specific routes in your tables (locally connected networks,
RAs with more-speicfic route options, RAs with *new* locally connected
networks while OpenVPN is done with its initialization, assuming that
all networks have been covered, ...).
So the interesting question is "how can the OS help the VPN package
to not have this 'bug'?".
(In Android or iOS, you just tell the VPN API "all networks go *there*",
and the kernel will ensure that. In normal Linux, you could do this with
"ip rule" and extra routing tables that will not be affected by RAs. In
the BSDs, we don't know...)
USENET is *not* the non-clickable part of WWW!
Gert Doering - Munich, Germany
Main Index |
Thread Index |