Not working captive portal in https

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Not working captive portal in https

L4 Transporter

Users report me problems, when  they launch web-browser with a website in https, captive portal is not shown and they can not surf on internet, but if they go into http website the captive portal is working. why is not being showed the captive portal in https webs?

1 accepted solution

Accepted Solutions

From LAN/trust to Internet/untrust port 443, ssl app. Maybe start with single destination webpage and when that one works apply decrypt rule for all. Avoid decrypting banking, health URLs... with no-decrypt rule above the general rule.

View solution in original post

11 REPLIES 11

L4 Transporter

you need to do ssl decryption to have it work on https

Do you have any example about how to configure decryptssl for https captive prtal?

Decryption is not specific for captive portal but it is for all kind of traffic passing through the firewall. Check the following document. You can prevent some traffic from being decrypted by creating a no decrypt rule.

 

https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Implement-and-Test-SSL-Decryption...

Lewis,

 

I was thinking of that doc but was not sure if it will work or not.

 

Regards,

Pankaj Kumar

Yes but im not sure about how is the policy that i should create in SSLDEcrypt.

 

Any / any decrypt?? which filter?? app ssl? this happends with all https webs...

For SSL sites to work properly in captive portal you should have decryption enabled and will need to have the captive portal set to redirect to a dataplane interface, preferably using a hostname that can be resolved internally and a certificate for that hostname

 

ssl decryption policy would ideally be any any 443 decrypt BUT if this is undesirable you could work with a certain URL category destination which could be a custom category with a URL each user needs to visit before being allowed to browse out, or 'obvious' categories for the first page in most people's browsers like 'search-engine' or 'news'

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

From LAN/trust to Internet/untrust port 443, ssl app. Maybe start with single destination webpage and when that one works apply decrypt rule for all. Avoid decrypting banking, health URLs... with no-decrypt rule above the general rule.

Its weird, because i dont have this problem and i dont have a SSL decrypt policy in my Palto.

 

For example, if users go to http://www.google.es the captive portal is showed and they can log in. However, if they go to https://www.google.es nothing is showed and they can not logging (the page shows nothing). 

 

this is why you need ssl decryption in order to deliver the captive portal page or https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Serve-a-URL-Response-Page-Over-an...

 

pankaj.kumar we have used this method to deliver reponse pages in the past but not captive portal specifically. I suspect it would work fine. We had to turn it off as it impacted one of our backend systems in unique situations that required an expensive upgrade on this backend system we were not willing to pay for at this time (nothing Palo Alto was doing wrong). However, delivering a response page without ssl decryption did work great. When users went to blocked categories on https it allowed them to get response page vs the white screen.

  • 1 accepted solution
  • 6800 Views
  • 11 replies
  • 0 Likes
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!