Global Protect - split tunnel catching too much

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Global Protect - split tunnel catching too much

L2 Linker

Global Protect is working great, but we're seeing too much traffic inside the tunnel and subsequently dropped on the DC firewalls.

We're using split tunnel with specific routes and a couple of include and exclude domains. However, we're seeing completely unrelated traffic tunnelled through the VPN. Where do we even start with troubleshooting this?

One traffic source I've noticed is Logi Options sending UDP:59871 to private addresses which are not part of the prefixes passed to clients. Why Little Snitch doesn't drop this traffic is another issue, but why Global Protect forwards it over the VPN is what I'm trying to address here. Another is a Chrome helper process targeting a public address which is also not meant to be inside the tunnel, but is also forwarded inside the VPN. Neither the included domains nor the prefixes would match this traffic.

We do use a wildcard domain in the included domains. I'm under the impression that this is supported.

We're running Global Protect 6.2.7-1047 and have a valid license.

1 accepted solution

Accepted Solutions

L2 Linker

The reason for split tunneling is that this VPN is intended only to manage servers and not to protect the end-points; else we would be using always-on full tunnels. But, why draw 99% irrelevant traffic to the DC when we don't want to treat this data at all? Anyway, my question wasn't about whether to use a split tunnel or not. Thank you for your input though!

 

Meanwhile, I think I have found the issue. A recent Global Protect gateway change failed to commit due to a config error. It appears that since that error was resolved, the problem of traffic being sent via the VPN that should have bypassed it is solved.

View solution in original post

3 REPLIES 3

Cyber Elite
Cyber Elite

Hello,

My personal recommendation is to not utilize a split tunnel. Almost all of the controls and best practices state to not use one. You will get better visibility into the traffic as well as protecting all of the traffic with the Palo Alto. I'm sure there are reasons you are however. I say keep tuning it if you are set on the split tunnel.

 

Regards,

Cyber Elite
Cyber Elite

@dmgeurts,

I agree with @OtakarKlier, split-tunneling traffic is something that I don't recommend unless absolutely necessary. 

 

I have seen inconsistencies when you try to include wildcards for split-tunnel domains where it's captured more traffic than intended, so what you're seeing isn't abnormal behavior in my experience. Behind the scenes I'm actually not sure how GlobalProtect identifies the domain you have specified and whether or not that it should route through the GlobalProtect network interface or not. It's understandable to me that some traffic would need to be sent through the tunnel before GlobalProtect can identify whether it should be there or not, much the same as you'd see when allowing access based off of application or app-id. 

L2 Linker

The reason for split tunneling is that this VPN is intended only to manage servers and not to protect the end-points; else we would be using always-on full tunnels. But, why draw 99% irrelevant traffic to the DC when we don't want to treat this data at all? Anyway, my question wasn't about whether to use a split tunnel or not. Thank you for your input though!

 

Meanwhile, I think I have found the issue. A recent Global Protect gateway change failed to commit due to a config error. It appears that since that error was resolved, the problem of traffic being sent via the VPN that should have bypassed it is solved.

  • 1 accepted solution
  • 624 Views
  • 3 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!