Member Avatar for Member #129437
Member #129437

Hi,

I have an issue with VPN clients not being able to access the DNS server on our LAN when they dial in. To give a brief overview of our network:-

  • Clients connect over VPN using L2TP IPSec VPN to our Draytek router
  • DNS Server runs on a dedicated WIN2008 server and the Draytek dishes out this via DHCP to LAN hosts (successfully) and VPN clients (unsuccessfully)

When connected over VPN, a user cannot resolve any of the internal host names - some users are successful using FQDNs but my PC is in one of the categories who are not so fortunate (I think it's a WinXP vs Win7 issue for FQDN resolution success, with Win7 being successful).

I've done a Wireshark capture on the VPN client and noticed that when making a request to the DNS server, the server that responds is that of my ISP or if I force that way down the list in Network Connections, the secondary DNS server configured on the Draytek router (our corporate ISP's DNS server). The Win2008 server never seems to get chosen/or responds (can't figure out what) to DNS requests. One potential area of investigation is the fact it is on a local LAN address, but VPN clients are able to ping it with no issues, so it's contactable, without doubt.

A few things I've tried are:-

  • Adding and registering the corporate DNS suffix in the VPN connection properties
  • Adding and moving to the top of the list, the internal WIN2008 DNS server on the client VPN properties
  • Using NSLOOKUP to diagnose the issue and seeing that the IP address of our WIN2008 server has "Non-existent domain" beside it, with my home router preceding it with "Timed out" and our corporate ISP as 3rd choice stating, "Non-existent domain" too. It also shows that the corporate ISP's DNS server is the chosen DNS server.

If anyone would have any ideas on how to resolve (excuse the pun) this issue, any advice at all would be great. I know the broken link: the DNS server and VPN clients can't communicate, but I cannot figure out where the problem could be.

Thanks in advance! :)

  • 1 Contributor
  • 0 Replies
  • 184 Views

Dani AI

Generated

When remote VPN clients can reach the DNS host but name queries are answered by an upstream/ISP server, the problem is usually one of three things: the VPN concentrator is redirecting or proxying DNS, the DNS service on the server is not accepting queries from the VPN address pool, or client-side routing/adapter ordering sends DNS to the internet instead of the VPN. The quickest path to a root cause is a short, focused checklist followed by targeted fixes.

  • On the VPN concentrator: confirm it is configured to push the internal DNS IP to VPN clients and that any "DNS proxy" or forced-WAN-DNS feature is disabled. Ensure there is no NAT/firewall rule on the concentrator that intercepts or rewrites UDP/TCP 53 from VPN clients.
  • On the DNS server: verify the DNS service is listening on the interfaces that cover the VPN subnet (DNS Manager -> Server Properties -> Interfaces). Check that inbound UDP/TCP port 53 is permitted for the VPN pool in the server firewall and that the server is not restricted to answers only from LAN addresses.
  • On the client side: confirm the VPN adapter actually has the internal DNS IP and a route to the DNS server (adapter DNS entries and route print). If split-tunneling is used, DNS traffic may still go to the internet unless a route/gateway setting forces it over the tunnel.

Helpful commands/tests (run with administrative rights):

ipconfig /all
route print
netstat -an | findstr ":53"
# query server directly:
nslookup <internal-name> <internal-dns-ip>

Practical fixes: have the concentrator explicitly push the internal DNS address or forward DNS requests for the internal domain to the internal server; disable any router DNS proxy; open 53/TCP+UDP to the VPN pool on the DNS server; set the VPN adapter metric or force remote default gateway if needed so the resolver uses the VPN DNS. After changes, restart the DNS service and re-establish the VPN session to validate. If problems persist, capture packets on the concentrator and the DNS server to see where queries are arriving and how they are answered.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.