Captive Portal not working on iOS devices only (DHCP 114)

EDaleH

If there is a tendency to use the Captive Portal File Manager, then the instructions could read:

The method you use to upload the rfc8910.php file can affect the resulting file name. It is wise to check the resulting file name before configuring DHCP. To do that, go into Diagnostics, Edit File, Browse, and click on usr, local, captiveportal and verify the name of the file. if it is renamed to captiveportal-rfc8910.php then that is the filename you use for setting up the DHCP 114 option text/string in setting up the DHCP server (ICE for now as Kea does not yet support DHCP options).

Independent of name, it is essential that the rfc8910.php file reside in the same directory as the index.php file used by captive portal for the login page. This directory is /usr/local/captiveportal. The exact name of the file is not important except for the .php extension. What is important is that when your DHCP 114 URL is called, the name you use for "rfc8910.php" or "captiveportal-rfc8910.php" or other name as applicable; actually exists!

The addition of "captiveportal-" in front of the file you are uploading is a feature of uploading through the Captive Portal file manager. If you subsequently want to remove the "captiveportal-" from the front of the file, you can use the shell built into the pfSense Console to do so. This would be done by going to Diagnostics, Command Prompt and typing "mv /usr/local/captiveportal/captiveportal-rfc8910.php /usr/local/captiveportal/rfc8910.php" followed by pressing execute. Then use the instructions above to browse to the /usr/local/captiveportal directory to verify the file was renamed correctly.

Bisho

@EDaleH Thank you for the valuable advice about getting first the pfSense Captive Portal to log into a secure session.
After numerous attempts and playing around with the SSL Certificate, DNS Resolver, and Host Overrides, I was able to get this part done.

Right now, the moment I connect my Laptop or iPhone to the guest network, the Captive Portal page pops up using my default browser and I can see the URL is https://portal.af*****.com:8003/index.php?zone=$cpzone".

I then applied the same configuration on my friend's pfSense who resides in a country where http://captive.apple.com/hotspot-detect.html is unfortunately blocked and there was some progress.

Before, we had to manually and exclusively go to an HTTP site in order for the Captive Portal page to open, but now, we can go to any HTTPS site and we will get a message to visit this website (only for the first time) and then we will be redirected to the Captive Portal page.

Now, here is the tricky part of my friend's situation for which I created this new topic.

Since http://captive.apple.com/hotspot-detect.html is blocked, we had to use the DHCP 114 along with the modified PHP file presented by @Gertjan. I did that and set the String to "https://portal.af*****.com:8003/captiveportal-rfc8910.php?zone=$cpzone" and used the PHP code I mentioned in my previous reply https://forum.netgate.com/topic/188402/captive-portal-not-working-on-ios-devices-only-dhcp-114/13.

The issue is that the Captive Portal page on iOS doesn't pop up, but it does pop up on Laptop.
The Hotel guests must open Safari or Chrome on their iPhones and type an HTTPS site to get to the Captive Portal page. Unfortunately, the great majority will not guess they have to do that. They will just think there is an internet connection problem, especially if the WiFi network states that.

As the DHCP 114 and the modified PHP file are the way to bypass the http://captive.apple.com/hotspot-detect.html challenge/detection. What could be stopping the Captive Portal page from automatically popping up?
I'm trying from the U.S. where nothing is blocked and the Captive Portal page is automatically popping up on my iPhone even after using the DHCP 114 and the modified PHP file. This makes me think that there could be something incorrect with either the DHCP 114 or the PHP code since they are not doing their job in bypassing the Apple Captive Portal detection.

@Gertjan Could you please take a look at the code I'm using? Is it correct? Am I missing any line?
I know I can name the file as rfc8910.php by using WinSCP, but it's ok, let it be captiveportal-rfc8910.php and I can change the code and the string accordingly.

Thanks,

Gertjan

@basharsaba said in Captive Portal not working on iOS devices only (DHCP 114):

@Gertjan Could you please take a look at the code I'm using? Is it correct? Am I missing any line?

Where did you get the code from ?
Something is wrong.
Look here :

The variable $cpzone is set = see the green statement.
But this variable $cpzone is already 'used' (so it will contain nothing or an empty string) the line above : that is a bug.

So your $rfc8910_url will contain only this :

'https://'portal.pfsense.tld:800x/index.php?zone='

The "cpzone" html variable isn't set ...... things will go wrong.

This is what I'm using right now, for the last two month :

<?php

require_once("auth.inc");
require_once("util.inc");
require_once("functions.inc");
require_once("captiveportal.inc");

