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

[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:

1. 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.

2. 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.

3. 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?

[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.

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.

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 ?

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.

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.

[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.

[Gertjan]

@basharsaba

The certificate you use contains the (only) 'SAN' : "pfsense.af####.com"
It should also contain "portal.af####.com".

Again, the portal URL is "portal.af####.com" so the certificate should contain "portal.af####.com".

I agree with @EDaleH : a portal should be on it's own LAN type interface like OPTx - but not LAN - or WAN. But ... it does work when you use LAN.

[Bisho]

@Gertjan
I'm using now a new URL pfsense.af####.com with a new certificate that only contains pfsense.af####.com and pointing to 192.168.1.1 (Dynamic DNS) and all the configuration has been changed according to this new URL. Why would I still need the old URL portal.af####.com ?? In fact, I can do that, but I know it will lead to the same issue.

I can work on OPTx later. For the time being, let's keep it on LAN. The most important and mysterious question is why both VM Hosts at both locations are getting a secure connection with a valid certificate, unlike any connected device.

[EDaleH]

@basharsaba
Let’s review the pre-requisites within pfSense besides the setup under Captive Portal.

Under System, Certificate, Authorities you must have a Certificate Authority for your certificate and it must contain a current copy of the Certificate data. Either ACME is taking care of that for you or you are pasting the Certificate Data into the box with that label. Note the “Name” of that external issuer. Under the Certificates column of Certificate Authorities you will see at least the number 1 for quantity, that is the certificate for the portal.

So, go to System, Certificate, Certificates and in the name column you will see your domain name listed. The Issuer will match the “Name” in the above. In the “In Use” column you should see at least Captive Portal DNS Resolver and possibly Acme(1) if you are using ACME to renew your certificate.

If you have not updated the certificate data above after adding a subdomain to the certificate, it won’t work because the SAN list (Subject Alternative Name) does not contain the subdomain you pointed the captive portal at. Thus, certificate error.

Now that covers the certificate, how does the browser find the Captive Portal?

You are now familiar with the URL required to launch the login page to get through the captive portal. You can force this page to load in a browser tab by either having the Captive Portal capture your attempt to go to an http site, by entering the portal url directly into the browser URL or by using RFC8910’s DHCP114 to send the URL to an aware device that will typically launch a custom browser to load that page directly without being “captured and redirected to it”. What the browser is and how it got that URL entered is no longer important. Now the browser processes the request.

Well, it needs to find out where that domain is so it does a DNS query and gets an IP which is the IP of the Captive Portal, 192.168.1.1 in your example.

As this is an ssl request, it retrieves the public SSL key and it is the job of pfSense to handle the private key. If there is a subdomain like portal.domain.com, the “portal” subdomain must exist in the SAN list of the certificate and it provides the IP address as it also must exist in the DNS for the domain. If there is a discrepancy in any of the above, you get a browser specific SSL certificate error. You can look it up in edge by clicking the lock icon, then details, then Certificate Subject Alternative Name. Below is an example for gmail.com: Note accounts.google.com and *.partner.android.com are SANs

For me, the introduction of Dynamic DNS, VM, etc is just a lot of noise to distract you from the final objective. When you have the error on the laptop, drill into the certificate data by clicking on the square icon with the upper right arrow.

and try to figure out what is offside. If you get a successful connection, also verify the SAN list.

You need to identify what is failing and ensure the pfSense certificate data is current. The browser should tell you why it failed.

[Gertjan]

@basharsaba

Because : You should (I really advice you to do so) :

== remove "portal." in front of the domain name. It doesn't belong their.

This pfSEnse.af#######sort.com has IP 192.168.1.1 - that's your LAN host name pfSEnse network name.
Now you can access pfSense using pfSEnse.af#######sort.com from LAN.

Then : go her :

and I presume that your captive portal IP is 192.168.2.1.

Remember to set up the captive portal DHCP server - pool for example 192.168.2.10 -> 192.168.2.254.

For starters : set up a generic pass all fire wall rule on the Portal interface.

Check that unbound listens on the portal interface.

If you need certs, and you use acme.sh : ask for two (yeah,n why not) certs :
One for pfSEnse.af#######sort.com - use this one for the pfSense GUI
One for portal.af#######sort.com - use this one on the captive portals setup page.

From now on, when a DNS request for "portal.af#######sort.com" comes in (pfSense), it will answer "192.168.2.1" !!
The portal web server will be contacted, and it will have a cert that says : I am "portal.af#######sort.com" => this is what https is all about.

Done.

Btw : Go here : https://www.youtube.com/@NetgateOfficial/videos and look for the 2 (3 ?) captive portal videos.
There are old.
But still very valid.