GlobalProtect client behind a proxy, configuration help

[bigtone]

I am trying to establish an ssl vpn connection using the globalprotect client, but the client is behind a proxy using a configuration script.  I have tried calling paloalto support but they said their client is not proxy aware.  Does anyone know of some things I could try to get the globalprotect ssl vpn client to work from behind a proxy?

[gwesson]

GlobalProtect is indeed proxy-aware. Prior to version 1.2.6 there was a failure to detect a PAC file when connecting to the gateway, but that was resolved.

Depending on how the portal and gateway are reached, you may have to modify the registry if the Gateway and Portal have different directives. From the release notes:

=====

54487— GlobalProtect was failing to automatically discover Web Proxy Autodiscovery Protocol (WPAD) and proxy auto-config (PAC) settings and was not connecting to the proxy portal. This did not occur when the proxy was configured statically using the web interface.

54230—GlobalProtect was failing to automatically discover proxy auto-config (PAC) settings and was not connecting to the proxy gateway. With the fix, GlobalProtect will now use the same proxy server for the portal and gateway, as determined from the PAC file. If the PAC file has specific directives to use a different proxy server for the portal and gateway(s), then a registry setting must be added on the client:

HKEY_LOCAL_MACHINE\SOFTWARE\Palo Alto Networks\GlobalProtect\PanGPS.

Create a new key named ProxyMultipleAutoDetection, with a type of DWORD and a value of 1. This key is only required if the PAC file specifies a different proxy server for the portal and gateway(s).

=====

The challenge may be in the initial discovery of the PAC file, but if using something like wpad.dat or the proxy configuration from Windows (assuming a Windows client) Internet connection settings, GlobalProtect should have no problem connecting using the proxy settings.

-Greg

[bigtone]

thanks for the reply greg, I have notified support.  We tried the registry changes and we are still getting a "gateway x.x.x.x: proxy authentication failure." message.  Do you have any other suggestions for us?

[mbutt]

Another thing you can try to do is set the proxy settings in the browser manually and test to see if this works.

If doing this works and you have made sure that you are on the latest release of the GP client in which the fix is there as per Greg. I think then you might be running into some bug or configuration issue and will need to open a case with support.

Hope this helps.
Best Regards,

Numan

[bigtone]

We use an automatic configuration script but yes I have also tried putting in the ip address and port of the proxy server with the same proxy authentication error.  When I do a packet capture while trying to connect I see that the GP client tries to do an HTTP CONNECT to the ssl gateway on port 443.  I believe that is what my proxy doesn't like.  I think the proxy will allow http on port 80, but not 443.  When I manually type in my browser http://hostname:443 I get this

The Proxy received an invalid response.

URL: http://67.214.245.37:443/

In the packet capture I get an http 407 authentication required from my proxy...any other ideas.

[gwesson]

An HTTP CONNECT is the correct type of request for an SSL site when using a proxy. The CONNECT request is actually on port 80, and is an instruction to the proxy that it should connect to the site using port 443. The manual 'http://hostname:443' is not quite the same thing that the GP client will use.

A raw HTTP request on port 443 would look like:

TCP Destination Port: 443

GET / HTTP\1.1
Host: hostname.example.com

Whereas the CONNECT would look like:

TCP Destination Port: 8080

CONNECT HTTPS://67.214.245.37:443/ HTTP\1.1
Host: hostname.example.com

If your browser also uses a proxy, you can go to "https://67.214.245.37:443" and it should return valid data. A packet capture would show the CONNECT request from your browser as well.

Hope this helps,

Greg

[Metgatz]

Hello @bigtone 

Two things:

It is one thing for the client to be behind a web proxy:

There it is only enough that at the Proxy config level, allow or bypass the URL and/or subdomain of global protect, example:

https://yourpublicIPoryourpublicsubdomainortheoneyouuse/*
https://yourpublicIPoryourpublicsubdomainorwhicheveruses globalprotect/global-protect/*
https://yourpublicIPoryourpublicsubdomainortheoneyouuse globalprotect/global-protect/login.esp

Example: vpnglobalprotect.acme.com or la IP publica, si que usas la Ip publica y no un subdominio 200.200.200.200 por dar un ejemplo.

Now if apart from the client be behind the proxy and at the same time behind Palo Alto itself.

On Palo Alto you must configure a no NAT rule.

A source zone rule, the internal zone(s), pointing to the external zone, untrust, the wan zone of the firewall and the public IP and/or FQDN subdomain of the firewall and not setting any type of translation, that is, no NAT and It will already allow you to connect to Global protect from the Internal network.

Also you can check, at level App Portal Global protect config, the option: 

Detect Proxy for Each Connection
(Windows only)
Select No to auto-detect the proxy for the portal connection and use that proxy for subsequent connections. Select Yes (default) to auto-detect the proxy at every connection.

Best regards