header("Expires: 0");
header("Cache-Control: no-cache, no-store, must-revalidate");
header("Pragma: no-cache");
header("Connection: close");

global $g, $config, $cpzone, $cpzoneid, $cpzoneprefix;

$cpzone = strtolower($_REQUEST['zone']);
$cpcfg = config_get_path("captiveportal/{$cpzone}");

if (empty($cpcfg)) {
	log_error("rfc8910 - Submission to captiveportal with unknown parameter zone: " . htmlspecialchars($cpzone));
	portal_reply_page($redirurl, "error", gettext("Internal error"));
	ob_flush();
	return;
}

$cpzoneid = $cpcfg['zoneid'];
$clientip = $_SERVER['REMOTE_ADDR'];

if (!$clientip) {
	/* not good - bail out */
	log_error("Zone: {$cpzone} - rfc8910 - Captive portal could not determine client's IP address.");
	$errormsg = gettext("An error occurred. Please check the system logs for more information.");
	portal_reply_page($redirurl, "error", $errormsg);
	ob_flush();
	return;
}

$cpsession = captiveportal_isip_logged($clientip);
$sessionid = $cpsession['sessionid'];
$rfc8910_url = 'https://' . $_SERVER['HTTP_HOST'] . '/index.php?zone=' . $cpzone;

ob_flush();
if (empty($cpsession)) {
//	captiveportal_logportalauth("rfc8910", "EMPTY SESSION : {$_SERVER['HTTP_HOST']}", $clientip, $cpzone);
	$json_post  = array (
		"captive" => true,
		"user-portal-url" => $rfc8910_url,
		"venue-info-url" => $rfc8910_url,
);

echo json_encode($json_post, JSON_PRETTY_PRINT);
} else {
//	captiveportal_logportalauth("rfc8910", "EXISTING SESSION : {$_SERVER['HTTP_HOST']}", $clientip, $cpzone);
	$json_post  = array (
		"captive" => false,
		"user-portal-url" => $rfc8910_url,
		"venue-info-url" => $rfc8910_url,
);
echo json_encode($json_post, JSON_PRETTY_PRINT);
}
ob_flush();

return;
?>

To check if a portal client device is using the DHCP method (is using the URL that DHCP option 114 has been given to the device when it obtained a lease), to this :
Look at the logs !!
Here : Status > System Logs > System > GUI Service

Example :

Question : how would a device a device know that it should do a get "GET /rfc89410.php ..... " ?
Answer : because it uses the "DHCP option 114" it got from the captive portal DHCP server !
AFAIK, Apple device do this, but they are not the only ones using this RFC method.

If you are not finding any "GET /rfc89410.php ..... " in the logs, your device are not using the "DHCP Option 114" method.

Btw : the beauty of the ""DHCP option 114" : no "http" 'polling' is needed to have the request redirected to a portal login page.
No more initial DNS request, the one for captiveportal.apple.com to get the address of this http challenge page, is needed.
The device can go straight to the login page, and the URL used, example : portal.pfsense.tld is a host name that has been set up as a static host override into the resolver.
Because the DHCP lease informed (has to inform !) that pfSense is the local networks DNS, the portal visiting device will use the pfSense DNS to get portal.pfsense.tld resolved.
And that always works out.
The "DHCP option 114" is faster as the actual pfSense captive portal login process, although te original "/index.php ...." of the portal is still used ;) because less DNS requests, no web request redirections needed.
Bonus : a connection status page is avaible, although somewhat hidden, I can see it in the 'properties' under the wifi of my SSID on my iPhone.
Btw : I've said this earlier : please, please, tell me why something some one shoe how had decided that apple.com has to be blocked.
Don't let this feeling get to me that your friend is really living in a really sick place. I can't find a reason why people are not allowed ( ? ) to visit apple.com. Is this apple doing this ? The ISP ?

EDaleH

@basharsaba said in Captive Portal not working on iOS devices only (DHCP 114):

Before, we had to manually and exclusively go to an HTTP site in order for the Captive Portal page to open, but now, we can go to any HTTPS site and we will get a message to visit this website (only for the first time) and then we will be redirected to the Captive Portal page.

