GlobalProtect client behind a proxy, configuration help

Reply
Highlighted
L1 Bithead

GlobalProtect client behind a proxy, configuration help

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?

Highlighted
L7 Applicator

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

Highlighted
L1 Bithead

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?

Highlighted
L5 Sessionator

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

Capture.PNG.png

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

Highlighted
L1 Bithead

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.

Highlighted
L7 Applicator

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

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 Live Community as a whole!

The Live Community thanks you for your participation!