GlobalProtect user authentication delay after pre-logon
29158
Created On 12/20/20 17:37 PM - Last Modified 04/19/21 17:09 PM
Symptom
When a GlobalProtect Gateway is configured on an interface different from the one which the Portal is configured on, there may be a delay during user-logon following pre-logon connection. This issue does not occur when the Gateway and Portal share the same interface and IP address.
Environment
- GlobalProtect
Cause
GlobalProtect client needs to ensure that its connection to the Gateway is sent over the main endpoint adapter, and not tunnelled through the GlobalProtect virtual adapter itself.
The mechanism that it uses to achieve this is to install a /32 masked route towards the Gateway IP address via the main adapter. This is to ensure that it doesn't get caught by a wider network which might be routed through the tunnel, such as 0.0.0.0/0.
In the example below, the Gateway IP 80.80.80.80 is added to the routing table with a subnet mask 255.255.255.255 towards the WiFi adapter default gateway.
With pre-logon, when "Pre-Logon Tunnel Rename Timeout (sec)" is set to -1 or a non-zero value, the pre-logon tunnel will persist after the user logs in, will be waiting to be renamed when the user authentication occurs.
Before this happens, the user-logon will initiate a connection to the Portal to check for related config. If the Portal is also using the same IP address as the Gateway, the /32 masked route to this IP will ensure that the connection is sent over the physical interface.
If the Gateway is using a different IP than the IP of the Portal, the Portal address is not covered by the /32 masked Gateway route and the user connection will not happen until the Portal connection times out - which is based on the 'TCP Connection Timeout (sec)' setting. By default, this is set to 5 seconds and will likely not be noticed by end users, but if this setting is increased to a higher value, end users may sense the delay while switching to the user tunnel.
In the example below, the 2nd Gateway IP 40.40.40.40 is added to the routing table with a subnet mask 255.255.255.255 towards the WiFi adapter default gateway, but the Portal IP 80.80.80.80 will match the default route towards the GP tunnel. In this case, the Portal connection may be dropped due to policy-deny, and will need an additional security rule configured.
Resolution
There are two ways to overcome the delay:
Option 1 - Add a security rule
Portal connection is being tunnelled through GlobalProtect, so a security rule having the parameters below will allow the connection:
From: Globalprotect zone (The zone assigned to the tunnel interface which is configured on the GlobalProtect Gateway)
To: The zone which is assigned to the interface with the Portal IP address (Typically untrust)
Application: ssl
Note: You may notice that this inter-zone policy is not needed when the Gateway and Portal are on the same IP address, that is because the Portal connection is not being tunneled and will hit either the default intra-zone allow rule, or a specific rule which was already configured.
Option 2 - Add an "Exclude Access Route" for the Portal IP
Adding an "Exclude" route for the Portal IP will install a /32 masked route via the physical adapter. This will ensure that the Portal connection is not tunneled, and will use the security rule is in place which has already allowed the access.
In the example below, you will see both the Portal and Gateway routes via with WiFi adapter.