This behaviour is characteristic of the pfSense Captive Portal. The capture of traffic on HTTP port 80 or , sometimes HTTPS 443 is done by the Captive Portal. It has nothing to do with rfc8910 (DHCP option 114). Your need to enter a url to get the login page always means you are being captured by pfSense Captive Portal and your DHCP 114 through captiveportal-rfc8910.php is not parsing correctly. We know this quite simply because iOS does not use your phone's browser for the login screen, it uses a temporary, purpose specific browser just for the login screen. You can't enter or change the url, it either launches because rfc8910.php provided a valid, secure URL to iOS with "true" set, which tells it to go that URL or nothing happens. When you subsequently launch Safari, for example, and enter a url, you are now sending that url to pfSense Captive Portal and iOS is only acknowledging a connection to a WiFi station ID, and pfSense Captive Portal has you "captive", i.e. "No Internet Access". In Windows, you can send an http request to the Captive Portal and it will recognize an attempt to go to the internet and then redirect you to the login page. Unfortunately by definition, an HTTPS request is "encrypted" and pfSense Captive Portal may not recognize it and thus not launch the login screen. In iOS, any http request is blocked until internet access is verified through the captive.apple.com "Success" reply. This is why you do not get the pfSense Captive Portal login screen unless you bypass it through using DHCP 114 by having iOS request the Captive Portal login screen directly by accessing that URL BEFORE it checks captive.apple.com.

Observations:

There will never be a $ after the zone= in the url. The correct value is found under System, Captive Portal column labelled "Zone". In the rfc8910.php code it is looked up automatically.
Apple introduced this feature around 2020 and it has evolved. It is only fully supported from iOS 17 on. It does work under earlier versions but does not always behave the same way. Follow @Gertjan's advice and check:

@Gertjan said in Captive Portal not working on iOS devices only (DHCP 114):

Here : Status > System Logs > System > GUI Service

to ensure the zone is correct.

If captive.apple.com is not available but the login to pfSense Captive Portal is successful, it is likely that the "No Internet Access" state will remain on the iOS Settings, Wifi screen. If you then open Safari or other browser and go to a SECURE web site, first iOS will now let it through because it is secure, then Captive Portal will let it through because you are logged in and granted internet access. Once iOS detects valid internet traffic it will belatedly clear the No Internet Service warning and continue working. From that point on for new connections on that phone to that station ID, DHCP option114 through rfc8910.php will send a "false" in the json data and iOS will simply pass you through as long as "Auto Login is set to ON" in the profile for that wifi station id. Now iOS knows you have internet access because of the response from captive.apple.com. In the absence of that reply, it may not do so. If this persists, you might want to modify rfc8910.php to always send a "true" which will mean the user gets the captive portal login page (or logout if already logged in), thus enabling the user to close the temporary browser and "fool" iOS. However, the No Internet Access message will still have to be cleared. You may have an app running on the phone that accesses the internet and does that for you. That situation is "undefined" if you like.
The "This Connection is not Private" warning suggests a certificate issue so you need to make sure the Captive Portal and pfSense firewall are correctly configured to receive the certificate data from the internet certificate server. Many devices cache this data and it can become out of date if the device is not on the internet for a long time or the server is blocked. The certificate server on the internet has been updated but the device is not checking it. Debugging this can be difficult as well. If the error clears after you get through the Captive Portal then it is the certificate Data cached on the phone that is out of date.

Bisho

@Gertjan and @EDaleH... I'd like to extend my sincere thankfulness for your time, efforts, and determination to help me resolve this issue.

Finally, it's flawlessly working and my friend was able to get to the secured Captive Portal page and bypass the blocked http://captive.apple.com/hotspot-detect.html. It was a dream that had come true No more iOS guest complaints

Without your advice, deep troubleshooting, and attention to detail, we wouldn't succeed in this small project.

Regards.

Bisho

@Gertjan and @EDaleH

I'm back again with another issue. You're my last resort.

So yesterday we went live with pfSense and the Captive Portal on the entire network. All iOS users were so happy, they all were getting the Captive Portal page in seconds and getting connected to the internet.

On the contrary, Android users who used to be happy before implementing pfSense became upset.

There were 2 types of Android users.:

Type 1, is those with Android 11.x and above which supports DHCP 114. They weren't getting the Captive Portal immediately, but instead, they were getting the Chrome page that says "Your connection is not private" and "Turn on enhanced protection" and then "Proceed to https://portal.afxxxxx.com which would eventually take them to the Captive Portal page.

Type 2, is those with the older Android versions that don't support DHCP 114, which constitute the vast majority.
They were not getting to the Captive Portal page at all even if the above-mentioned alerts of Type 1 appeared. Some of them didn't get any alerts, but still no Captive Portal page.

The Android Developer site states: If the API is not available, or if no portal is advertised, the system will continue to detect portals and verify internet connectivity using HTTP/HTTPS probes, as before.
https://developer.android.com/about/versions/11/features/captive-portal

