Windows 10 (?) users cant login

21hertz

Today users started reporting to our Helpdesk that they cant login to our captive portal.

Users enter the correct username and password without getting redirected to the page the entered. And they don't actually get access, still trapped inside the captiveportal. This seems to happen only to SOME users, not everyone.
Mostly it's Windows 10 clients seem to have the problem. Using Edge or Firefox. Sometime it works, sometimes it doesn't.

Users keep hammering the Log In button and nothing happens. If you enter the wrong credentials you get re-directed to the loginfailed.html - as one should.

Captive Portal Auth Logs shows that users are being successfully authorized, these users are also visible in "Users Logged In".
Jun 14 18:38:34 logportalauth 488 Zone: cpzone - CONCURRENT LOGIN - REUSING OLD SESSION: XXX-XXXX, 00:24:xx:xx:xx:xx, 192.XXX.XXX.XXX
Jun 14 18:38:34 logportalauth 488 Zone: cpzone - USER LOGIN: XXX-XXXX, 00:24:xx:xx:xx:xx, 192.XXX.XXX.XXX
I did some minor changes to the Captive portal HTML pages today (adding some text), so my first thought was I did something wrong by mistake. So I re-uploaded the old HTML files (portal.html and loginfailed.html), which didn't solve this issue.

Any idea what could be causing this? Since the logs doesn't show anything....

Running pfsense 2.4.3-RELEASE-p1. I have tried to reboot the pfSense box, didn't help.

21hertz

@21hertz I might have found the problem but I have to wait until the users get back tomorrow.

First of all I think the old bug that pfSense had previously, where Allowed Hostnames stopped working, is back.
I just removed and re-added the whole bunch of "captive portal"-checks (detectportal.firefox.com, captive.apple.com, www.msftconnecttest.com etc). And now it seems to work! Users can now login again, atleast the two Windows 10 clients that I have).

Seems like one of the problems is that pfSense's Captive Portal won't work in atleast Windows 10 if you don't add the captive portal checks domain names under "Allowed Hostnames". On top of that pfSense sometimes seems to not use all of the Allowed Hostnames you added. Or maybe some custom configuration on our pfSense machines are different to other users...

jimp

You must have something else broken or incorrect. You want the client OS/browser portal checks to fail, otherwise the client won't sense the presence of a portal and present the login screen automatically or in cases like HTTPS. Do not add those into allowed hosts or you will confuse clients.

21hertz

Thanks for your answer. You are right about that, in most cases you should allow the portal checks to fail.
But there are scenarios and circumstances where those "pop up browsers" will not work, because the client OS is pushing a light weight version of a browser, which does not allow downloading of files.

For example:

You might have links to PDF's that you want the user to read/print or use before login in.
In our case we have a link to a printable Terms & Conditions PDF file (a university policy decision which I am trying to repeal...). It is impossible to download that file with Windows 10/MacOSX/iPhone or Android when using the pop-up/light weight version of each OS browser.
In cases were you are using captive portal as onboarding for another SSID/network, like a enterprise EAP-TLS/EAP-TTLS etc where you want the user to download a certificate, configuration, executable or .mobileconfig-file. To download certificates or configuration-files the user must use a "real" browser and not the one that pop ups.

This might give you an idea why some pfsense-users can't allow the captive portal checks to fail.

Anyways, I'm still struggeling to find the cause of this problem. It feels and looks like a browser issue. It's hard to find since according to pfSense logs everything works.

One idea though, our CP-page is based on something someone made in 2010 (!), I guess for pfSense v1.2.3. The HTML/CSS files have simply been migrated each update since then, with minor text changes.
Maybe I should reset the page to default and let someone re-write the whole page (it looks like its using HTML/CSS + some Javascript).

Gertjan

@21hertz said in Windows 10 (?) users cant login:

You might have links to PDF's that you want the user to read/print or use before login in.
In our case we have a link to a printable Terms & Conditions PDF file (a university policy decision which I am trying to repeal...). It is impossible to download that file with Windows 10/MacOSX/iPhone or Android when using the pop-up/light weight version of each OS browser.

