The option to

Update DNS Settings at Connect (Windows Only)

, which is available in the GlobalProtect portal agent configuration as an app customization, now applies only to GlobalProtect apps 4.0.2 and earlier releases. For GlobalProtect app 4.0.3 and later, you can configure the new

Resolve All FQDN Using DNS Servers Assigned by Tunnel (Windows Only)

option. For more information, see Features Introduced in GlobalProtect App 4.0.3.

On the macOS image, boot into Recovery OS and use the spctl kext-consent command to disable the user approval requirement completely or specify the Team ID PXPZ95SK77 to allow Palo Alto Networks as a KEXT that macOS can load without user approval.For Mac endpoints managed by mobile device management (MDM) systems, all endpoints with a valid MDM profile installed which specifies the Team ID PXPZ95SK77 do not require user approval to load any properly-signed kernel extension.All third-party KEXTs that were already installed at the time of upgrading to macOS 10.13 are automatically approved and don't require any user action. For unmanaged devices, if a user sees the popup after upgrading to macOS 10.13 (and you have not performed one of the above fixes), the user must follow the on-screen instructions to allow Palo Alto Networks to load kernel extensions. For additional information on this pop-up and the recommended fixes, see Apple Technical Note TN2459.

GlobalProtect can now automatically retry the connection when network disconnects occur due to network instability or endpoint state changes. For more information, see Features Introduced in GlobalProtect App 4.0.3.

To improve the logic the GlobalProtect app uses to select the best gateway, the app now prioritizes the gateways assigned highest, high, and medium priority ahead of gateways assigned a low or lowest priority regardless of response time. Previously, the app would connect to a lower priority gateway only if the response time for the higher priority gateway is greater than the average response time across all gateways. For more information, see Features Introduced in GlobalProtect App 4.0.3.

In macOS 10.13, Apple introduced a new feature that prompts users to approve any third-party extensions (KEXTS). Although the GlobalProtect app is compliant with the KEXT change, the pop-up prompts can cause confusion for users. For enterprise deployments where you must distribute software that includes kernel extensions without requiring user approval, there are two options that prevent the user pop-ups when installing GlobalProtect:

All third-party KEXTs that were already installed at the time of upgrading to macOS 10.13 are automatically approved and don't require any user action. For unmanaged devices, if a user sees the popup after upgrading to macOS 10.13 (and you have not performed one of the above fixes), the user must follow the on-screen instructions to allow Palo Alto Networks to load kernel extensions. For additional information on this pop-up and the recommended fixes, see Apple Technical Note TN2459.

Traffic on a loopback interface is no longer blocked when you Enforce GlobalProtect for Network Access (

Network

GlobalProtect

Portals

<GlobalProtect-portal-config>

Agent

<agent-config>

App

App Configurations

) and GlobalProtect is not connected. This change allows local applications that use ports for internal communication to run without a GlobalProtect connection. Previously, applications using the loopback interface failed.

If you Allow User to Disable GlobalProtect app, the Disable Timeout now applies when the user disables the app using any method (passcode, comment, or ticket), instead of just applying when users use the ticket method (

Network

GlobalProtect

Portals

<GlobalProtect-portal-config>

Agent

<agent-config>

App

App Configurations

).

The name of the GlobalProtect gateway subscription has changed to GlobalProtect subscription. A GlobalProtect subscription is required for the following features: HIP checks and associated content updates, support for the GlobalProtect mobile app, IPv6 support, and GlobalProtect Clientless VPN.

GlobalProtect app behavior for the

App Configuration

Allow User to Continue with Invalid Portal Server Certificate

has changed. Prior to this change, if the server certificate verification failed (for example, the user was behind a Captive Portal network) the GlobalProtect app warned the user but still provided the user an option to continue with the connection. With this change, as long as a valid cached portal configuration exists on the endpoint, GlobalProtect will no longer continue with the portal connection if the server certificate verification fails; instead GlobalProtect uses the cache configuration to continue the connection to the gateway. This change prevents the user from accidentally continuing the connection to a man-in-the-middle (MITM) site.

As a best practice, use a server certificate from a trusted root certificate authority (CA). However, if a non-trusted CA (such as a self-signed CA) issued the server certificate, then this change might impact user connections. To avoid disruption before the initial attempt by a GlobalProtect app to connect to the portal, select

Network

GlobalProtect

Portals

Agent

and

Add

the server certificate CA to the Trusted Root CA list.

If you missed this step and made a configuration error and the user is now in a state where the initial portal connection was successful and the server certificate did not come from a trusted root CA, follow this procedure to recover the endpoint: