Global Protect client not isolated

[MarkDufault]

If you are using Global Protect AND you have split-tunneling enabled. Your PC is accessible via the local LAN. So if your in an insecure location the other people on that LAN can hack at your computer. If you don't believe me try it out. 

[TomYoung]

Hi @MarkDufault ,

Have you tested with the "No direct access to local network" box checked?  https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000PPbACAW  This should disable local LAN access.

It is also good to know how the Exclusions tab interacts with this feature.  https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u0000001V2dCAE

Thanks,

Tom

[rbellare]

That is the way we had it configured. "No direct access to local network" configured with split tunnel. The problem is that if we add any IP or domain under exclude, the "No direct access to local network" setting is overridden inbound. The GP-connected device cannot access the public or home network, but devices on the said public or home network can access the GP-connected device. The assumption would be that the exclusion would be applied to only the IPs or domains in the exclusion list. No so.

Specific Example. On our GP gateway, we have "No direct access to local network" enabled. We exclude IPs for Microsoft updates and Teams, Zoom, and Webex, as well as domains related to Zoom and Webex. Now an enterprise laptop, connected to a home network with IP 192.168.0.16, with GlobalProtect enabled, cannot ping or connect to anything in the 192.168.0.0/24 local network. But a device on the local network, say 192.168.0.10 can ping and RDP to 192.168.0.16. That is a problem.

We currently have removed all exclusions, and "No direct access to local network" works as expected. 192.168.0.16 cannot connect to 192.168.0.10, and 192.168.0.10 cannot connect to 192.168.0.16. This means that "No direct access to local network" is an all-or-nothing function. At least that is the way I see it. We have a ticket open with Palo Alto, and the engineers helping me on the case have verified what I have said and told me that is the case. They have made a "feature request" on our behalf.

The second link you provided (https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u0000001V2dCAE) states the following:

• The 'No direct access to local network' feature in GlobalProtect is used to block outgoing connections originating from the endpoint to the local subnet using the physical network adapter when GlobalProtect tunnel connection has been established. 
• GlobalProtect application does not block incoming connections.
• On Windows OS, when 'No direct access to local network' is enabled and domain/application split tunnel is not configured, the GlobalProtect client enables "weak-host-send" on the physical adapter (Windows feature), this allows the response packet for the incoming traffic to go through the tunnel and hence the connection cannot be established.
• MacOS does not have such a feature as Windows OS therefore incoming connections will work.
• If there is a requirement to block incoming connections, then the recommendation would be to use the native OS firewall on the endpoint or any other endpoint firewall product.