- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Just completed an install this last weekend and received a report that a user wasn't able to connect to GlobalProtect. I started with the normal troubleshooting and quickly realized this was going to be something more detailed.
The user that initially complained said that she wasn't able to connect to GP. I asked them to just try to hit the portal with a web browser and make sure she could get there first. Nope, can't reach the portal via a browser.
Next step I did some monitoring and packet captures on the firewall and verified I can see their traffic hitting the firewall on the GP portal address but I'm only seeing packets in one direction. I see the client hello in the packet capture but I don't ever see the server hello and then certificate exchange, it just stops there on the client. Performing a packet capture on the firewall I see in the tx capture that the server hello is being sent and also verified this with a packet capture downstream from the firewall. The server hello just never makes it to the remote client.
The client is able to ping the GP portal fine.
It appeared that this was an isolated issue with this one client, but I'm now finding that my cell phone, when on my home Internet, I'm able to connect, but on AT&T wireless I'm not.
Any one have any ideas?
One more piece to the puzzle. The client is able to connect to other devices with SSL on the same network here and is also able to VPN to the existing Cisco ASA that's here without any issues. The only issue is to the GP portal.
I sat on a call with Palo support for the last two days without any resolution.
Hardware: PA-460 in HA
GP versions tried 5.2.10 and 6.0
Can't say I've had this particular problem, but a couple things to investigate come to mind.
1) Are you running dual-ISP? Could it be trying to send the reply out the other uplink which is getting dropped by the ISP? (I have seen this in the PA where it receives a request on WAN1 188.8.131.52 and replies out the WAN2 184.108.40.206 interface with a source IP of 220.127.116.11, getting dropped as a bogon by ISP2.)
2) Are you pointing the client address somewhere else in the routing table? I.e. reply goes to an address that actually routes to your internal/etc. interface.
3) Are you using a blacklist on input/output. We are running several dynamic blacklists and occasionally some updates with an unexpected IP.
Edit:... grrr... re-reading I now see that you say the client can ping the Portal... so that seems to throw out several of my ideas.
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!