- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
08-17-2023 09:14 AM
Hello,
I got a question regarding GlobalProtect and DNS. We currently have a setup where the users have an always-on-vpn. We also have some split tunneling enabled, so 10.10.10.0/24 does not enter the tunnel when the users are on-prem (when they are 'on the read', everything is tunneled). The split tunneling is working fine, when visiting a website, connecting to a NAS that lives in this subnet from an onprem workstation, the traffic does not enter the tunnel. However, our DNS server is also in this 10.10.10.0/24 range. We still see the traffic going into the tunnel. Is that expected behaviour? I see there is a form of split dns tunneling: https://docs.paloaltonetworks.com/globalprotect/5-2/globalprotect-app-new-features/new-features-rele... but it uses split tunneling based on domains if I see that correctly... We use only 'access route' split tunneling right now.
I would imagine if we want to have all the DNS queries outside of the tunnel, I would write a 'domain based split tunnel' rule for the 'on-premise users', to include all domains, so: *
But this also has effect on http(s) traffic etc if I understand correctly...
So, long story short, is there a way to route DNS traffic also outside the tunnel when on-premise?
cheers!
08-21-2023 09:30 AM
The only way I can get this to remain outside of the tunnel is by modifying the windows routing table.
route delete 10.10.10.<DNS Server> mask 255.255.255.255
can be done via a gp post script but see no harm in tunneling such requests via the tunnel so may not be worth bothering.
pretty sure you could also use an alias ip routed address and nat to real server as it traverses the Palo.
But at least we know that the reason it remains within the tunnel is because GlobalProtect adds it as a host address to the routing table which because of the metric... overides your split tunnel rules.
08-18-2023 08:31 AM
Hi Wazaka... quick question, by what method do you determine split tunnel or full tunnel, is it via different gateways or gateway configs??
We have a similar setup for our users and we just use forwarders on our local DNS to external DNSwhich works fine as not much overhead in a DNS request...
08-20-2023 11:24 PM
In the GW, under agent, client settings; we do a check on what hide NAT address the user has to determine if they are onprem or at home.
For our usecase the internal DNS should be used in all cases. But it would make sense to me to not send the DNS queries/replies through the tunnel when onprem, as the DNS servers are also onprem...
08-21-2023 04:34 AM
Yes but by design the GP client adds your DNS as a /32 to the routing table, as below I added a /32 exclusion from the tunnel but the GP modifies the metric to force DNS via the tunnel..
So i added 10.250.1.41/32 to be excluded from the tunnel, it has been added to the routing table but with a metric of 36 so the metric of 1 will be used for your requests.
08-21-2023 04:41 AM - edited 08-21-2023 04:41 AM
So specifying an 'exclude /32 route' for the DNS, does the trick?
I wonder why it is nowhere mentioned? I mean, if Palo forces the DNS to always go through the tunnel even why excluding the larger block, isn't this then a bad idea to mess with the split tunneling for DNS by adding that /32 route?
08-21-2023 08:04 AM
no sorry it doesn't work that way... GP client sets a lower metric so traffic still goes via tunnel
08-21-2023 09:30 AM
The only way I can get this to remain outside of the tunnel is by modifying the windows routing table.
route delete 10.10.10.<DNS Server> mask 255.255.255.255
can be done via a gp post script but see no harm in tunneling such requests via the tunnel so may not be worth bothering.
pretty sure you could also use an alias ip routed address and nat to real server as it traverses the Palo.
But at least we know that the reason it remains within the tunnel is because GlobalProtect adds it as a host address to the routing table which because of the metric... overides your split tunnel rules.
08-21-2023 10:01 AM
Hello there, thank you for helping on this, I really appreciate it. If it is not possible easily then that’s the answer I guess! Thanks!
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!