Created On 09/25/18 19:03 PM - Last Modified 07/29/19 17:51 PM
In pre 7.0. PAN-OS versions, when a GlobalProtect connection was established, users would have access to their local subnet. They would still be able to access local printers, local file shares, etc.
This presents a potential risk because one can print sensitive information and/or send this information to local file servers.
Since PAN-OS 7.0, administrators have a way to disable access to the local subnets. All requests to the local subnets will then be routed through the tunnel.
Note that this feature is not supported on iOS or Android clients, so it's Windows or OSX only.
This feature works with different network types. Some examples are hotel/public hotspot, private networks, systems with existing VPN or virtual adapters present, and systems using proxy servers.
Note that this feature supports IPv4 only.
How this works in Windows:
When GlobalProtect is connected, it will scan the routing table of the local PC and create new, masked routes for all existing local subnet routes with the exception of the localhost route (127.0.0.1) and self-pointing routes of physical adapters.
When GlobalProtect is disconnected, all these masked routes are removed.
If GlobalProtect terminates unexpectedly, the masked routes are removed shortly afterwards
by the OS because the GlobalProtect virtual adapter is no longer present
if the OS fails to do so, GP will remove them when it restarts
For example, the destination route can be masked as follows:
Note that split tunneling is overridden by this feature! Access routes will not work if you enable this feature, because they will be masked. There is no error or warning message and the 'Access Route' box is not grayed out. You will still be able to create access routes, but just keep in mind they won't work if you have enabled this feature.
For troubleshooting, note that there are no logs added in PAN-OS, PanGPA.log or PanGPS.log. You can see if the feature is enabled or not in PanGPS.log and PanGPA.log. This confirms that your gateway is sending down this configuration.
In Windows, check the Application and System logs for failures to create a route. In OSX, check /var/log/system.log for failures to create a route.