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