Globalprotect split tunneling

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Globalprotect split tunneling

L1 Bithead

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!

1 accepted solution

Accepted Solutions

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.

 

View solution in original post

7 REPLIES 7

L7 Applicator

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...  

L1 Bithead

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...

L7 Applicator

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..

Mick_Ball_0-1692617230749.png

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.

 

 

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?

no sorry it doesn't work that way...   GP client sets a lower metric so traffic still goes via tunnel

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.

 

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!

  • 1 accepted solution
  • 1756 Views
  • 7 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!