Palo Alto Globalprotect app to gateway communication impact because of free hotel Wi-Fi.

[nikoolayy1]

Hello to All,

We see issues when someone goes to a hotel and uses the fee Wi-Fi to start the Globalprotect agent application, because many hotels have SSL decryption proxy devices and the Globalprotect agent sees that the Gateway certificate is with wron CN name or if it is a newer proxy, it will be seen that the signing CA is different (similar to the Palo Alto SSL Forward proxy decryption and certficate emulation).

One option we think is to use the loopback option to use an other port than 443, so that stupid proxy devices don't try to decrypt the traffic.

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClGKCA0

I have checked and I don't see any option to make the globalprotect application to accept an unknown gateway certificate as this is major security hole. Also the Globalprotect starts with ssl/https before switching to ipsec, even when it is "ipsec prefered".

Can the globalprotect app start derectly with ipsec when connecting to a gateway without any ssl before that? Maybe if there is no SSL client authentication enabled on the gateway config?

If you have any other ideas, please share them.

[aleksandar.astardzhiev · Accepted solution]

Hi @nikoolayy1 ,

You have option to tell the client to ignore invalid certificate:

 I am surprized that hotel is doing SSL decryption to it users as there is no way for the users to have hotel CA trusted. This means that every freaking https site on the internet will trigger browser error. I cannot believe this is real...

Are you sure hotel is doing SSL decryption? Aren't they doing some kind of captive portal, that it will redirect any web request from the uers to the captive portal for either accepting the terms of use or authenticating. GlobalProtect have some capabilities to detect such captive portal and pop a message to user, but I don't have any experince with that.

[Remo]

Hi @nikoolayy1 

I think @aleksandar.astardzhiev is pointing to the right direction. I also assume the reason for the connection problems is because of captive portals. Depending which GP version you use this captive portal detection is working really good - as long as you are using a supported version (5.1 or 5.2). Prior to these versions we had some situations which lead to problems with this detection in combination with the captive portal detection of windows.

Anyway, if your problems are also because of captive portals then there are some settings which you need to check:

• Captive Portal Exception Timeout
• Automatically lauch Webpage in default Browser upon captive portal detection
• Display captive portal detection message
• Captive portal detection message

Depending on the other settings you use in your environment not all of the above settings are relevant.

[nikoolayy1]

Thanks for your replies. The message we see is when the user connects to the gateway not the portal, so the option with allowing an invalid  portal certificate may not help us and we have "Captive Portal Exception Timeout" configured as for the hotel paid Wi-Fi option there were no such issues and it also had captive portal that needed confirmation.

Maybe it could be that the other options could help as the certificate error was about wrong CN in certificate not wrong CA as it should be for the normal SSL certificate emulation.

I will do some captures and test your suggestions but just to ask if when the palo alto globalprotect app/agent is connecting to the globalprotect gateway is there a way to start directly with ipsec without any SSL/HTTPS traffic before that?

[Remo · Accepted solution]

Hi @nikoolayy1 

Even after your last comment I believe in the csptive portal theory. Here's why: the captive portal tries to redirect to the loginwebsite. Captive portals also do this for https traffic which could be the explanation that you see certificate mismatch errors. With such a captive portal often there is only port 80 and 443 allowed - at least prior to login. So ... gp is not able to connect to the portal which it does by default as a first step. If there is a cached gateway, gp continues to connect there. As you set it to prefer ipsec it tries this. If ipsec is blocked in this wifi network, then gp does a fallback to tls - which the captive portal redirecta again to the loginwebsite. So far about my theory. Obviously I don't know your situation exactly. Did you or one of your user try to connect - without vpn - to your portal website in the browser or another website? A good test website in such a case is http://neverssl.com .

[nikoolayy1]

I will test this if it is a portal and why the portal for the free wi-fi does not get detected and inform you about what we see. Maybe also because we have client ssl authentication even if the ipsec is not blocked the application will need first to use ssl traffic and then switch to ipsec.

[nikoolayy1]

Thanks for the help. After talking with the user I think that just the web blowser was not opened and the user did not know there was a captive portal so the "Display captive portal detection message" and "Automatically lauch Webpage in default Browser upon captive portal detection" should solve future such issues.

[nikoolayy1]

Extra issues I have found are:

%%%%%%%%%%

Many times when there is captive portal with ssl self-signed certificate if it is not confirmed the Globalprotect Agent will also show an error that the gateway/portal certificate is wrong/self signed. Also if "Enforce GlobalProtect for Network Access" is used you may need to exclude the domains (msftncsi.com) used by the operational system to detect the Wi-Fi portal. Please read the article below and don't forget that many web browsers block self signed ssl certificates and it is a real mess with captive portals that have such as captive portals without ssl certs are better handled https://docs.microsoft.com/en-us/windows-hardware/drivers/mobilebroadband/captive-portals

For Apple Mac it should be http://captive.apple.com/hotspot-detect.html :

https://discussions.apple.com/thread/7491051

For allowing Mozilla to not block self signed SSL cets stop the OCSP strapping and  for in the newer versions of Chrome and Edge there seems to be a bug when the captive portal is with self signed cert and I have not found a way to allow this:

https://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox/

Don't forget just in case to check globalprotect agent the PanGPS and PanGPA logs as they will show if captive portal detected and to as the customer to refresh the connection or reboot the pc as the max captive portal "Captive Portal Exception Timeout" is 1 hour.

%%%%%%

I have added them to my general Knowledge sharing article:

https://live.paloaltonetworks.com/t5/general-topics/knowledge-sharing-globalprotect-troubleshooting-...

[nikoolayy1]

Hello to All,

Again thanks for the help and here is a nice article about the issues I have seen and solved with globalprotect so far and there is some new information about issues with captive portals.

https://live.paloaltonetworks.com/t5/general-topics/knowledge-sharing-community-account-fix-and-glob...