- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
on 04-10-2020 12:08 PM - edited on 10-03-2022 09:51 AM by jforsythe
In my previous article, "GlobalProtect: Authentication Policy with MFA," we covered Authentication Policy with MFA to provide elevated access for both HTTP and non-HTTP traffic to specific sensitive resources. You can see a diagram of the environment here.
In this post, we are going to add pre-logon authentication using machine certificates.
The value of pre-logon authentication means that a device can be connected to a gateway before an actual user logs into the machine, allowing certain internal resources to be accessible or scripts to be run. For more information about pre-logon, please review this TechDocs article: Remote Access VPN with Pre-Logon.
Hopefully you see this and can offer some advice. We have pre-logon set up and was working in testing. As it relates to the gateway, we have the following client configs:
Pre-logon
Students
Staff
Each has their own IP Pools. When you boot you successfully authenticate to the gateway in the pool for pre-logon. When you log on we are seeing the user stay in that pool but show the proper username. If you do a "refresh connection" you land in the proper ip pool based on user. Have you seen this?
Hi Brian,
I haven't seen this behavior before. That stated, it seems logical that this would occur because the tunnel and its corresponding IP address won't refresh when the user changes from Pre-logon to the actual user's account. What is the reasoning behind the multiple client configs and pools?
-Spencer
Thanks for your reply. The engineer that installed our palos originally set it up that way (different ip pools for different users groups - students vs staff vs it staff) prior to me implementing pre-logon. In an on-demand world it worked fine. It makes sense to me to have different pools. Are you saying that you don't think it will ever switch during a logon? I don't think the user changes until they're fully logged in (desktop visible) so it could happen then and not have any impact. Perhaps something is wrong, because our clients do actually disconnect from GP as they are logging on. I see the client go through "Connecting" again.
Hi Brian,
It wouldn't hurt to open a case just to validate the behavior. I would think that if it doesn't go through a full refresh of the connection then it would retain the existing IP.
In the past with traditional VPN concentrators I have seen the use of different IP pools as a mechanism to segment user traffic at the network layer. Many times this was because there was lack of security capabilities beyond basic ACLs to control user access after authentication on the concentrator, and segmenting traffic at layer 3 would allow security admins to control the traffic in different ways as it traversed the rest of the security stack (i.e. firewall, IPS, content filter, etc.) to access internal resources and the Internet. My recommendation would be to explore the Source User and HIP aspects of security policy. As every user must authenticate to use GlobalProtect for access, you will have a user mapping as well as host information that you can leverage to determine identity/posture and subsequently enforce policy based on that context. In other words, leveraging a policy construct based on those elements makes it unnecessary to split users up into different pools. I would just have a single pool because there is no loss in visibility or granularity of control. Not sure if that is helpful or not, but I just thought I would share what I've seen and recommended while in the field :).
-Spencer
Thanks for taking the time to reply. I know you were waiting with anticipation on the answer... I heard back from support - sounds like I just needed to change the pre-logon tunnel rename timeout from -1 to 0.
Pre-Logon Tunnel Rename Timeout (sec) (Windows Only)
This setting controls how GlobalProtect handles the pre-logon tunnel that connects an endpoint to the gateway.
A value of -1 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. However, the tunnel persists even if the renaming fails or if the user does not log in to the GlobalProtect gateway.
A value of 0 means when the user logs on to the endpoint, GlobalProtect immediately terminates the pre-logon tunnel instead of renaming it. In this case, GlobalProtect initiates a new tunnel for the user instead of allowing the user to connect over the pre-logon tunnel. Typically, this setting is most useful when you set the Connect Method to Pre-logon then On-demand, which forces the user to manually initiate the connection after the initial logon.
I would like to share my experience with GlobalProtect which forced me to use different IP pools instead of relying on user identification. We use Active Directory authentication via RADIUS profile for our users. If a user connects via GlobalProtect and then logs via Remote Desktop on a machine in internal network, connected user losses it's association to the IP address received from VPN pool, and is associated with the IP address of remote machine on which he/she logged. All the user can do is work via established RDP session until it disconnects. When RDP session disconnects, VPN connection must be reset, as no other session can be made from the client's IP (because rules are user-based, and Palo Alto Firewall no longer associates IP address of GP client with that user, so request are not recognized as coming from that user). Because of this we made several IP pools and we make rules based on IP addresses instead of users. I feel that this is wrong, but can't find a way around the user identification problem.
@brianjreed thanks for finding that setting.
I have 2 gateways... pre-logon users all go to gateway A. Post-login, default users stay on gateway A but a certain user group needs to connect to gateway B. The trouble is that the user group was staying on A instead of switching to B. So hopefully this timeout will fix my issue.