Global Protect: Full Tunnel Enforcement

[TBardIPsoft]

I have already contact Palo Alot Networks support about this issue and their comment back to me was "you need to protect the route preference/configuration from the host side."

The issue that I am facing is that we have third parties that are not managed by our company however need access to medical systems to support our customers.  In order to allow these individuals access they use our VPN to connect to the customer site. The current VPN solution that we have does this without any issues.

While testing full tunnel with GP-VPN we discovered that you are able to change your default route via the cmd command < route change >.  This allows you to stay connected to the GP-VPN for network access (Even with "Enforce GlobalProtect Connection for Network Access" = Yes) while having access to your local Internet connection effectivly changing the full tunnel to a split tunnel.  Since there are no other monitoring settings for the GP-VPN that can detect and prevent this change the only way to stop this action is via managing the client itself.  However this brings us back to the point that the support of of some of these devices is being done by third parties of which we do not manage.

Does anyone have any suggestions or solutions? Maybe there is some magic check box that I am missing somewhere in GP that will prevent this action from working on the host? Anything would be helpfull at this point, but I have a feeling I will just have to tell them that we need to be able to manage all endpoints that are using this VPN connection for support.  Which in my openion should be the case already.

[Mick_Ball]

Hi @TBardIPsoft.

I have tagged here as was not aware of this issue.....

i have tried to do a route change of 0.0.0.0 via local gateway but traffic still flows via vpn.

in your GP gateway/agent/client settings, have you selected "no direct access to local network".

also,,, could you confirm the route change command you are using, are you including an interface or is just like the one i tried below...

route change 0.0.0.0 mask 0.0.0.0 192.168.0.1

Mick.

[Remo]

@Mick_Ball

If you set the metric to 1 it is like @TBardIPsoft wrote. You are still connected but the trafgic is routed outside the tunnel. At least without the setting "no direct access to local network". With this setting enabled I need to test again.

But anyway, I kinda see it like TAC. A user without admin rights is not able to do route changes. Anf if a user has adminrights, there are way more security concerns than this route "issue".

[TBardIPsoft]

I forgot about this post.  Yes, you are correct in the metric change.  We did also use the "no direct access to local network" setting and it had not worked before.  I had messed with this tunnel on my own time on a non-corporate system and it appears to work however.  I am still waiting on the other business unit to do additional testing but time tends to go slow here.

Something that is different between a non-corporate system and a corporate system is that the corporate systems use certificates to access another GP-VPN tunnel.  I am curious to know if this is somehow causing issues with our testing in some way.  I was able to validate that they had the right client config though.

You are also correct in having more issues by having users with admin access.  In our set up the assumption is that the end user has admin access since they are outside contractors.  I have actually discussed this with the business around requiring full-tunnel for this VPN since either way at some point they will have access to uncontrolled networks.

[jdelio]

Just wanted to let everyone know that if they are having any GlobalProtect issues, and need to troubleshoot the issue, our Very own @kiwi has written a great blog all about troubleshooting GlobalProtect.

Be sure to check it out here: 
https://live.paloaltonetworks.com/t5/blogs/dotw-globalprotect-troubleshooting-tips/ba-p/383911