But apparently, these old Android phones are still failing to detect portals using the old method, or somehow, the rfc8910.php is forcing them to use the unsupported DHCP 114.

My questions:

is there a way to exclude non-iOS users (mainly any Android version) from using DHCP 114? because Android never had any issues from the start. The only reason I had to start this new topic was because iOS users were having issues.
If #1 cannot be done, is there anything that we can do for Type 1 to get the Captive Portal page immediately without seeing the alerts? Not everybody knows what to do and how to proceed. These alerts were very confusing to them.
Regarding Type 2, Can we for example create a separate DHCP Pool or Captive Portal for these devices? but will we be able to distinguish the old Androids from the new ones?

Thanks.

Gertjan

@basharsaba

The good news is the bad news : you didn't understand RFC8910.

If the client isn't asking for DHCP 114, it doesn't get one. edit : have to check this. But I'm sure that if a DHCPO client gets an option that it doesn't know, it will ignore it.

So it will know nothing about the file/url "https://portal.bhf.tld:8003/rfc8910.php?zone=cpzone1" and everything is as before.
If it does know about RFC8910, then it will ask for the usual minimal DHCP options, like 'IP', network, DNS, gateway and some more stuff : these are part of the bare minimal "how to get a DHCP lease" and it will also receive a DHCP 114, and know what to do with it = use the URL directly.
A device could even receive option 114, and decided to neglect it : portal detection will work out the good old known way.

So, the beauty about RFC8910 : it enhances possibilities, without loosing backwards compatibility.
After all : adding loads of options to your DHCP server doesn't harm anything, as the client doesn't deal with if it can't understand them.
The file "rfc8910.php" on the portal web server will not get loaded, the client device doesn't even know it exist.

I know it works, as I can't control what devices people bring to my hotel. But they connect to my portal.
And they won't complain to me, as I always make a bet with them : "If I make your device connect, do you pay me a beer ?" I was drunk the better part of my live.
Btw : the sub 50 $ phones, I don't touch them anymore.
And the worst is : I'll promise to refund the free ($ or €) service .... so I never lost money here.
Most come back with stuff that 'just works'.

About your type 2 devices : and now I state right upfront : I don't know them, I have no android phones or devices that I'm aware of.

@basharsaba said in Captive Portal not working on iOS devices only (DHCP 114):

My questions:

is there a way to exclude non-iOS users (mainly any Android version) from using DHCP 114?

Not sure.
Packet capture a DHCP negotiation. Is option 114 systematically given by the server ? Or only if it is asked for ?
And even if the option is there, and the device doesn't know what it is, it should just neglect it, and when doing so, the old behavior is back.
With the devices these days randomize their MAC addresses, you can filter what so ever to know if a device is an iOS, or something else. This is what I think - I might be wrong, but I never saw a list with "these are the possible iOS random MACs" and "these are the random android MACs" etc. As such a list makes the random list not random anymore.
So, no go.

If've seen devices that block and or panic on : Wifi not encrypted - even Apple gives this messages : and this scares the user. Although the Apple user manual says : this is an informal message, not necessarily a failure. But Portal never really be encrypted. If they were, you have to show everywhere, on every wall, the WPA2 password first. That great for "security". Most traffic is TLS anyway these days.
Other devices don't like 'unknown' RFC1918 .... these users won't be able to use a captive portal. You can't save them.
And so on ....

The message "connection not secure" actually means : (for me) : as soon as you are connected to the portal, fire up your VPN.
That's it. And their you have it : for ones I advertise that VPN suppliers can have some benefits.

@basharsaba said in Captive Portal not working on iOS devices only (DHCP 114):

If #1 cannot be done, is there anything that we can do for Type 1 to get the Captive Portal page immediately without seeing the alerts?

What alerts ? The "you didn't encrypt the wifi" .... well, encrypt it .... This will ditch the message, as long as everybody has the WPA2 password first. The choice is up to you. You - and me - can't have it both ways.

@basharsaba said in Captive Portal not working on iOS devices only (DHCP 114):

Regarding Type 2, Can we for example create a separate DHCP Pool or Captive Portal for these devices?

As explained above : in short : no.

EDaleH

@basharsaba

The "Your Connection is not Private" message in Chrome is telling you that your certificate used for Captive Portal does not have current data available or has no access to a certificate server. There are a number of tests you can do, just google the error and you will get a list.

