GlobalProtect access to local LAN devices

cancel
Showing results for 
Search instead for 
Did you mean: 

GlobalProtect access to local LAN devices

L2 Linker

I am fairly new to Palo Alto devices.  We are in the process of testing the GlobalProtect client and have set it up without split-tunneling.

I have confirmed this works for web browsing (get the PA NAT address), but we are still able to get to all local LAN resouces.  We are able to use local wireless printers, I am able to ping to and from the GP client on the local subnet.  Based on my previous experience with Cisco, without split-tunneling there was no access to the local LAN.  Is this how this works with PA or is something incorrect in my configuration?

Thank you,

Randy

11 REPLIES 11

L6 Presenter

Hi...There is an IP pool used for GP and this IP pool should be a new unused IP pool/range.  Make sure your LAN router has a route defined for this IP pool/range.  Thanks.

The IP pool is using a unique network that is not on the PC's LAN or overlapping with any subnets in the corporate LAN.

End User's IP 192.168.0.X/24

IP Pool 172.19.101.X/24

PA LAN 172.19.100.X/24

When the end user goes to www.whatismyip.com they are getting our NAT'd address and they are able to access corporate LAN resources, so I know split tunneling is not happening.  But they can get to their network printer on the 192.168.0.X network.  Also from another device on the 192.168.0.X I can ping the non-IP Pool address.  This piece acts like it is split-tunneled.

What do you have defined for the access route in the VPN's client configuration?  For split tunnel, you need to add only your LAN's subnet (i.e. 172.19.0.0/16) as the route.  This setting will then use the VPN tunnel for traffic destine for 172.19.0.0/16.

I am using 0.0.0.0/0 because we don't want split tunneling.  All traffic should be going through the PA.

There are a few things I can think of that may cause issue.

1) Internal host / Router do not have route back to GP network

- This will depend on your topology. It should work if the hosts have default route pointing to PAN. If there are router's between then check routing table for GP network.

2) Is GP in a separate zone than the LAN?

- Verify security rule allows the traffic

3) Is this multi VR environment?

- Need to verify next VR route

4) GP traffic sent internal is matching unintended NAT rule

- Easiest to view traffic log for session details. You can see more detail via CLI 'show session id <id number>'

If the problem is not obvious, you can post session information here or open a case with your support team for further troubleshooting.

- Stefan

The only way I can get it to work correctly as a test is to remove the local subnet from the GP client's routing table, i.e. from Windows: route delete 192.168.1.0 mask 255.255.255.0.  Then I can't reach other devices on the local subnet and vice versa.  Is this a bug in the the client?  This is also only a temporary fix, next reboot and it would be back.  Also not feasible to do.

The routing table also does include to default routes both of which are pointing to the VPN address and the local NIC interface.

Hi rgreenspon - we have same exact issue/concern with both windows and mac clients - running latest 1.1.7 gp client - did you get a permanent solution?

Never did find a solution.  It appears there is a vulnerability inherit in Global Protect.  I know Cisco does prevent this and was very surprised GP doesn't.  To me this is a critical issue, because it allows the systems to be compromised.

Thanks for the reply - I agree - we must be able to cut the GP client off their LAN!  I'm also surprised there would be no permanent solution for this yet!

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!