GlobalProtect Pre-logon tunnel rename doesn't work as expected

Showing results for 
Show  only  | Search instead for 
Did you mean: 

GlobalProtect Pre-logon tunnel rename doesn't work as expected

L1 Bithead

Hi Guys,


We are currently running PanOS8.1.1 have some issues with global protect pre-logon. I have configured pre-logon as per below article.


Problem we have is pre logon works as expected, however when user logged in to the computer, pre logon tunnel getting disconnected and connecting again with user logon.


What we want is prelogon tunnel to be renamed so for user vpn stays connected ater logged in


L4 Transporter

Hmmm, this sounds possibly like what we saw when we tried to upgrade to 8.1.1 all of our VPN users got dropped and the ones that could reconnect showed as pre-logon instead of their user names and they kept getting the authentication popups from the GP client. we ended up rolling back and have an open case with PA now


expected behavior was:

pre-logon connections is up->user logs into windows->VPN tunnel switches to user authenticated and pre-logon goes away



L1 Bithead

was there ever a resolution for this? I am currently experiencing the same issue with 8.1.13 and GP 5.0.8

L1 Bithead

 I am currently experiencing the same issue with 9.0.7 and GP 5.0.8

L1 Bithead

I had a very similar issue with pre-login (always on) connections, tunnel rename, and RADIUS-based MFA. Our portal login profile only requires username/password, but our gateways require MFA. We also had the "pre-login tunnel rename timeout" set to the default of -1 and users were experiencing all sorts of problems connecting after login.


Setting the pre-login tunnel rename timeout to 0 solved it (since you're requiring MFA during gateway login, there's no point in renaming the tunnel). So users are re-prompted for credentials and the MFA passes correctly.


I don't know if tunnel rename is supposed to work with MFA gateways and pre-login, but intuitively it really should not. PA's guidance seems to be only set the timeout to 0 when using pre-login then on-demand, but with MFA, I don't think the tunnel rename actually works correctly.

@kmuellercm the description of your setup sound like there should be something changed. I would use MFA already for the portal and then use authentication cookies for the gateway in order to ask the users only once for credentials. For security reasons on the gateway you use the sam RADIUS MFA authentication profile for situations where the connection comes directly to the gateway without the portal. At least this way it works for me (I also experimented with the value 0 but this resulted for me in problems because of the tunnel IP chance between prelogon and the usertunnel). In addition to the userlogin to gp I use an user-id agent setup because with the active directory logs the user is known a lot earlier on the firewall than it would be with the gp login which takes place when already the desktop is completely there. 

L7 Applicator

As per @Remo , we have all auth at portal and allow cookies on all gateways. Reducing the timeout by a large amount caused issues when moving out of wifi range and switching to mobile data (As expected).

The only thing that really changed was on the client-side (windows 10 upgraded to 20H2), but we couldn't find anything that the client was doing differently.

The portal (from my understanding) authenticates each time the config refreshes, so MFA would prompt the end-user for credentials each time it refreshes. So I just use a RADIUS profile that only requires user/pass and don't issue cookies from the portal.

Ultimately I want to replace this all with SAML-based login and pre-login VPN authentication, but that's a ways off. I just wanted to share a solution that I had to a particular problem I've run across, just in case someone else has a similar configuration and was banging their head against a wall like I was.

The gateway client settings is not properly selected when switching from pre-logon user to the logged on user


  • If "Pre-Logon Tunnel Rename Timeout (sec) (Windows Only)" is configured a value of "-1", this means the pre-logon tunnel does not time out after a user logs on to the endpoint; GlobalProtect renames the tunnel to reassign it to the user.
  • If it is configured a value of 1 to 600, this indicates the number of seconds in which the pre-logon tunnel can remain active after a user logs on to the endpoint.
  • This implies that the tunnel remains up and is only renamed from one user to another, which means the client settings on the gateway is not re-evaluated to match the logged on user, which is why the user has the same configuration as the pre-logon user.
  • 8 replies
  • 47 Subscriptions
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!