The fact the error is in Chrome indicates you are hitting the captive portal and simply getting an SSL error message so nothing is wrong with the captive portal as long as the URL matches.

For older devices, use an http URL to test them, neverssl.com is a popular one. It frequently triggers the captive portal login page. If you get the certificate error above, it is a separate issue and as long as the URL matches the captive portal one, not a Captive Portal problem, as it proves you are being "captured".

You may want to ensure there are host overrides in your DNS Resolver for all SSL certificates used on Captive Portals. It doesn't hurt to add the certificate server DNS for your SSL certificate to the DNS list under System, General Setup either.

Gertjan

@EDaleH said in Captive Portal not working on iOS devices only (DHCP 114):

You may want to ensure there are host overrides in your DNS Resolver

Good catch.
If this is the URL used for the captive portal : "portal.bhf.tld" then this :

is important.

The host name "portal.bhf.tld" is resolved to the portal IP : (example) 192.168.10.1 and the portal web server should return a certificate that has a SAN that contains "portal.bhf.tld", and now the TLS (https) is ok, IF the certificate signer (CA) is recognized as 'valid' by the client's browser.

Bisho

@Gertjan Thank you for explaining RFC8910. Indeed, I didn't understand it which made me curious to read its history from this document RFC8910.
What you said about DHCP 114 requests by supported/unsupported devices makes total sense. If it's known to the device, it will use it and if not, it will neglect it.

@EDaleH Thank you for your input. The essential DNS Resolver part has already been done. I mentioned that in my previous reply Here

I tried to narrow down the issue, by focusing for now on the devices with Android 11 and above that understand and use DHCP 114 which keep getting the alerts "Your connection is not private" and "Turn on enhanced protection"...etc

iOS doesn't show these alerts because the default browser is Safari. Android's default browser is Chrome which is a bit annoying when it comes to securtiy and certificate validation.

Since I'm also getting the same alerts when I connect to the Captive Portal on my laptop using Chrome, I said if I could solve it on my laptop and make my connection to the Captive Portal page secure, then the new Android devices would have no issue and then I can focus on the old ones that don't understand DHCP 114.

I have done everything you could imagine on pfSense to make this connection secure and the only way that worked was by importing the ca_bundle.crt file to my laptop. By doing that, no more security alerts.

Obviously, this is not a feasible or practical solution when it comes to Laptops and Android phones in a hotel environment with hundreds of guests. I didn't even know how to import the CRT file to my Android phone.

My question. Have you heard of or seen any method to make the connection to a Captive Portal page secure through pfSense without importing any CRT file to the connecting device?

@Gertjan said in Captive Portal not working on iOS devices only (DHCP 114):

I know it works, as I can't control what devices people bring to my hotel. But they connect to my portal

This gives me some hope since I'm sure some of your guests are using Android phones but since you're not hearing any complaints, that means they are either not getting the alerts or they are getting the alerts but they know how to proceed.
It would be amazing if you could get your hand on an Android phone from one of your colleagues for example (or maybe from a nice guest) and see what they are seeing when they connect to your Captive Portal page. I'm just so curious.

@EDaleH said in Captive Portal not working on iOS devices only (DHCP 114):

The "Your Connection is not Private" message in Chrome is telling you that your certificate used for Captive Portal does not have current data available or has no access to a certificate server. There are a number of tests you can do, just google the error and you will get a list.

I couldn't find any test. Any suggestion?

@EDaleH said in Captive Portal not working on iOS devices only (DHCP 114):

You may want to ensure there are host overrides in your DNS Resolver for all SSL certificates used on Captive Portals. It doesn't hurt to add the certificate server DNS for your SSL certificate to the DNS list under System, General Setup either.

I want to mention that my current TLS certificate is issued by Let's Encrypt. I also tried using one from ZeroSSL and it was the same issue.

What exactly are you asking me to do here? How do I get the DNS server of my certificate? Shall I get the IP of my portal domain https://portal.afxxxxx.com and add it somewhere? Or add the DNS server of the certificate issuer?

EDaleH

@basharsaba
One thing that catches my eye is your subdomain which is complex. portal.af.domain.com is more than one subdomain level. subdomain.domain.com is what you want here. I use Cloudflare simply because they provide first level subdomains free. If your registrar is giving you second level subdomains then you are likely fine as long as portal.af.domain.com is in the registrar's DNS server (pointing at captive portal vlan?'s IP) so the world can resolve it to that IP. Then you need to add that full domain path to the let's encrypt (ACME?) so it picks it up. ACME will not grab that level2.level1.domain.com until the next time you refresh the certificate. If you have done all that, then you are ready to test.

If it is working in iOS, it is not being resolved in Safari, it is the custom browser that is dedicated to logging onto captive portals that is being used for access. However, it does have to resolve the URL under SSL/TLS, i.e. the certificate must be valid. Are you using the same certificate URL for both iOS and android devices? This is important because if it is working on iOS with the identical path in the RFC8910.php file as captive portal uses (portal.af.domain.com:8003/index.php?xxx in your example) then you know the certificate and DNS are working correctly. They can not be different. Putting the correct URL into the DHCP114 option string for your iOS clients and having it work is proof you have the URL to the captive portal login page correct.

BTW, importing the certificate to the laptop simply proves it is not resolving either through DNS or the server that is the source of your ca_bundle.cert file. It sounds like you have a certificate file at the SSL Server that is not propagating, check that ACME is "picking it up" when it refreshes the certificate if that is how you are implementing it. ACME will pick up only a subset of subdomains if you don't include all of them in the list.
Now that you have the cert file on your laptop, you can no longer debug the problem on your laptop until you remove it.

So assuming no ca_bundle.cert file has been imported, take the exact URL you use in the RFC8910.php file and enter it into the URL of your chrome browser on your laptop. This is assuming it does not launch automatically when you connect to the AP that is serving that captive portal. If you have a DHCP address from the correct DHCP server for the captive portal, then entering the captive portal URL will launch the login screen. If you are already logged in, it will launch the "logout" screen instead (index.php does that for you). We use the logout screen as a dashboard to report the status of the connection to the portal (typically time and bytes). If you haven't written a custom one, you will just get the logout screen. What you should not get is an SSL error or not found related error.

Normally, if the certificate were invalid, you would not be logging into iOS either, it too gives a security related error, but I believe it is something like "a secure connection is required".

As long as the error is SSL related, you do not have a captive portal problem. DNS, the company providing the certificate, and if used, ACME are where to concentrate on troubleshooting it. BTW, if you have the certificate info for the URL (subdomain.domain.com) in the DNS resolver but not in the DNS for the domain, then it will not resolve for the SSL verification, you need both for it to work.

Bisho

Thank you @EDaleH.

I believe you got confused about the URL because I was masking the domain name with asterisks. Anyway, it's not a secret.

So the domain URL is https://www.afamiahotelresort.com/ and the Captive Portal URL https://portal.afamiahotelresort.com/. So it's in the form of subdomain.domain.com or level1.domain.com which is correct, right?

The SSL/TLS certificates were issued for portal.afamiahotelresort.com. I mentioned that Here.

The RFC8910.php has this line:
$rfc8910_url = 'https://' . $_SERVER['HTTP_HOST'] . '/index.php?zone=' . $cpzone;

The DHCP 114 has this string:
"https://portal.afamiahotelresort.com:8003/rfc8910.php?zone=cpzone"

What is the Certificate URL? Isn't the above URL? If yes, then I'm using it for both iOS and Android devices. I don't even think there is an option to use different URLs for different devices.

I did remove the ca_bundle.crt file from my laptop, then I entered https://portal.afamiahotelresort.com:8003/rfc8910.php?zone=cpzone in Chrome and got the alerts with no secure connection (since I removed the cert file). I proceeded and got the login screen, I logged in and pasted the URL again and got the disconnect screen.

This is the General Setup and DNS Resolver options. I believe I'm missing the DNS Server IP and Hostname, right? What are they supposed to be? Whose IP or Hostname? Where do I get them from?

Screenshot 2024-08-03 121902.png

Screenshot 2024-08-03 122238.png

Bisho

@basharsaba said in Captive Portal not working on iOS devices only (DHCP 114):

This is the General Setup and DNS Resolver options. I believe I'm missing the DNS Server IP and Hostname, right? What are they supposed to be? Whose IP or Hostname? Where do I get them from?

I just tried to use 1.1.1.1 and 1.0.0.1 with Hostname one.one.one.one or 8.8.8.8 and 8.8.4.4 with Hostname dns.google but it didn't make any difference.
Do I need to get them from the certificate issuer (LE or ZeroSSL) or from the domain Registrar?

EDaleH

@basharsaba

Let's address these one at a time.

The first screen capture made it look like you had a period after the af which is now clear that you are using only a subdomain (1st level). That's good.

Your captive portal is on the LAN based on the IP assigned to it?. I have never built a portal on the LAN for security reasons so am unfamiliar with any consequences that may introduce.

You have named your captive portal "cpzone". That is unusual and confusing as apparently now $cpzone will resolve to cpzone in index.php. As stated before, go to Services, Captive Portal and make sure that the "Zone" column says cpzone for the zone name.

In order for your portal to work, I would set the DNS IP address to 192.168.1.1 given your internal captive portal requirements. If your device is using external DNS servers they will see:

Pinging portal.afamiahotelresort.com [10?.?6.??1.?0] with 32 bytes of data:
Reply from 10?.?6.??1.?0: bytes=32 time=65ms TTL=54
Reply from 10?.?6.??1.?0: bytes=32 time=63ms TTL=54
Reply from 10?.?6.??1.?0: bytes=32 time=63ms TTL=54
Reply from 10?.?6.??1.?0: bytes=32 time=65ms TTL=54

Ping statistics for 10?.?6.??1.?0:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 63ms, Maximum = 65ms, Average = 64ms

If they are using the internal DNS Resolver on 192.168.1.1 as DNS they will see 192.168.1.1 so there is a conflict right there. You can't control which DNS server resolves the address first. One reason the iOS may resolve it correctly is simply because iOS blocks internet access until after the captive portal authorizes access. That forces it to use the DNS resolver result on the default DNS of 192.168.1.1.

I suggest you dedicate subdomain "portal" to the captive portal and nothing else. Then edit your DNS provider records such that it points to 192.168.1.1. It is normal that afamiahotelresort.com would point to some other public IP, as would the www subdomain. Make sure you give it time to propagate the change throughout the internet, check the Time To Live value and wait that long at a minimum.

Your DNS question is not applicable as they all point to the wrong address for your captive portal. Thus they will never resolve correctly and I presume cause your certificate error message?

Bisho

Thank you @EDaleH for your prompt response.

My Captive Portal Zone's name is indeed cpzone. I kept it like that and modified the DHCP 114 String accordingly. I have tried different names and they all have led to the same issue.

I'm a bit in shock that the Captive Portal is supposed to be enabled on the WAN interface. To my understanding and from the many tutorials I have watched, clients get a DHCP lease from the LAN subnet and since the Captive Portal is enabled on the LAN interface the portal page will pop up, once they authenticate, they get internet through the WAN interface.

However, just for testing, I enabled it on WAN and the result was that no portal page popped up and I got internet access directly, which doesn't serve our purpose.

The portal.afamiahotelresort.com never existed before. We exclusively created it for the pfSense Captive Portal. a total dedication.

I set the DNS IP address to 192.168.1.1. Correct?

Now let's come to the tricky part. Correct me if I'm wrong. Are you asking me to set the DNS IP address to 192.168.1.1 in the domain's registrar which is NameSilo in my case? if yes, I doubt I can change the DNS record just for the subdomain URL. I will have to change it for the whole domain which might break everything. I will have to check but I thought to confirm with you first.

EDaleH

@basharsaba

No, never on the WAN. In my experience the captive portal is on OPT1, a third interface. A VLan is then defined if necessary for multiple captive portals. By placing the captive portal on OPT1, you can keep the LAN isolated through firewall rules for a local office or simply maintaining pfSense. You can set it up on the LAN, that is not your problem wrt the Certificate error.

I assume your response comes from not understanding why the subdomain portal.domain.com must point to the internal address of the Captive Portal. It seems you are confusing DNS with WAN. Yes, the DNS will point say a www subdomain to the public side of your WAN for a web site but the Captive Portal is on the inside of your firewall and it points to the non public address of the interface you assign it to. As you have it on LAN, 192.168.1.1, simply point portal.domain.com to that address. Do not change any of the other DNS entries as they have other purposes.

I think when you get the certificate error you may be resolving to the public address but to be sure, ping it from the laptop. For example. open a command prompt. Ping portal.afamiahotelresort.com. It should return 192.168.1.1. If it returns the public address then the captive portal is not there. That is an undefined state and it is no wonder the certificate is not valid.

Your pfSense host override should not change the address that the certificate is registered against as resolved by public DNS servers.

Bisho

Hi @EDaleH, I have some interesting updates.

So I went to the Registrar (NameSilo) and found that whoever developed the website www.afamiahotelresort.com, has set the NameServers (DNS Records) to be the Web Hosting company's ones. NameSilo clearly states that since we are not using their default DNS Records, then any changes we make will have no impact, so I left them untouched.

Screenshot 2024-08-04 074813.png

Screenshot 2024-08-04 082211.png

