Pritunl Private DNS Fails? Add a Narrow Resolver Route

Private names resolve for everyone on the corporate network and time out for everyone on the VPN. The resolver answers the gateway, the route to it exists, and the query still never gets a reply. What is missing is not another public resolver or a broader route: it is a source address the private DNS server is willing to answer.

Confirm the resolver is refusing your client pool

Start by proving the failure is about source, not reachability. From a connected client, query the private resolver directly and watch whether the request times out or comes back as a refusal. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 timing out while the same query from the gateway succeeds points at an access policy on the resolver. A SERVFAIL reply points somewhere else entirely, usually at the zone or the upstream forwarder.

Note the client's address before testing. ip -4 addr show tun0 on the client, or the lease shown in the console, tells you which pool the resolver sees.

Then confirm the path exists at all. A route that sends the resolver address into the tunnel is a prerequisite, not the fix; if packets never arrive, the source policy never gets consulted. Check it with ip route get 10.40.0.53 on the client.

Add one host route instead of translating everything

Pritunl's private-DNS guidance describes the narrow remedy: a NAT-enabled /32 route for the resolver address, with that address selected as the clients' DNS server. The route changes the source the resolver sees for DNS traffic only. Application traffic keeps the source-preserving design you chose for it.

Configure it through the server's supported route owner, after reviewing existing routes for overlap. In the example above the destination is 10.40.0.53/32 with NAT enabled, and the client pool stays 10.90.0.0/24. Do not translate the whole private range to fix one service, because every downstream policy that relies on the client's real address will start seeing the gateway instead. Confirm the address the resolver actually receives by watching its query log during a test lookup. A host route alone proves nothing about translation or permission.

The resolver still has to allow the translated source on UDP and TCP, and its replies must be able to return. Changing the source cannot create a missing zone or record.

Decide whether the server or the client sends the query

Pritunl also documents a DNS-proxy arrangement tied to VPN Client DNS Mapping, where the server forwards upstream queries for clients. In that model the upstream source belongs to the server's own network context, and a client-side exception is the wrong fix.

Identify which model is active before adding anything. Three overlapping repairs, a proxy, a client resolver override, and a manual NAT script, usually mean nobody has established which component is supposed to send the query. Check bootstrap as well: a private-only resolver cannot be the only way to find the endpoint before the tunnel exists, and a permanent resolver edit should not outlive the connection.

Test a private lookup, not a public web page

After applying the change and reconnecting, inspect the client's effective resolver configuration, then resolve a name you know exists only in the private zone. dig intranet.example.net without an explicit server shows what the client actually uses. Follow it with a request to the address that lookup returned, because resolution and service access are separate steps. A browser that loads public sites through DNS-over-HTTPS proves nothing about the operating system's private resolver path. A public secondary resolver is not an authority for an internal zone either.

Record the resolver address, the /32 route, and the client DNS setting together in the server notes. Half of that configuration restored alone reproduces the original failure.

Finally, confirm the tunnel still routes the application destination after DNS succeeds. Route, service access, and authentication remain independent of name resolution, and a working lookup says nothing about throughput. If the private page is slow but resolves, the resolver did its job and the problem moved to the path.