Trouble resolving DNS for my OpenVPN connections

I’m using a GL-AR750S Slate device on the 3.013 testing firmware, trying to establish an OpenVPN connection (in this case, to the provider VPNUnlimited). It’s failing to connect after a 30 second timeout, and the reason seems to be that it is using an incorrect IP “recently used” address:

Sun Feb 10 13:08:05 2019 daemon.notice openvpn[11973]: OpenVPN 2.4.5 mips-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Sun Feb 10 13:08:05 2019 daemon.notice openvpn[11973]: library versions: OpenSSL 1.0.2o 27 Mar 2018, LZO 2.10
Sun Feb 10 13:08:05 2019 daemon.warn openvpn[11982]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sun Feb 10 13:08:05 2019 daemon.notice openvpn[11982]: TCP/UDP: Preserving recently used remote address: [AF_INET]146.112.61.106:1194
Sun Feb 10 13:08:05 2019 daemon.notice openvpn[11982]: UDP link local: (not bound)
Sun Feb 10 13:08:05 2019 daemon.notice openvpn[11982]: UDP link remote: [AF_INET]146.112.61.106:1194
Sun Feb 10 13:08:35 2019 daemon.notice openvpn[11982]: [UNDEF] Inactivity timeout (–ping-exit), exiting
Sun Feb 10 13:08:35 2019 daemon.notice openvpn[11982]: SIGTERM[soft,ping-exit] received, process exiting

That 146.112.61.106 address seems like a Honk Kong address (?), so I’m guessing it is falling back on some previous data which happens to be in the firmware because it can’t resolve the name in my config? The actual server name is us-sf.vpnunlimitedapp.com, which should resolve to a totally different address. I’ve tried a few different VPNUnlimited servers.

Maybe the underlying cause is that OpenVPN can’t resolve DNS? If I put a hard-coded address into my OpenVPN config file I am able to connect. For DNS I’m currently using the manual setting “1.1.1.1”, but I’ve tried various settings on the Slate’s “Custom DNS Server” tab and it always seems to use that same IP when connecting to a named OpenDNS host. My PC is connected via WISP, and DNS is working fine on that side; it just seems to be OpenVPN that is having DNS trouble (or at least that’s what I’m guessing is happening).

It will use the router’s default DNS server to resolve DNS before VPN connection established.

You can try “DNS over TLS”, to check if it can work.

Yes, I’ve also tried using the “DNS over TLS from Cloudflare” setting but I still get “TCP/UDP: Preserving recently used remote address: [AF_INET]146.112.61.106:1194”. Does that mean DNS is failing? I don’t understand why, since DNS works fine for my PC (using “Override DNS Settings for All Clients”, which I assume means it should use the same DNS OpenVPN is using).

How about using nslookup to resolve your DNS on the router?

Thanks kyson-lok, I learned a few things checking in that way. It turns out that the Slate is using my main router DNS settings which are configured for OpenDNS FamilyShield, and that is where that unexpected IP is coming from. That’s the settings on the router WISP is connecting to. So that solves half of the puzzle.

The remaining question is why the AR750S is using the router DNS instead of the custom DNS server settings configured within the UI. It seems to be passing those configured DNS values to connected clients but not using them itself. It’s possible it is that way intentionally, but if so it might need to be configurable somehow? It seems like the VPN client would often need to use that configurable DNS, as in the case of hotels, etc, they might not properly resolve VPN addresses (intentionally, to block them).

1 Like

Just to clarify, the question is now this: Why is the Slate using the DNS from the WISP DHCP when connecting to an OpenVPN server, rather than the settings configured in the GUI? Is this the expected behavior? It could be useful, but it seems like it should also be configurable (and probably not the default behavior either). Certainly I could see a hotel’s DNS might intentionally fail to resolve a VPN address.

Yes see this issue I raised here:

Thank you @nopro404! :clap: I will continue on your thread, as it is a more concise description of the underlying problem.

I confirm this issue is present on other devices which are running 3.013 firmware. See this post for more information: