Captive Portal not working on iOS devices only (DHCP 114)
-
I had to wait all this time until LE finally allowed me to issue a Production Certificate.
I want to update you that all the devices of all kinds are finally working without issues and getting a secure connection with a valid certificate. Having a dedicated domain on Cloudflare was a very wise idea.
I wouldn't be able to achieve that without your advice and assistance. You guys rock.
One last question. I have enabled Cron Entry. From your experience, will it really renew the certificate automatically after 90 days? Or am I still supposed to click the blue Issue/Renew button?
Apparently, the "Certificate renewal after" field doesn't matter at all because regardless of how many days I set, it's still 90 days as per LE.
-
@basharsaba
ACME will renew every 60 days and it works well with the default settings.
Congrats on your success.
-
@basharsaba said in Captive Portal not working on iOS devices only (DHCP 114):
From your experience, will it really renew the certificate automatically after 90 days? Or am I still supposed to click the blue Issue/Renew button?
Check the cron entry :
To see it, install; the pfSense Cron package first.
The need-to-renew-test runs every day, mine at : 03h16.
Now check the system log : to no surprise :Don't use '90' as a certificate renewal, but something between 30 and 60.
That leaves you with 60 to 30 days to resolve an issue IF something went wrong.
"90" will leave you with no spare time to resolve the issue.Btw : I'm using acme for years now, and it never failed. if it did, it was because the admin (me) was messing up again.
That said, free services or even when you pay for them : don't auto trust them, think about putting in place automated checks like this (very old munin based monitoring system). You can see that I check 2 domains there, and they are renewed after 30 days, and the other 60 days. Is like clock work. -
I've noticed something.
The scenario :
My PORTAL network :
192.168.2.1/24 - DHCP pool 192.168.6 -> 192.168.2.254
192.168.2.2, 3, 4, 5 = 4 APs with a static IP setup, DNS and gateway set to 192.168.2.1Normally, when I connect with my iPhone, I always get the same IPv4 : 192.168.1.6 because I created a DHCP MAC lease for my iPhone.
Now, when I add my IPv4 192.168.2.6 to the "allowed IP address" list :
I killed all Portal sessions, relaoded the Portal on pfSEnse, and then reconnected my iPhone.
I still got the login page ....It took me the better half of this morning that .... this is totally 'ok' as my iPhone, as soon as it receives a DHCP lease, it knows right away it has to go to
= "https://portal.xxx.net:8003/rfc8910.php?zone=cpzone1"
Before, when an IP was white listed like this, the portal became transparent for the device using that IP.
So, not really an issue, I was actually looking for a 'problem' that didn't exist.
Just : keep in mind that "rfc8910" method will not allow the bypass "allowed IP address" method.
edit : MAC list : probably same thing, didn't test yet.
-
Did you "forget" the iPhone "My Network"? I have noticed when testing RFC8910, DHCP 114 that it is/can be "sticky". As I switched between Kea and ISC, I had to remember to forget the old network on the iPhone, otherwise it appeared to be working under Kea when it actually had saved the login info from when it connected under ISC and received a 114 option, even though it got a different IP address. You can also switch "auto login" off and see if it has internet connectivity as that will prevent the captive portal page from loading, even if received via DHCP 114.
-
@EDaleH said in Captive Portal not working on iOS devices only (DHCP 114):
Did you "forget" the iPhone "My Network"?
Yep, did that, as part of the 'clean slate' approach.
@EDaleH said in Captive Portal not working on iOS devices only (DHCP 114):
I have noticed when testing RFC8910, DHCP 114 that it is/can be "sticky"
I have that impression also. Probably some iPhone side coding doing 'its' thing.
@EDaleH said in Captive Portal not working on iOS devices only (DHCP 114):
As I switched between Kea and ISC
I saw your discussion with marcos on Github about the upcoming kea implementation.
Progress is looking fine.@EDaleH said in Captive Portal not working on iOS devices only (DHCP 114):
You can also switch "auto login"
I'll experiment with that one
-
For the "rfc8910.php" file :
if (is_array($cpcfg['allowedip'])) { foreach ($cpcfg['allowedip'] as $ipent) { if ($ipent['ip'] == $clientip) { if ($ipent['dir'] != 'to') { // Bail out, 'clientip' is part of the 'allowedip' list ob_flush(); return; } } } }
If there is an array with "allowedips"
For each IP in the array,
If the IP of the portal c;lient matches an IP in the list,
And if the direction in not 'to' (thus 'both' or 'from'),
Then flush and return.This will take of he devices that are on the "allowed IP" list, they won't get login page anymore.
Take note : this works for 'English' portals. Afaik, the text 'from' 'to' and 'both' might be different for another languages.
-
@Gertjan said in Captive Portal not working on iOS devices only (DHCP 114):
This will take of he devices that are on the "allowed IP" list, they won't get login page anymore.
I confirmed that the same symptoms are present for "allowed IP" in Kea as I assume you were using ISC. I also confirmed that the fix works in Kea.
It is important to note that in order to have DHCP allocate a Static IP to a Mac address, that address must be outside the dynamic allocation pool for that portal's DHCP server.
It is also important to note that many devices change the MAC address every time you connect so you must turn off the "Private Wi-Fi Address" option on the iPhone for example. When you forget and add it again, it will reset to a dynamic Wi-Fi Address so the MAC will change and your static mapping will no longer be used.
The fix to RFC8910.php suggested simply prevents the device from intercepting the "capture" from the captive portal and it goes directly to the captive portal where it is allowed through, exactly as desired. There are negative consequences to this, first amongst them for me is that the "Open Captive Portal Page" option is not available on the iPhone for example. We use this to inform the client as to time, data quota, number of simultaneous users, time to automatic reset of account and potentially other important information (like logout) about their status. This is possible because DHCP 114 is sending the login URL to the captive portal every time you either log onto the Wi-Fi or click that option under the circled i on the iPhone for example. Captive portal will load the logout page if the device is already logged into the Captive Portal. Thus, we use the logout URL to provide this info. Once you bypass DHCP 114 through RFC8910.php this information will no longer be available. Loading the login URL manually will simply load the login page because, of course, a passed through IP is not logged in.
For this reason, thermostats, other IOT devices may use/need this feature but it is defeating the purpose of RFC8910 and must be applied for that reason, not to bypass the captive portal login screen. Once you are logged into the Captive Portal, you stay logged in until conditions are met to log you out automatically, time, data, etc. That is a preferred method of solving the problem of simply avoiding the login screen itself. Even for thermostats and other devices, they typically ignore RFC8910, DHCP 114 anyway and simply work by passing through their MAC address or an allowed IP in Captive Portal thus we never even noticed this issue to date. You preserve the login over a reboot by checking: Preserve users database ->Preserve connected users across reboot. If enabled, connected users won't be disconnected during a pfSense reboot.
-
Your last to phrases :
The fix to RFC8910.php suggested ...
and
For this reason, thermostats, ....
That's what I had in mind : 'thermostats', APs, smart switches and whatever other devices hosted on the portal network, these devices are typically white listed by using "Allowed IP" (and/or MAC probably) are mostly automates that don't know sh#t about portal login and/or don't use DHCP 114 (RFC8910) anyway - as you said already.
These devices won't consult the the portal's "venue-info-url" neither.The same type of filtering against the two "Allowed IP" and "MAC" lists isn't needed in the original portal's index.php
That said, devices have their MAC listed as "blocked" do inform the connected user with a message that his MAC is blocked (inviting him to change his MAC address ^^).Updated : I've also added MAC listed handling :
if (is_array($cpcfg['allowedip'])) { foreach ($cpcfg['allowedip'] as $ipent) { if ($ipent['ip'] == $clientip) { if ($ipent['dir'] != 'to') { // 'clientip' is part of the 'allowedip' list ob_flush(); return; } } } } $clientmac = pfSense_ip_to_mac($clientip); if (!is_array($clientmac)) { if (!isset($cpcfg['nomacfilter']) || isset($cpcfg['passthrumacadd'])) { /* unable to find MAC address - shouldn't happen! - bail out */ captiveportal_logportalauth("unauthenticated", "noclientmac", $clientip, "ERROR"); echo "An error occurred. Please check the system logs for more information."; log_error("Zone: {$cpzone} - Captive portal could not determine client's MAC address. Disable MAC address filtering in captive portal if you do not need this functionality."); ob_flush(); return; } } else if (is_array($cpcfg['passthrumac'])) { foreach ($cpcfg['passthrumac'] as $macent) { if ($macent['mac'] == $clientmac['macaddr']) { if ($macent['action'] == 'pass') { // 'clientmac' is part of the 'allowed MAC' list ob_flush(); return; } } } }
I took the initial MAC testing directly from the portal's 'index.php' file : if no MAC was found, but MAC usage isn't' disabled, then messages are logged/shown.
-
@Gertjan
Good Work, I tested the fix(es) under Kea/Plus 24.08 Dev (0925) and they work as advertised. I suggest you publish the full updated RFC8910.php here so others can quickly get the current result of this project to date.