Just tried that on an iPhone / iMAC : you can rule these out (latest OS everywhere) - it kicks in this light-weight browser when it detects a captive portal.
From a link on my captive portal page, I could 'read' a PDF' and visit the company's web site (some where on a server on the net).

"Windows 10" : don't have one, I'll migrate my PC-park to "10" the day it's better as "seven".

In cases were you are using captive portal as onboarding for another SSID/network, like a enterprise EAP-TLS/EAP-TTLS etc where you want the user to download a certificate, configuration, executable or .mobileconfig-file. To download certificates or configuration-files the user must use a "real" browser and not the one that pop ups.

This kind of captive portal is very intrusive, and can't be used for common (for me : hotel clients) users.

One idea though, our CP-page is based on something someone made in 2010 (!), I guess for pfSense v1.2.3. The HTML/CSS files have simply been migrated each update since then, with minor text changes.
Maybe I should reset the page to default and let someone re-write the whole page (it looks like its using HTML/CSS + some Javascript).

Very easy to test : switch to the build in page. It ought to be compatible ^^

21hertz

Just tried that on an iPhone / iMAC : you can rule these out (latest OS everywhere) -

You are right, thanks for the heads up. I just confirmed with our Apple team that downloading of PDF's seems to work with latest versions of iOS / MacOSX. Also tested with Firefox/IE/Edge in Windows 10. Hooray. :)
After lunch I will check if downloading of executables or .mobileconfig also works in Apple-products. This was not the case a couple of years ago for sure. :)

This kind of captive portal is very intrusive, and can’t be used for common (for me : hotel clients) users.

Sure, if security isn't part of your policy. We have to guarantee a secure WIFI network to all students and employees even though they have BOYD devices. A normal day we have over 5k+ "BYOD" users using EAP-TTLS (eduroam) at our Campus. We have tried different methods of showing the users how to connect, and actually, onboarding via an open WIFI portal is a great way to get the users connected to a secure network! It can be done for sure.

switch to the build in page.
I let our HTML guru look the captive portal and it's source and he said everything was fine.

Weird thing is that now, today, I have removed the "Allowed Hosts" again for portal checks. And it still works... So something else was the problem to start with. I can't confirm what the problem actually was. It bugs me since I have worked on this for so many hours...

What I can confirm though, is that pfSense still has some sort of bug with "Allowed Hosts". Sometimes it takes a couple of minutes and sometimes it doesn't work at all, when you have entered a value / domain.
It seems like the list of domains that you enter in "Allowed Hosts" isn't applied to the rules as it should. Feels intermittent. This was a actual reported bug in an earlier release (don't remember which version).

Gertjan

@21hertz said in Windows 10 (?) users cant login:

What I can confirm though, is that pfSense still has some sort of bug with “Allowed Hosts”. Sometimes it takes a couple of minutes and sometimes it doesn’t work at all, when you have entered a value / domain.
It seems like the list of domains that you enter in “Allowed Hosts” isn’t applied to the rules as it should. Feels intermittent. This was a actual reported bug in an earlier release (don’t remember which version).

The "allowed hosts" is easy to "debug".
Add your host, ad then look at the generated ipfw rules (this page is very useful : https://www.netgate.com/docs/pfsense/captiveportal/captive-portal-troubleshooting.html - it has told many, many portal admins that they shouldn't break their DNS before operating a captive portal - or, using more common words : Captive portal will not work better as our DNS).

Btw : In case you didn't know : if you use the Allowed host to let portal visitors visit public Internet sites before authentication, be careful : even the most dull WordPress index page includes tells your browser to search for additional info at Google, FB, and else where. These places - hosts, are of course not allowed, so the principle site seams broken, or even the Allowed host entry doesn't seem to work.

** Don't add a host without checking first with nslookup, dig or your favorite DNS tool.