Global Protect switching from Pre Logon to User

[ksauer507]

Hello,

We have an issue where many times Global Protect clients are not switching from the Pre Logon user to their logged in user name.  Certs are deployed and Pre-logon access works.  IT can remote on to troubleshoot a PC that is just at the windows lock screen.  We can ensure the PC has access to WSUS for updates, etc...  Obviously they have domain authentication access to login and run login scripts etc.  Then after 60 seconds its supposed to switch to their user, which has more access and based on their LDAP groups.  The user login is SAML to Azure AD and every 14 days does require a Duo mfa prompt.

Whats happening is many times the user connects, all their apps start opening and then everything disconnects.  Teams is a real bear keeps asking to sign in.  Then if you go to the tray the GP icon has red X on it.  Click it and it says the network connection is unreachable or the portal is unresponsive.  Check the network connection and reconnect.  If you click the blue connect button, it says connecting, and then in about 10 to 15 seconds its connected and you can restart a lot of the apps that are in a stuck state due to network issues.

A few things about the setup.  In prelogon we give a different IP address.  When you login users get one set of IPs, vendors another, and IT yet a third.  This helps with other access lists, like for example theres ACLs on switches and stuff only IT can get to.  Vendors stay on their own subnet and zone, etc...  I'm wondering if this IP switch is part of the problem?

For example, I booted up, logged in, and I seemed ok and my IP address was 192.168.54.31.  Then I lost everything.  Had to click connect on the GP tray icon and it authenticated me fine and my IP is 192.168.59.201.  Do you think we have to keep prelogon and users in the same subnet / network?
This is Global Protect App version 6.1.2-83 on Windows 11.
Connected to PA 1420's running 11.1.2-h4
We do full tunnel.

We deny local network access. For example I cant ping my home printer from my work laptop, etc...

I seem to remember on our older 3220's this was consistent, but we used a different IP scheme.  Everything was 192.168.55.x prelogon and all.  But the 3220s were on 10.1.10-h4

Any ideas how to make the switch from prelogn to logged in user seemless?

[BPry]

@ksauer507,

You should be able to look at the user-id logs on your firewall to identify if you have any events to map the IP to the user or not. I would guess that your hypothesis is correct and what you're running into is that the IP switch that you're having them do is losing the user-id mapping. The authentication event gets the pre-logon IP mapped as the user, and when your user gets the new IP address there's no user-id mapping to grant them access through your security rulebase.

You could always add different gateways if you require different subnets to be used for these three groups. Your Portal address could stay the same and then you would just point each user group to the required gateway to isolate them. Generally this is what I would recommend as it also allows you to land them in their own zone to completely separate the traffic.

[RH747]

Without seeing the GP Monitor logs it's hard to say what could be the root issue. Do you have access to these logs? Check them and note where the failure point is for more clarity on the issue. Seeing what happens at the interim step of portal-prelogin and portal-auth would be of particular interest since that's where you'll pull your user-specific IP.

From what it sounds like based on your description it could be the gateway agent client settings as that defines where users are going to be pulling their IP's. When you say you logon, do you mean log into GP or the device? Is your GP configured to pull Windows credentials or have the user login manually? Correct me where I may be wrong, but the string of events read as:

• User logs into device
• Device is already registered into pre-logon via machine cert, etc
• GP disconnects pre-logon connection due to 60 second disconnect rule
• GP does not pull the user's windows credentials properly and fails
  
  • Failure point - does GP actually fail here or is this a limitation of your configuration? Logs would give more insight
• User must sign in manually to regain access to gateway and pull proper IP

[ksauer507]

RH747, you have the series of events correct.  The failure point and its intermittent, is instead of switching to the logged in user after 60 seconds it just disconnects.  That requires the end user to click the system tray, open up Global protect and hit connect manually.  We tried upgrading to 6.1.5 GP and same issue.  We came up with another workaround on Sunday and so far Monday / Tuesday we haven't had any complaints.

1.  Created a cookie auth to help with MFA "every time" you connect.  It should MFA once a week.  Otherwise it will just pause the desktop until the MFA is completed every single time on the same computer.  We had this on our PA-3220's and forgot about it when we moved to the PA-1420's.

2.  We disabled the login script from even running on startup by setting the pre-logon timeout to 0 and instead used a GPO to registry edit HKLM\SOFTWARE\Palo Alto Networks\GlobalProtect\Settings\post-vpn-connect, value name command, REG_SZ, value data \\domain.com\NETLOGON\logonscript etc....
Using item level targeting, this is applied if the file C:\Program Files\Palo Alto Networks\GlobalProtect\PanGPA.exe exists.

Now the logon scripts run after GP switched over to the user (so its not running as pre-logon).  This aids in scripts that half complete due to taking longer than 60 seconds.  That happens once in awhile if we are pushing some update in this time.

By changing the prelogon delay from 60 to 0, it switches right away, every time.  The side effect is the login script in Active Directory doesn't run, hence the GPO workaround.

So far so good.