- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
11-15-2013 01:28 PM
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?
11-15-2013 02:43 PM
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
11-22-2013 01:53 PM
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?
11-25-2013 11:33 AM
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
11-27-2013 09:24 AM
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. |
In the packet capture I get an http 407 authentication required from my proxy...any other ideas.
11-29-2013 07:18 AM
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
11-07-2022 08:28 PM - edited 11-07-2022 08:39 PM
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
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!