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

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

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

L6 Presenter

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.

4 REPLIES 4

L7 Applicator

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...

L6 Presenter

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....

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.

L6 Presenter

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.

  • 1589 Views
  • 4 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!