Issue with DNS resolution in browser when connected via Checkpoint mobile client

[sklotz]

Not sure if this is really a VPN and/or Checkpoint issue, but as of now it looks like with the following strange behavior.
When users are connected via VPN and browsing websites with internal DNS-names, the browser sometimes through the error message DNS hostname could not be resolved. Also ping the hostname is affected. Only a dedicated nslookup is working fine.
Our first idea/finding was that it might be related to a missing metric entry for the VPN-adapter, but setting this metric manually didn't change anything.
Then we tried to sniffer the DNS-queries on the Checkpoint FW (which terminates the VPN) and we see both the DNS-request as well as the response once we hit refresh in the browser. This means the client is sending the DNS-querie via the correct interface, but it looks like the client (browser or ping) doesn't react on the DNS response.
Do you have any further idea how to troubleshoot or analyze this issue? Or do you already know, what's the reason for this?
We are running on 81.10.
Thank you!

Regards,
Stefan

[Arne_Boettger]

Hello,

we are seeing a similar issue, but with Windows Clients connectiong to R81.20. A Wireshark on the VPN Client clearly shows DNS Queries and Responses, but the client still can not resolve the hostname.

Could it be a recent Windows Update?

Kind regards, Arne

[sklotz]

It might be related to IPv6, we disabled it now on the Checkpoint and WLAN adapter and since then no further issues.
I'm also checking with Checkpoint official support on that topic, but when I read sk182212, it might be the reason here.
I'll keep you updated.

Regards,
Stefan

[PhoneBoy]

Yes, our Remote Access clients do not support IPv6 currently.

[Arne_Boettger]

Hello,

I try not to see disabling IPv6 as a solution to anything, because eventually we want to disable IPv4. But it might be related to IPv6 connectivity on the non-VPN interfaces. I did not completely understand sk182212 - are the mentioned IPv6 features already in the generally available Endpoint Clients? 

kind regards, Arne

[PhoneBoy]

Not as far as I know.
In any case, what's mentioned in sk182212 is support for clients in a NAT64 scenario.
The actual VPN is still IPv4 and doesn't support IPv6.

[sklotz · Accepted solution]

It seems we could identify to root cause and also found a confirmation with another FW-vendors knowledge base here.
It's a Windows related issue, if IPv6 is enabled on the interface (most likely the WLAN-adapter), where the VPN-tunnel is connected to. By default Windows performs a A and AAAA DNS-lookup simultaniously and prefers the AAAA response.
We will double check this in our environment, if the issue occurs again.
But as of now this sounds verify promising.
Thank you!

Regards,
Stefan

[PhoneBoy]

That seems like a plausible explanation for the issue.

[the_rock]

Thanks for letting us know @sklotz 

[FloydG]

Hello. Not 100% sure if we experienced the same issue, but maybe this is helpful for you:
Starting this October we had a few clients not able to resolve internal hostnames and home printers. Like "ping wsus01" was "not resolveable". But "ping -4 wsus01" was successful. After a lot of investigation we figured out, that a GPO was causing the issue. This is the reg-key which we deleted now: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\DNSClient\ - DisableSmartNameResolution