Bug #14266
closed
Bug Captive Portal first access URL in HTTPS
0%
Description
Good afternoon,
I'm using version 2.6 of the system, I tried this week to increase the use of the captive portal in my scenario.
However, when the user accesses a url in https (example: https://www.google.com) and the user is not yet authenticated, the captive portal does not open (giving a connection time error), whereas when the url is http (for example: http://google.com.br) the captive opens normally.
Taking into account that today there are almost no http pages, what would be the feasibility of adjusting the bug so that captive works correctly in this situation above.
Tests were done with several people who use pfsense, and all report this same problem.
This bug is not the same as #13212, I am not trying to open the captive page in https, but the problem is when a user not authenticated in captive, tries to access a url in https for the first access.
Thanks
Updated by Jim Pingle about 2 years ago
- Status changed from New to Rejected
As I mentioned on the other issue you opened (#14263), there isn't anything else you can do here.
There is no way for the firewall to redirect someone's HTTPS request anywhere due to the secure nature of HTTPS.
Modern clients are usually smart enough to detect the portal even without a redirect and offer to take the user to the login page.
You may have better luck with that by enabling HTTPS logins for the portal itself as mentioned in that other issue.
You should at least try a 2.7.x snapshot to see if the behavior is better there, too. A number of captive portal bugs have been fixed since 2.6 released.