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

[Namalw]

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.

https://live.paloaltonetworks.com/t5/Configuration-Articles/Basic-GlobalProtect-Configuration-with-P...

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

[hshawn]

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

[Jonathan_C]

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

[aabozaid]

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

[kmuellercm]

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.

[Remo]

@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. 

[Mick_Ball]

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).

[kmuellercm]

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.

[jmora]

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

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u000000HBx0CAG

• 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.