How to prevent GlobalProtect default route overwriting local static routes?

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.

How to prevent GlobalProtect default route overwriting local static routes?

L2 Linker

This is using PAN-OS 8 in AWS.

 

We have a site which has multiple networks attached. Users from the "main" network (let's call it 1.1.1.0/24) can also access 1.1.2.0/24, 1.1.3.0/24 via the default route supplied by the DHCP server, which goes to our core switch. (before you ask, I cant just change the subnet masks as the real subnets are completely discontiguous).

 

From the same site, we would use the GP VPN to connect to site B, and likewise, someone could connect to GP and get access to site A (in order to get to all of the networks) and site B.

 

When connecting to the VPN from site A it seems silly to have GP send all of the traffic to 1.1.2.0/24 and 1.1.3.0/24 through itself, when that traffic should be routed internally to site A.

 

I have tried adding static routes to our DHCP and could see that in my routing table, however, it got overwritten by the GP default route once I connected.

 

I have also tried to change the next-hop info for the particular routes in the virtual router - but still get local traffic heading all the way up to Amazon and back down again.

 

Has anyone encountered such a situation, and any advice on how to fix it, so local traffic remains local?

 

Many thanks

7 REPLIES 7

Community Team Member

Hi @StuartFordham,

 

You'll need to configure split tunnel (PAN-OS 8.0) :

https://www.paloaltonetworks.com/documentation/80/pan-os/newfeaturesguide/globalprotect-features/spl...

 

In 7.1 it's in a different location under Gateway configuration > Agent > Client Settings >Network Settings.

 

Hope this helps !

-Kiwi.

LIVEcommunity team member, CISSP
Cheers,
Kiwi
Please help out other users and “Accept as Solution” if a post helps solve your problem !

Read more about how and why to accept solutions.

Thanks for the link. But if this approach is taken, the remote access users that need access to those networks won't have access. 

 

this sounds interesting but i dont get it...   @kiwi suggestion seems good but are you saying that the 3 networks listed can be accessed both by local and GP.  i also dont understand your previous response regarding remote access users, are these the GP users? perhaps a doodle would suffice, are networks A and B within those given subnets?

 

 

Community Team Member

Hi @StuartFordham,

 

You could also configure separate gateways for VPN access and for access to your internal resources. With this configuration the agents will perform an internal host detection to determine if they are on the internal network or not and choose the gateway accordingly.

 

https://www.paloaltonetworks.com/documentation/60/globalprotect/global_protect_6-0/globalprotect-qui...

 

The above link is on PAN-OS 6.0 which is officially EoL but the general idea remains the same.

 

Cheers,

-Kiwi.

LIVEcommunity team member, CISSP
Cheers,
Kiwi
Please help out other users and “Accept as Solution” if a post helps solve your problem !

Read more about how and why to accept solutions.

Hi @kiwi and @Mick_Ball

 

This is the basic idea:

Basic PA layout - Page 1.png

For the remote users, this will not be an issue, they will get the networks they need to access through the GlobalProtect gateway (Sites A, B, and C).

 

Users in site A would not normally need to connect to GP, unless they need to access Site C.  All traffic would flow to the L3 switch and reach what it needs to reach. However, if they need to access Site C, when they connect to the GP VPN, all the traffic to 10.10.10.10 will go up to the Palo Alto GP, instead of directly to the switch. 

 

Because of various rules and regulations, we need to follow, split-tunnel is not an option. Also, the only PA gateway we have (at the moment) is in the Amazon cloud.

 

if there was a way to pick and choose the routes that the GP client overwrites, then this would fit the bill perfectly, however, this does not seem to be the case, or if there was some form of running a post-logon script, then this would also be a workable solution as we could try and inject the routes back in, dependent on location... 

 

I appreciate that this may seem like an odd setup... and thank you for your help!

thanks for the info...

 

Is Network "A" private.

Hmmmm tricky...

 

you are going to struggle with any pre logon stuff, interject or not as the vpn tunnel will be between device and PA.

 

OK so no split network so @kiwi option 1 is out.

 

not sure about option 2 as the internal gateway will still connect to PA.

 

you do have the option to just connect the client when needed, perhaps not practicle for your users.

 

or....

 

If site A is private then would you be allowed to split tunnel there.

 

a possible solution would be to have 1 portal with 2 gateways.

gateway 1 is full on access to all networks for peeps at home etc. route =0.0.0.0  via tunnel

gateway 2 is split tunnel for users at site A. route = site B & C via tunnel (so traffic for A stays local)

 

then... use "regions" to decide on GW auto selection. if user is connecting from region A (site A) then GW=2

all other connections then GW=1

 

probably other combinations possible including satelite etc but for GP you is limited.

 

  • 7266 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!