10-16-2020 08:28 AM
Hi All!
Last week I was able to roll out split DNS to our production firewalls. This was tested successfully on a firewall in pre-prod and then moved to prod firewalls with same result.
Suddenly this morning queries to explicitly excluded domains are no longer being split. I've verified the configuration is good. I went back to pre-prod firewall and the same situation! This was a previously working config and no changes have been made since. I've verified this by using Wireshark on my local machine while connected to Global Protect. I don't see any DNS queries exiting the local adapter for excluded domains.
Previous to today I was able to see all DNS queries to excluded domains come through Wireshark when monitoring the local NIC.
Has anyone else experienced this problem?
01-21-2021 01:02 PM - edited 01-21-2021 01:04 PM
The issue was finally resolved in December and Split DNS is working as it should. However there was more than fix that was involved. For anyone stuck in the same situation I was, hopefully the information below will help.
Palo Alto has thus far done a poor job on the documentation to implement split DNS. About 1/3 of information is spread out across multiple documents which can be hard to track down. The remaining 2/3s of the information needed to configure this required a support ticket to Palo Alto in order to get he full picture.
If anyone from PA reads this forum please publish a complete guide on how to completely configure this feature. It would have saved me a lot of frustration and phone calls to support.
01-21-2021 01:06 PM
The issue was finally resolved in December and Split DNS is working as it should. However there was more than fix that was involved. For anyone stuck in the same situation I was, hopefully the information below will help.
Palo Alto has thus far done a poor job on the documentation to implement split DNS. About 1/3 of information is spread out across multiple documents which can be hard to track down. The remaining 2/3s of the information needed to configure this required a support ticket to Palo Alto in order to get he full picture.
10-16-2020 10:40 AM
So far never saw this behaviour.
Which GP version you are running.
first thing I will do is pull the logs from the agent and check the GPS logs.
Regards
10-16-2020 10:50 AM
Thanks MP18. I reviewed them this morning. While I see all the domains that are supposed to be excepted from the tunnel, I also see a lot of errors stating;
(T10796)Debug(1844): 10/15/20 00:33:28:575 Retry DnsQuery.
(T10796)Debug(1862): 10/15/20 00:33:28:575 Already takes 90 seconds for all dns queries.
(T10796)Debug(1864): 10/15/20 00:33:28:575 Exceeds 1 minute. Do not retry DnsQuery
I'm also seeing a lot of;
(T26916)Debug( 914): 10/15/20 08:25:19:427 HandleDnsCallback: failed to parse dns req packet.
(T26916)Debug( 914): 10/15/20 08:25:20:031 HandleDnsCallback: failed to parse dns req packet.
(T26916)Debug( 914): 10/15/20 08:25:46:423 HandleDnsCallback: failed to parse dns req packet.
However I have not been able to see in the logs what DNS server is unreachable or why it could not parse DNS packet. Still combing through the logs and I've logged a ticket with PA Support
10-16-2020 10:59 AM - edited 10-16-2020 11:00 AM
Can you do nslookup for the gateway FQDN from the GP user.
External Gateway DNS server should be reachable and it should resolve from the FQDN for portal once GP agent is connected.
Regards
10-16-2020 11:06 AM
When connected to GP Gateway and I perform an nslookup to the external FQDN of the gateway (vpn.example.com). It doesn't resolve. Example.com is one of the domains that we tunnel through the VPN for resolution. However we don't have an internal DNS record on our AD servers for vpn.example.com I am a little unclear as to what you are asking for so I hope this was the right answer.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!