Palo Alto GlobalProtect
This topic provides configuration details that enable seamless interoperability between Palo Alto GlobalProtect and Netskope Client.
For scenarios where a Palo Alto GlobalProtect full tunnel is established, we recommend that you perform the following steps to ensure client traffic is bypassed to Netskope Cloud via the closest data center (POP).
Creating Netskope Address Objects
Creating Google Address Objects
Creating Address Groups
Adding Address Groups to Palo Alto GlobalProtect Gateway Exclude list
Verifying Changes
Note
You must add exceptions to your Netskope steering configuration to bypass VPN traffic. To learn more see: Exception Configuration for VPN Applications.
Environment
Palo Alto GlobalProtect account with admin level access.
Palo Alto GlobalProtect windows client version 4.1.0
Netskope Client
Interoperability Configuration Requirements
We recommend the following configuration requirement to ensure Netskope Client is able to steer traffic to Netskope cloud and also allow Palo Alto GlobalProtect to process its traffic without any conflicts.
Configurations in Palo Alto GlobalProtect
For scenarios where a PAN GP tunnel is established, we recommend that you perform the following steps to ensure the Client traffic is bypassed to Netskope Cloud via the closest POP.
In this step, create address objects and map it to Netskope IP ranges to be excluded from the Palo Alto GlobalProtect tunnel. The list of IP ranges for Palo Alto GlobalProtect tunnel bypass is listed here: (https://support.netskope.com/hc/en-us/articles/360036125714). In the following example, Netskope Range 1 is an address object for IP range 8.36.116.0/24.
Note
For simplicity we recommend using Netskope Range <x> as the name for address objects, where x is the range number. However, you are free to use a naming convention that suits your general practice and organizational guidelines.
Continue creating address objects (for example: Netskope Range 2, Netskope Range 3, etc) for all IP ranges as listed in the Range IP link.
Netskope client uses EDNS features in conjunction with Google DNS in order to accurately determine the closest Netskope POP. Therefore, traffic to the two Google DNS anycast IP addresses ( 8.8.8.8/32 and 8.8.4.4/32) needs to be allowed to go direct even in the full tunnel VPN configuration. In the example below, the address object Google Primary DNS maps to Google's anycast IP range 8.8.8.8/32.
Similarly create another Google Address object for 8.8.4.4/32
Address groups allow you to add one or more similar IP addresses to a specific group that can be added to the GP tunnel bypass configuration. For this use case, you will need two separate address groups, one for Google DNS and another for Netskope IP ranges.
Create an address group with the list of all address objects that map to Google anycast IP address created in the previous step.
Create an address group with the list of all address objects that map to Netskope IP ranges.
Note
NOTE: We recommend using the Netskope Cloud Dataplane name for the address group. You are, however, free to name them as per your general organization guidelines.
Locate the GP Gateway Configuration to be modified. Go to Agent > Client Settings
Select and edit the client configuration and add the two address groups to the Exclude section
Commit all changes to the running configuration.
Configurations in Netskope Client
When installing Netskope Client along with a VPN client, configure Destination Location exceptions in steering configurations to bypass traffic from the VPN client. To learn more about adding exceptions for 3rd party VPN apps, see Exception Configuration for VPN Applications .
From a Windows and Mac command / terminal prompt, execute the netstat -rn command and verify if Netskope and Google IP list go direct.
