Hi, On Sat, Aug 17, 2013 at 03:17:53PM +0200, Matthias Andree wrote: > Am 17.08.2013 12:30, schrieb Gert Doering: > > > So, what I'm hoping to hear from you... > > > > - should we include this in 2.3.3? > > - if yes, are changes needed? > > Well, it would take huge warning banners because it might disrupt > existing setups (which would be insecure through the "connect around > tunnel" behaviour), so I'd prefer "2.4" with a sooner 2.4 release.
Well, it would not happen "automatically", but only if block-ipv6 is
configured or pushed from the server (and if the server pushes it to
a 2.3.2 client, that one would not silently ignore it but abort) - so
I do not see much potential for breaking existing setups here, unless
the admin is intentionally turning it on...
> > - should we try to implement something for 2.4/master that will work
> > by pointing the IPv6 routes into the tunnel, and then synthesize the
> > IPv6 ICMP errors inside OpenVPN? That would work on Android and iOS
> > as well, and remove the extra per-platform logic for the "reject" routes
>
> Absolutely, on both accounts, if technically feasible. You may need to
> synthesize RST for stale TCP sockets, and ICMP for UDP, too.
I hear you and Arne, and will go out and start coding... :-)
> > - any clever ideas how to achieve "full" IPv6 blocking (right now, it only
> > kills the default route, but all more specific routes continue working -
> > this is by design to keep the implementation simple, and was considered
> > "good enough" by the end customer asking for it)
>
> End users may also have requirements to override certain more specific
> routes to bypass the tunnel. I can fancy only few things that are
> worse than flipping global connection status "with/without VPN" every
> few minutes if you need host and "home" resources at the same time.
Indeed. Besides the technical challenge, this would of course need to be
configurable ("block-ipv6 all" vs. "block-ipv6 default-route-only" or so).
The technical challenge of actually making this work in scenarios where
VPN policy requires "no other access" is even more interesting, given
that IPv6 routes/prefixes might change dynamically on a host with IPv6
autoconfig enabled...
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de
pgpBcoQwz8glW.pgp
Description: PGP signature
