I have a situation where computers in some of our remote offices from time to time lose the ability to use our DNS server (in head office) to resolve hostnames. The offices are connected via VPN using Cisco ASA 5505 (VPNclient config rather than Site to Site) connecting back to an ASA 5510 at head office.

Ping to the IP address of the DNS server works. But nslookup will get a "no response from server" message. Computers in other locations can use DNS fine.

This is an intermittent problem. One day/hour it works, another it doesn't. Other offices connected in the same way work when another doesn't.

No config changes have been made on routers around the time we see the problem.

The DNS server that drops out for the clients is on our private address space in the network. The ASA 5505s and the clients behind them are each in a 10.6.x.0/24 private address space.

Each ASA 5505 has its DHCP server configured to assign addresses and DNS config to clients behind them -these are generally Windows XP clients, with a growing number of Windows 7. The primary DNS is our one in the space, the secondary is to allow access to the internet in case the VPN tunnel drops for any reason.

Some users have reported that the problem goes away after doing a repair connection in Windows XP. I think this could be caused by the DNS cache being flushed as part of this - the Windows DNS cache makes the intermittent problem look less so because it caches failed lookups as well as successful ones. However, it is possible some other aspect of Windows is involved. Windows 7 clients have also had the same problem.

Any pointers on deeper troubleshooting, or anyone else found this?

  • Intermittent as in sometimes they can and sometimes they can't? How is the VPN connected? Isn't there a DNS timeout for the 5505. If so set it higher. – dbasnett Jun 30 '11 at 13:48
  • I don't see anything about DNS timeout in the docs for ASA. Are you thinking of DHCP? – dunxd Jun 30 '11 at 16:01
  • @dunxd Have you tried monitoring traffic on the ASA while the problem is apparent, or checking the syslog (assuming it's configured), to see what traffic is passing each way. You could also capture on the dns server, say with network monitor, to see if the requests are getting there. – Chris Jul 3 '11 at 22:25

Make sure that port 53 isn't blocked on the offices end. Also I would make sure that they don't have a statically assigned IP and DNS server. I would also look into a pc at that location acting as a DNS MITM.

  • 1
    Don't forget the basics too, Keith. Remember RFC 1918 section 4. – JdeBP Jun 30 '11 at 13:37
  • @JdeBP - not clear what RFC 1918 Section 4 has to do with this - "4. Advantages and Disadvantages of Using Private Address Space". Can you elaborate? – dunxd Jun 30 '11 at 16:07
  • don't forget that the response needs to be allowed as well...if you can turn up debugging or use a packet capture to verify that the server is receiving the request, you'll at least have identified which part of the request/response is failing – Greeblesnort Jun 30 '11 at 16:11
  • Are you using RFC 1918 address space? How is your DNS configured? – dmourati Jun 30 '11 at 16:21
  • I was hoping that Keith would augment xyr answer, to make it more complete and get the acceptance credit. It's a fairly basic and well-known issue, but one to check nonetheless. Tunnel two or more networks together that are using the same non-public IP address ranges, and one has to deal with address and routing conflicts. – JdeBP Jul 1 '11 at 9:13

DNS over VPN problems almost always have to do with the client DHCP/VPN DNS nameserver configurations.

In Windows, anything is possible.

Try removing the clients from DHCP all together and see if the problem goes away.

Provide more details about the client configs and the IP ranges in question.

Check all your firewalls and routers and VPNs for port 53 tcp and udp.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.