Global Protect gateway is unresponsive

[palomed]

I have a GP user complaining about his GP sessions getting dropped. He's using certificate auth autovpn. The full error is 

[Error]: The network connection is unreachable or the gateway is unresponsive. Check the network connection and reconnect. 

Network discovery started.

Now while that is going on, I see in Monitor/Global protect at that time is repeated messages of the client in pre-login

before-login status and no IP address yet assigned. What is likely going on? Any other logs to review?

Type	Generate Time	Event ID	Stage	Source User	Source Region	Public IP	Public IPv6	Private IP	Private IPv6	Client Version
GLOBALPROTECT	2/14/2022 4:45	gateway-prelogin	before-login	ACME-67321211157	US	200.33.22.130	0.0.0.0	0.0.0.0	0.0.0.0	5.2.5
GLOBALPROTECT	2/14/2022 4:44	gateway-prelogin	before-login	ACME-67321211157	US	200.33.22.130	0.0.0.0	0.0.0.0	0.0.0.0	5.2.5

Client OS	Client OS Version	Repeat Count	Status	Login Duration	Error Code	Portal	Sequence Number	Action Flags	High Res Timestamp	Selection Type	Response Time
Windows	Microsoft Windows 10 Enterprise , 64-bit	1	success	0	0	GP_Gateway	27604518	0x0	2022-02-14T04:45:07.499-08:00
Windows	Microsoft Windows 10 Enterprise , 64-bit	1	success	0	0	GP_Gateway	27604477	0x0	2022-02-14T04:44:35.386-08:00

[mprintz]

Hi @palomed ,

We're having a similar issue, just using standard authentication, not certificates.  Were you able to get a resolution for the issue?  Thanks.

Matt

[MichaelMedwid]

Hi. We've had a lot of progress since then. One issue was upgrading to a more recent GP client. 5.2.12 

has been less problematic and worked past a known bug. I'm posting the login event phases you should

see in sequence as I was not clear on that part in February. Not that the get-config is when the address

is assigned. Also are you pulling down the GP client debugs? They have a lot of into including 

ipconfig /all, netstat -rn, GP events. I wish there was a way we could get that data without bothering

the user about it. But if you can get them to send it it's pretty insightful.

[mprintz]

For affected users, the only event we're seeing in the GP log on the firewall is portal-prelogin.  I've looked at the pangps.log from an affected client and it wasn't really helpful.  We've tried a few different GP versions, including the latest 6.1.0, and full uninstall/reboot/install.

Based on this thread, I'm thinking it might actually be a Windows update issue, but we haven't gotten to testing either uninstalling the October CU or installing the out-of-band patch noted there.  Thanks.

Matt

[MichaelMedwid]

Perhaps the the pan_gp_event log.would be more helpful? That's my go-to.

[mprintz]

I looked at that too, but it's just 2 generic errors that aren't helpful.  One says "No Network Connectivity" but that's definitely not correct because the users can do everything else on their computers, 90% of which is online.

[MichaelMedwid]

And just to confirm - Networking/Portals/(portal)/Agent/Configs/External is good for the DNS name or IP address? 

And there's no chance users are connected to a legacy VPN nor in a branch office when trying to connect to GP? I had more than 

one try to connect while on legacy VPN or from a branch office. Later added Internal host detection in tab Internal. 

[mprintz]

Yeah, we've been using GP for years and haven't changed the DNS name since we started.  The IP hasn't been changed for at least 2 years.  We have over 100 users connected right now.

The users are remote; we don't have any other VPNs we use and I doubt the users would know how to make their own 😂.

I just added the internal host detection today (as a potential fix to an unrelated cursor-changing-focus issue), but that's not going to do anything for remote users.

[MichaelMedwid]

Good luck! I think at this point I'd bring in TAC and let them sort it out. 

[n.major]

hey, did you resolved this issue?
i have the same issue with GP on prisma.

[mprintz]

@n.major I ended up opening a support case and after a month and a half of troubleshooting, they told me that it was a known bug fixed in 10.2.3, which was released a month before I even opened the case.  Upgrading to that version resolved the issue.