Captive portal / HTTPS / redirect / 8000
-
You can't without throwing certificate errors.
If you don't care about that (you should) just enable https logins in the captive portal config. It'll run https on port 8001.
-
Hi and thanks for reply,
As I said before after doing http://www.rocainet.com/2014/03/securing-captive-portal-login-page-on.html tutorial I get this error:
Port 8001 doesn't seem active at all (can't telnet)
Maybe I do something wrong with SSL cert…. :o :(
-
You can't telnet to an ssl port successfully. Not sure if what you're seeing is because of that or something else.
Anything in the logs telling you there's a problem?
What does this command show (if you're on 2.1.5)
ipfw_context -l
What about this:
netstat -an | grep LISTEN | grep 800
-
Hi,
Well now I see port 8001 as soon as I save CP setting with HTTPS enabled
But it tried forward to same URL… (http:///name.company.com:8000.....)Well I will check my index.php of CP
Seem my developers friends made some changes there (we have to change login page so developer made some changes) -
Hmm. Developer friends…
There is some logic in the redirection code in the stock index.php that determines whether or not to redirect to https. Maybe they broke it.
-
Hi,
Mostly you are right, here is output of netstat:
Before HTTPS enabled [2.1-RELEASE][root@wifi.company.com]/root(4): netstat -an | grep LISTEN | grep 800 tcp6 0 0 *.8000 *.* LISTEN tcp4 0 0 *.8000 *.* LISTEN After HTTPS enabled [2.1-RELEASE][root@wifi.company.com]/root(5): netstat -an | grep LISTEN | grep 800 tcp6 0 0 *.8001 *.* LISTEN tcp4 0 0 *.8001 *.* LISTEN tcp6 0 0 *.8000 *.* LISTEN tcp4 0 0 *.8000 *.* LISTENI will compate index.php before and after, and even with fresh pfSense index.php
Cause I install pfSense in VirtualBox and HTTPS workedThanks for reply… I will inform results...
-
Are you really not running 2.1.5? Why?
-
I am running 2.1-RELEASE (amd64)
Do you recommend update? -
Of course. to 2.1.5-RELEASE or 2.2-RC1. Not that it will fix your problem but there was a pretty good flurry of captive portal fixes after 2.1 if I am remembering right.
If I were you I would upgrade to 2.1.5, replace your index.php with the default, and test again. It works.
-
I will do same as you said
Let's see what will happen
I will keep you informedThanks
-
Well seems upgrade failed somehow
Have you ever seen this?
-
Let it run I guess.
-
I rebooted system now it is OK
Well upgrade changed index.php to default one and everything was OK CPBut replaced it with which I took backup before… and now I can see CP page as we designed
Also I found difference between index.php's, so will try to fix it... :) with developers :)They just made change it to get faster result, like work around, not know full CP options
-
Hi again,
Anyway is it possible configure CP with HTTPS and do not get HTTPS CERT ERROR (RED PAGE) while first browsing?
Thanks
-
Nope. Not a pfSense limitation. Think about it. CP is a man-in-the-middle. Exactly the type of thing HTTPS is designed to prevent.
In 2.2 there is a checkbox to disable redirects on port 443 if you have HTTPS logins enabled. This lets you enable the HTTPS login page and your users get automatically forwarded to it (without a cert error of you do it right) when they connect to a REGULAR port 80 HTTP site. But they don't get a cert error if they try to go to a secure site. It just hangs like when the HTTPS login page is completely disabled.
As more and more sites go https this will become more and more of a problem. Your instructions should probably include something like "open your web browser and go to http://mylogin.yourlocaldomain.com/" If you to that right (proper DNS Servers and domain search values), they should just have to type "mylogin" in the location bar.
-
Thanks for great reply
But for 100% confirmation I meant that, when user try to open any URL my pfSense redirects to CP, so if I enable HTTPS on CP, it directs to HTTPS CP page and user gets RED PAGE, confirmation etc.So I was thinking avoid it
-
If you turn on HTTPS logins in the captive portal and the user attempts to connect to a secure site and you forward them to the portal instead, there is nothing you can to do prevent the certificate error. Think about it. They tell their browser to connect to https://www.google.com/ and they get some certificate from your pfSense instead that has a completely different CN. Certificate error - always.
If you have HTTPS logins enabled and the user attempts to connect to an HTTP site on port 80, the CP will redirect them to the proper HTTPS port on the server name defined in HTTPS Server Name in the portal. It is up to you to obtain a certificate signed by something in the client's root certificate store and get it installed in the portal. If everything doesn't exactly match, certificate error generated by the browser.
HTTPS Server Name
This name will be used in the form action for the HTTPS POST and should match the Common Name (CN) in your certificate (otherwise, the client browser will most likely display a security warning). Make sure captive portal clients can resolve this name in DNS and verify on the client that the IP resolves to the correct interface IP on pfSense.The only way to guarantee certificate errors will not be generated by your portal is to enable HTTPS logins with all the proper certificates and hostnames and to be running 2.2-RC with the "Disable HTTPS forwards" option checked. You won't get cert errors any more but initial attempts to HTTPS sites will still hang.
There is nothing, NOTHING that can be changed in pfSense or any other captive portal to "fix" this. Captive portals break the internet by design.
ETA: https://www.startssl.com/ for free (really) certificates. And you'll get an S/MIME cert for email (also free) in the process. You, naturally, have to have control of the domain(s) under which you obtain certs.
