- 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.
10-01-2020 06:35 AM
Hi Everyone,
We are experiencing an issue with some of our Windows 10 laptops where if the user connects before the pre-logon tunnel establishes at the Windows logon screen, then they are presented with a Global Protect error saying 'VPN Connection could not be established' once the desktop loads.
I have checked the system logs during this process, and the strange thing is that the tunnel does get established and is up, even though GP says otherwise. However either the user needs to refresh the connection, or if you wait long enough GlobalProtect will auto refresh before it displays as connected.
The system logs look like the following;
<user logs into Windows, before pre-logon tunnel>
1 globalprotectportal-auth-succ Portal user authentication succeeded. User name: xxxx
2 globalprotectportal-config-succ Portal client configuration generated.
3 globalprotectgateway-auth-succ Gateway user authentication succeeded. User name: xxxx
4 globalprotectgateway-regist-succ Gateway user login succeeded. User name: xxxx
5 globalprotectgateway-config-succ Gateway client configuration generated.
6 globalprotectgateway-switch-succ Gateway client switch to SSL tunnel mode succeeded.
<user see's popup saying VPN failure>
7 globalprotectgateway-auth-succ Gateway user authentication succeeded. User name: xxxx
8 globalprotectgateway-regist-fail Gateway user login failed. User name: xxxx, error: Existing user session found.
9 globalprotectgateway-config-release Gateway client configuration released. User name: xxxx
10 globalprotectgateway-logout-succ Gateway user logout succeeded. User name: xxxx, Reason: remove previous login.
11 globalprotectgateway-regist-succ Gateway user login succeeded. User name: xxxx
12 globalprotectgateway-config-succ Gateway client configuration generated.
<user sees VPN connected message>
If the user waits for the pre-logon tunnel to establish (which sometimes its not easy to ask them to do this, you have to explain where to find the icon which shows this on the Windows logon screen) then the tunnel will establish with pre-logon user, and then rename when Windows loads - as per design.
Has anyone come across anything similar with people logging in before the pre-logon tunnel establishes?
Thanks in advance
11-24-2020 05:34 AM
We had a ticket open with support for some time, although the main issue that we were trying to fix was pre-logon tunnels not renaming, the problem in this post was also resolved along with the tunnel-rename issue being fixed.
What it came down to was routing from the internal network to the gateways.
As we have multiple internet circuits and a gateway on each one, we had to make sure that traffic was getting routed correctly. When we looked into this we found one gateway was going into a routing loop and we needed to put a PBF in place to make the traffic bypass the default PBF rules.
It's not a very detailed solution, but I hope this may point others in the right direction.
10-01-2020 06:56 AM
We are Running GP 5.2.2 with Prelog on always on no issues.
Our machine tunnel connects before user log on and GP shows connected.
We are using windows 10 laptops.
Make sure under Portal agent single sign is configured as Yes.
Regards
10-01-2020 07:11 AM
Thanks @MP18 , it works fine for us too - but only if you wait for the pre-logon tunnel to establish.
If you get your credentials in before that, then there are issues once Windows loads.
10-01-2020 07:12 PM
As per my understanding in our case we see user login prompt and we see sign in options.
Then if i click on sign in options i see GP icon shows connected in sec or 2
For prelogon always on we need to wait for few secs to get the GP machine tunnel built with user name prelogon.
I will say check the client side GP logs in your case if it takes more time to built machine tunnel?
Once PC is rebooted and login prompt is there then GP prelogon should connect with few secs
Regards
10-02-2020 08:31 AM
What build of the GlobalProtect Agent do you have deployed? I can't say that I've seen this issue in recent releases, but we did see it on occasion with old releases of the agent. However, post 5.0 and higher we've completely eliminated the issue getting reported within our environment.
10-05-2020 03:44 AM
We have the same result with some of our users, but others seem to take a long time to connect, causing them to log into windows before the tunnel is established, causing the problems when Windows loads.
It's a beta deployment before we roll out to a large user base, so its very likely others will log in before the tunnel comes up.
On my machine I have a tunnel within about 20s, but I've seen on others it taking up to 90 seconds.
Perhaps I should be looking at why the tunnel is taking so long to come up, rather than the issues after windows loads.
10-05-2020 03:48 AM
We have 5.1.5 running on the Firewall, but client side we have tried up to 5.2 with the same results.
I have a ticket open with support, but I'm considering now changing to Connect Before Logon, as the main purpose to deploy Pre-logon was to allow new users to connect to new laptops without having to connect to the domain first.
With the inconsistencies with Pre-logon I feel like connect before logon could be a better solution. I appreciate it works fine for others, but so far i've not had any luck and the support ticket has been going on for 6 weeks now!
11-24-2020 05:34 AM
We had a ticket open with support for some time, although the main issue that we were trying to fix was pre-logon tunnels not renaming, the problem in this post was also resolved along with the tunnel-rename issue being fixed.
What it came down to was routing from the internal network to the gateways.
As we have multiple internet circuits and a gateway on each one, we had to make sure that traffic was getting routed correctly. When we looked into this we found one gateway was going into a routing loop and we needed to put a PBF in place to make the traffic bypass the default PBF rules.
It's not a very detailed solution, but I hope this may point others in the right direction.
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!