DNS issues in Site-to-Site Auto-VPN

[EtienneleComte]

Windows 10 clients connected to a site-to-site VPN into our datacenter are experiencing DNS issues.

We cannot ping using hostname or FQDN (all our AD domain suffixes are added to the clients search list using GPO). However nslookup resolves the correct hostname. On our MPLS network everything is working fine, so I suspect somethiong wrong with DNS in the AutoVPN. 

Ping using IP address works as wel to all our routed subnets behind the datacenter MX. Traceroutes on the clients to all destinations show the correct route. So there is L3 connectivity, but all DNS related stuff (logging in to AD, mapping network drives, loading GPO's, etc.) fails. 

I am a bit stuck on this one......

[PhilipDAth]

Try adding a trailing dot to the dns name you are pinging to make it an absolute DNS lookup rather than relative.  For example:

ping server.company.local.

Note the trailing dot.

[EtienneleComte]

Result is still the same.... ping servername.company.lan results in: Ping request could not find host servername.company.lan.. Please check the name and try again.

The weird thing is we have 5 or 6 dns suffixes configured in our clients. Of three of those the hostname resolves in ping, the other 2 do not..... Wireshark traces show only DNS requests of the last three DNS domain names, the first two (unfortunatly the most important) do not work.... All DNS sufixes resolve correctly using nslookup.

[BrechtSchamp]

I don't think this is a Meraki issue. That said, does this help?

Source:

https://superuser.com/questions/495759/why-is-ping-unable-to-resolve-a-name-when-nslookup-works-fine

[Nash]

Which domain are the computers joined to, out of curiosity? Asking for my own edification. Is it the working one?

Agreed that this isn't sounding like a Meraki issue, beyond the fact that the Meraki client VPN doesn't share DNS suffixes to connected clients automatically. Just DNS servers.

[EtienneleComte]

Unfortunately, my non-working laptop is joined to the non working domain, resulting in all kinds of issues. We are looking into the DNS stuff at the moment.

For the record, it is a site-to-site VPN (and not a client VPN).

[Nash]

Ah, mea culpa. 🙂 I choose to blame the snow.

Good luck with your DNS stuff. This sounds difficult.

[SoCalRacer]

Did this work at some point or is this a new deployment? 

On the client machine network adapter, IPv6 turned on or off?

I assume if possible to connect physically into the datacenter then this issue does not occur?

[EtienneleComte]

It's a new deployment, strange thing is that other domains laptops are connecting just fine. On the test laptop disabling/enabling IPv6 makes no difference.

Strange thing is that using the MX'es PacketTrace, when opening it in WireShark we see 4 DNS queries (on the 4 least interesting DNS domain names) and the 2 main ones, nu query is sent out on the wire.....

Within the datacenter, or - for that matter - on all of our MPLS connected locations the same machine's are working fine. That is what puzzles me the most....

[EtienneleComte · Accepted solution]

Ulitmately the issue was a datacenter routing problem. Our impacted clients could not reach a Network Location Service and tried to activate DirectAccess (IPv6) over the site-to-site VPN. This changes the internal routing tables on the affected computers. We did not see this, because IPv6 was not in the default PacketDumps.....

Added the correct routes and problem solved. Thanks everyone for helping out! 

[BrechtSchamp]

Thanks for posting back!