So I went to the cPanel which was the place where I created the subdomain portal.afamiahotelresort.com and got its SSL/TLS Certificate from LE.
There was no option to change its DNS Records, after talking to support, I was told that in order to do that, I needed to create a Dynamic DNS for this URL.
When I tried to do that, it gave me an error that the domain portal.afamiahotelresort.com already exists.

Since I didn't want to delete it from the domains, I went ahead and created a brand new URL called pfsense.afamiahotelresort.com and assigned it 192.168.1.1, and within minutes an SSL/TLS Certificate was automatically issued by LE. I checked its status and it was Validated.

Screenshot 2024-08-04 124012.png

Screenshot 2024-08-04 123927.png

I went ahead and did your suggested ping test. The weird part is that if my friend pings pfsense.afamiahotelresort.com from the hotel in his country, he gets a reply. If I ping it from home in the U.S., it shows 192.168.1.1 but I get timed out. We both used the DNS provided by the local ISP first, then set the DNS to 8.8.8.8 and 1.1.1.1 and It was the same result.
I will assume that pfsense.afamiahotelresort.com is resolving to 192.168.1.1 regardless of the ping reply. Shall I ?

Screenshot 2024-08-04 075029.png

I went ahead and changed all the configurations in pfSesne to pfsense.afamiahotelresort.com. Certificates, Domain, DNS Server Settings (IP and Hostname), Captive Portal HTTPS Options, DHCP 114, DNS Resolver Host Overrides...etc but unfortunately, the connection to the Captive Portal page was not secure.

Screenshot 2024-08-04 122427.png

I even enabled the option to Respond to incoming SSL/TLS queries from local clients, but it didn't have any impact.

I kept testing the Captive Portal page every 15 minutes, and then one time, I got a secure connection. No alerts or anything and the certificate was fully validated. I couldn't believe my eyes So I immediately grabbed my Android phone and tested but the connection was not secure.
I then reset Chrome settings and tried and I was back to square one. Connection is not secure until this moment.
I took a screenshot for the memory of the only time it worked.

It's driving me crazy.

Bisho

Another weird observation: My pfSense is virtualized. The VM Host that has 2 hardwired NICs (WAN to the ISP router & LAN to a WiFi AP) has no issue at all.
If I paste https://pfsense.afamiahotelresort.com:8003/index.php?zone=cpzone into Chrome or Edge, the connection is secure and the certificate is valid even after resetting both browsers several times. Note that their versions with my laptop are identical.

I'm getting the connection not secure when I connect my laptop or phone via WiFi.
To find out if it's an AP issue, I connected my laptop via cable to the pfSense LAN port (no more AP). I got a DHCP IP but I got the connection not secure. So the method of connection doesn't matter.
My laptop/phone and this VM Host use the same DNS and we both are on Windows 11 and no CRT file is installed.

Even the VM Host at my friend's hotel overseas is working without any issues as same as mine. I did several tests and the connection is secure and the certificate is valid !!!!

I really don't know what is special about these VM Hosts. They always accept the Certificate. Unlike clients (laptops/phones)

By the way, it's worth mentioning that even this working VM Host, does time out when pinging to pfsense.afamiahotelresort.com [192.168.1.1]. So getting a reply doesn't affect the certificate validation as long as the URL is resolving to the IP.

Screenshot 2024-08-04 141707.png

EDaleH

@basharsaba
Please take a break while I digest and understand your replies. I will be tied up for a day or so and will do my best to assist when sufficient time is available to review your replies in detail.

Please remember that any ping test outside your pfSense internal LAN will fail unless a local 192.168.1.1 actually exists. All you confirm is that the DNS entry is pointing to the same address that you associate with your Captive Portal. This is essential for the browser to associate the SSL certificate with the URL's DNS record and pfSense's certificate specified by the Captive Portal configuration..

Bisho

Please take your time. I'm already grateful for your help.

@EDaleH said in Captive Portal not working on iOS devices only (DHCP 114):

Please remember that any ping test outside your pfSense internal LAN will fail unless a local 192.168.1.1 actually exists.

It makes total sense. In fact, when I'm on pfSense DHCP, the ping test to pfsense.afamiahotelresort.com [192.168.1.1] gets a reply.

@EDaleH said in Captive Portal not working on iOS devices only (DHCP 114):

All you confirm is that the DNS entry is pointing to the same address that you associate with your Captive Portal. This is essential for the browser to associate the SSL certificate with the URL's DNS record and pfSense's certificate specified by the Captive Portal configuration

All Confirmed. Otherwise, the VM Hosts at both locations wouldn't work and get a secure connection with a valid certificate as I explained above.