GlobalProtect access to local LAN devices

[rgreens]

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

[rmonvon]

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.

[rgreens]

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.

[rmonvon]

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.

[rgreens]

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

[sspringer]

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

[rgreens]

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.

[jay.martin]

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?

[rgreens]

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.

[jay.martin]

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!

[BDBartlett]

Local LAN access (local as defined by the native/underlying IP subnet mask) is configurable on the Cisco IPSec and AnyConnect clients, but with GlobalProtect, it seems as though its built in as a 'feature', and no choice is available to the administrator (I'd really like to hear from PaloAlto tech guys on this - by design?  undocumented?).  Its a form of split-tunneling, allowing only local traffic (defined by subnet mask), and tunneling everything else.  In the case of IP range overlap, or mistakes in local subnet masking, there can be some very interesting/annoying scenarios that crop up.

I understand that local LAN access is often desirable by end users, particularly when wanting to print locally while 'in-tunnel'.  The machine itself is no more or less vulnerable to attack (from the local LAN) when it is 'in-tunnel', except of course that it can potentially be leveraged to compromise the protected network in real time.  There is little difference in my mind between a machine that can be compromised when it is not tunneled (assuming you are using the client on-demand) and one that can also be compromised while tunneled.  A compromised system is a compromised system - the protected network is vulnerable in either case - just a matter of degrees.  Windows (or other) firewall can/should be configured (by GPO in MS enterprise networks) to protect any machine that is going to spend any time on the 'dirty' Internet (hotels, airports, starbucks, home, etc), not allowing any connections TO the machine while 'offnet' (off the corporate network) - but I digress.

In any event, the admin of the GlobalProtect gateway should be able to choose the operating mode they desire - this is a major shortcoming if there is not that level of control built into the GP client/server, and PA needs to speak to this issue.  Have either of you opened a ticket on this?

[jay.martin]

I brought it to our SE who is making a case for this - he told me others have requested same.  One of the primary reasons they gave for having that way is for compulsory vpn connections to be able to still talk to captive portals in hotels, airports, etc.  I said, if that's the case, why not only allow the apps necessary to do captive portals and not wide open.

Fingers crossed they'll make it at least a configurable option for their customers...