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

cancel
Showing results for 
Search instead for 
Did you mean: 

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

L4 Transporter

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.

2 ACCEPTED SOLUTIONS

Accepted Solutions

L4 Transporter

Hi @NikolayDimitrov ,

 

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

AlexanderAstardzhiev_0-1622129058186.png

 

 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.

 

AlexanderAstardzhiev_1-1622129349414.png

 

View solution in original post

Hi @NikolayDimitrov 

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 .

View solution in original post

6 REPLIES 6

L4 Transporter

Hi @NikolayDimitrov ,

 

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

AlexanderAstardzhiev_0-1622129058186.png

 

 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.

 

AlexanderAstardzhiev_1-1622129349414.png

 

View solution in original post

Hi @NikolayDimitrov 

I think @AlexanderAstardzhiev 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.

 

L4 Transporter

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?

Hi @NikolayDimitrov 

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 .

View solution in original post

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.

L4 Transporter

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.

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!