Odd GlobalProtect issue

[campbech1]

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

Version: 10.1.4

GP versions tried 5.2.10 and 6.0

[Adrian_Jensen]

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 1.2.3.2 and replies out the WAN2 7.8.9.2 interface with a source IP of 1.2.3.2, 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.