openvpn should detect dns is working before even attempting profile actions

[jhaar]

Hi there

I'm running openvpn as a service and one "glitch" it suffers from is timing out on "<connection>" profile attempts because there is no working network link at that moment. I see this a lot due to running it as a service on a laptop which is sleeping/unsleeping

What I've noticed is both Android and IOS do a series of "random hostname" DNS lookups before deciding they have a working network link. ie they generate some fake DNS records, look them up, and if they don't generate a DNS "no such host" error, then the OSes decide the network is not up yet - so all apps don't even get woken

As openvpn runs on multiple OSes and they don't all do that, maybe it could be added directly to openvpn (I think maybe Chrome browser does this too?). ie when openvpn starts, it should first do such random DNS lookups, and only if it gets sensible answers even bother to start attempting a connection.

BTW: In my case our profile starts with a connection section for an intranet server, so this is meant to fail when on "the Internet" - so simply blocking openvpn until the server hostnames resolve would not be a good idea (for us!) (later on there are Internet openvpn servers of course: the idea is when on the LAN, openvpn goes to an internal server and when off the LAN [on the Internet] it goes somewhere else - works well)

Thanks

Jason

[plaisthos]

What benefit does the random DNS Lookup have? Especially what the benifit of your proposed solution to resolv-retry?

[jhaar]

consistency mainly. Without it you get openvpn making weird decisions

Most of us should be running openvpn with multi-protocol configs: ie try UDP first and TCP second. But what this means is that often when you have openvpn running in the background, it fails the UDP connection attempt because it's tried too early (ie the network isn't up yet) and you end up on TCP through no fault of the client or even network.

Now that you bring it up, you are right about the fake DNS requests - so how about looking up *all* the DNS names in the config (which could be 1, 2, 3+) and if *any* resolve, take that as meaning the network link is working and start attempting connections? At the moment, openvpn treats DNS lookups identically to a firewall blocking outbound ports and simply tries the next connection option, thereby making inefficient choices

In case I wasn't clear: this isn't a bug - openvpn still works - I'm just thinking it could be more consistent in this corner case.