[ipv6-wg] IPv6 Only Network at RIPE 67

Hi,

just for the record, as this is veering wildly off the original topic...

On Thu, Oct 17, 2013 at 08:57:28PM +0200, Philipp Kern wrote:
> > As expected, connecting using OpenVPN profiles that have IPv4-literals
> > in there ("server 1.2.3.4") fail.  Don't do that, then.
> 
> there is one instance where this is actually needed: if split DNS is in
> use and the resolvers are not available from outside the tunnel and if
> you're on Linux (the latter is a guess, and I only tested with
> resolvconf present).
> 
> In this case, when the client loses its tunnel, the DNS servers are not
> reset to the non-VPN ones. OpenVPN will do a fresh DNS lookup for the
> VPN server to a now unreachable DNS server, which fails. Hence the
> tunnel will not come back up.
> 
> That's the reason why we opted for IPv4 literals in the OpenVPN
> deployment at my alma mater.

I can only strongly recommend against that, again.  It will break your
OpenVPN setup on mobile devices that sit behind a NAT64/DNS64, while
OpenVPN would otherwise work perfectly well, connecting from an IPv6-
capable client to an IPv4-only OpenVPN server - and it will also impair
connectivity if you happen to dual-stack the server later (because 
you'll need to roll out new certificates).

I'll go testing why the DNS settings are not restored if the tunnel
breaks down, while at the same time doing a fresh DNS lookup - that 
sounds like a bug to me, as it can't work, obviously.  OTOH the whole
"change DNS while OpenVPN is running" is a bit wacky on *Linux*, as
it's done by distribution-specific external scripts...

I'm happy to continue that discussion over at the openvpn-devel list 
(@lists.sourceforge.net), though :-)

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 (0)89/32356-444           USt-IdNr.: DE813185279
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <https://lists.ripe.net/ripe/mail/archives/ipv6-wg/attachments/20131021/ee106af9/attachment.sig>