Captive portal slow redirect to login from https pages
-
Hello everyone,
I'm experiencing a weird issue with the captive portal:
whenever i try to access an https site and i'm not yet authenticated i don't get redirected to the login page.
for instance: if i try to open a page like http;//www.google.com and i'm not logged in, i immediately get redirected to the captive portal login page.
if i do the same thing but let's say with https://www.facebook.com or https://www.gmail.com the redirection takes ages and in many occasions in never occurs.
i've tried reviewing my firewalling rules but without any result as they look simple and fine.
any suggestion is really welcome.
i'm using freeRADIUS with mysql backend. -
I'm not sure there is an easy way to fix this because of the certificate issue. (Also see:http://forum.pfsense.org/index.php/topic,49108.0.html)
But since Firefox now defaults to a httpS google page I was wondering if someone did know a solution to this because now all users with a default firefox homepage won't be redirected to the captive portal. (unless they browse to a different url)
I guess there isn't a perfect solution, but who knows if some of the experts find themselves suddenly shouting "Eureka"
-
Curious if you found a work around on this. I too am having problems of poeple who have their homepage set to https (google or shortcuts) and never brings them to portal page.
-
HTTPS is never redirected, by design. It's not slow, it never happens.
-
After doing a little more reading I see the problem. This really stinks as I predict more and more website becoming secure with SSL.
-
I can't really see the problem why https (port 443) can't be redirected.
Isn't it possible to catch the first request on port 443 and redirect login page on port 80 as usual. I suppose the url isn't encoded with ssl at this stage (or is this the case?) and it should be still visible in HTTP_HOST. The certificate can be loaded and checked after the answer of the requested web server.
After successful login client's browser will execute the redirect to the original url with https://… what is passed by the filter. Therefore the ssl secured web page should be showed without any problem.
In any case pfsense should have to find a solution. More and more users have stored google's https site as starting page.
-
Isn't it possible to catch the first request on port 443 and redirect login page on port 80 as usual. I suppose the url isn't encoded with ssl at this stage (or is this the case?) and it should be still visible in HTTP_HOST. The certificate can be loaded and checked after the answer of the requested web server.
The SSL connection is established before any HTTP data is transmitted. SSL doesn't know anything about the hostname, URL, etc. just the IP.
-
After doing a little more reading I see the problem. This really stinks as I predict more and more website becoming secure with SSL.
I agree it is a problem, because pfsense silently drops all packets to ports other than HTTP (note: behavior has changed between 2.0.x and 2.1), instead of playing nice and sending a TCP reset so that the client's application can recover immediately.
In ticket http://redmine.pfsense.org/issues/2006 which I submitted a year ago, I suggested to also add:
Deny the rest
add 65532 set 1 reset tcp from any to any
add 65533 set 1 unreach port udp from any to anybut that suggestion didn't get added, since apparently it'd cause issues (see Ermal's last comment)
-
@bardelot
How can the SSL connection already be connected before the server has been connected first and before the certificate has been loaded. If I enter "https://xxxx.com" the address must be searched in DNS. And then? How is the server connected first before established SSL?Probably the external DNS request on port 53 could be catched as an alternative?
-
As I explained in my previous post in this thread, the underlying issue here is that pfSense CP silently drops all packets (other than those to port 80/http which are transparently redirected to the CP itself), causing the connection attempts via https to time-out. This can be frustrating to users.
In my own tests of the CP I added an ipfw rule to reject the traffic with TCP reset instead of dropping it, so that the user gets immediately notified and retries with plain http. These rules worked fine in my test setup, but Ermal pointed out that it might cause issues in certain configurations (see ticket).
-
How can the SSL connection already be connected before the server has been connected first and before the certificate has been loaded. If I enter "https://xxxx.com" the address must be searched in DNS. And then? How is the server connected first before established SSL?
1. DNS to translate hostname to IP
2. Establish IP/TCP connection between server and client IP
3. Establish SSL connection and exchange certificate
4. Client verifies that certificate and hostname match and certificate is valid
5. Client sends HTTP request (including hostname + path)Between server and client the hostname is usually only used during step 5, although there is an extension in TLS such that the client can send the hostname already in step 3. However the full path is always sent during step 5 only.
-
I agree it is a problem, because pfsense silently drops all packets to ports other than HTTP (note: behavior has changed between 2.0.x and 2.1), instead of playing nice and sending a TCP reset so that the client's application can recover immediately.
How is CP redirect handled in 2.1? I don't have a test machine set up at the moment to test HTTPS redirects. Hopefully they've improved the situation somewhat? No redirection is not an acceptable solution and it's one of our number 1 user complaints.
-
It's the same. You can't redirect HTTPS.
