GP client upgrade fails to connect to portal after successful VPN connection?

[Adrian_Jensen]

I ran into an issue trying to push a GP client upgrade and seem to have run into a problem where, with multiple portals and gateways, the client can not reconnect to the same portal as it already authenticated against when connected to the gateway on the same ISP subnet. (i.e. you can no long ping/HTTPS to the authenticated portal, but you can to the gateways and all other portals/gatwways). Does anyone know why? I am still debugging, but it looks like the traffic is there, the portal is just not responding (or routing the response somewhere else).

I have a complicated config: 4 different ISP connections across 2 PaloAltos, each with a portal and gateway on separate IPs (required for different authentication methods on portal vs gateway). When connecting to any portal you get load balanced to an available gateway, which may be on the same ISP, or a completely different ISP/PaloAlto.

PaloAlto1	ISP1	portal-A.example.com	192.0.2.2
		gateway-A.example.com	192.0.2.3
	ISP2	portal-B.example.com	198.51.100.2
		gateway-B.example.com	198.51.100.3
PaloAlto2	ISP3	portal-C.example.com	203.0.113.2
		gateway-C.example.com	203.0.113.3
	ISP4	portal-D.example.com	233.252.0.2
		gateway-D.example.com	233.252.0.3

So in an example, if the GP client gets configuration from portal-A and then connects to gateway-C, the client can ping and download a GP update from portal-A without issue. But if the GP client gets configuration from portal-A and connects to gateway-A, the client can not ping or HTTP to portal-A any longer. It can still ping all the other portals/gateways. This break client updates for anything that load balanced to the same ISP as the portal connection.

At the moment I can't find any reason for it. In the Traffic logs you can see a successful TCP/443 connection (which would seem to be the initial GP portal authentication/config download). Then you see anther inbound connection with 0 response packets from the portal address.

[Mick_Ball]

OK clutching at straws here but could it be that your default gateway for users is towards the lan but as the isp is learned locally then it will try and go direct..  if so then perhaps a policy for GP zone to external interface would suffice...

[Adrian_Jensen]

That's OK, I'm clutching at straws as well... The users' default gateway is towards the VPN tunnel (always on setup), but the portal address is in the VPN bypass list (Portal -> Agent -> App config options). From the PA traffic logs it looks like the user is sending the update connection requests to the Portal (after successfully authenticating/connecting to the Gateway) over the public internet, but the logs show no reply packets. I updated PAs to 9.1.16 last night, but it didn't fix the problem.

I need to do some more extensive packet capture, but I suspect what is happening is that the user GP agent sends the connection over the internet to the public Portal address (outside the VPN) and then the PA sends the reply back across the established VPN, which is is wrong as the client would expect it on the public interface, not the private VPN. But I haven't gone far enough down that rabbit hole yet....

[Mick_Ball]

so via command prompt when connected to vpn try …..

tracert -d “your portal address”

and see what path it chooses..  

i think the app bypass is for GP enforcement, not always on….  So this will only come into play when vpn disconnected.  Try adding the portal address to the gateway split tunnel setting instead.

[Adrian_Jensen]

You may be on to something. Traceroute to the Portal in the same subnet as the connected Gateway returns zero results. Traceroute to the connected Gateway goes across the internet. Traceroutes to other Portals and Gateways (including registered Portal) seem to go across the VPN. In my previous testing i was sure that was also going across the internet to the other Portals/Gateways... Going to have to setup and retest from scratch again... I have other public addresses to DMZ devices in the same subnet range that respond, so going to have to look at my routing and U-turns pretty closely.