Full functionality Captive Portal with version 23.05.1

hsrtreml

@Gertjan Thanks, so do nothing... and wait

Gertjan

Well, no.
What about sharing sources ? So some (fact) checking can be done. And if needed, a redmine 'bug' entry should be created.
Waiting and doing nothings is long for the shorter 'waiting', and this one might as well last forever. Nothing will get repaired if it is unknown.
You're still on 22.01, that's you entering the danger zone as that version is already depreciated.

hsrtreml

@Gertjan ok, i will testing on our pfsense sync-System on Netgate SG-4860. Next weekend I will see more....

hsrtreml

@hsrtreml said in Full functionality Captive Portal with version 23.05.1:

@Gertjan ok, i will testing on our pfsense sync-System on Netgate SG-4860. Next weekend I will see more....

side effect on sg-4860 wiht 23.05.1 .. no problem?

hsrtreml

@hsrtreml said in Full functionality Captive Portal with version 23.05.1:

@hsrtreml said in Full functionality Captive Portal with version 23.05.1:

@Gertjan ok, i will testing on our pfsense sync-System on Netgate SG-4860. Next weekend I will see more....

side effect on sg-4860 wiht 23.05.1 .. no problem?

/boot/loader.conf.local
This can typically be worked around by disabling the affected device, with some caveats.
To disable the ichsmb0 device, which will disable the LED status indicators, add the following Loader Tunable:
hint.ichsmb.0.disabled=1

Gertjan

@hsrtreml said in Full functionality Captive Portal with version 23.05.1:

/boot/loader.conf.local
This can typically be worked around by disabling the affected device, with some caveats.
To disable the ichsmb0 device, which will disable the LED status indicators, add the following Loader Tunable:
hint.ichsmb.0.disabled=1

This is hardware version related.
I do not use a 4860, I've a 4100.

Btw : why would a Netgate device not be supported by Netgate software, leds included ?

hsrtreml

@hsrtreml
My findings:

Captive portal does not work on local area connections (no redirection)- it works with WLAN!
DHCP server leaves fixed addresses in IDLE status; no further access possible (... other device has this address...)

We go back to SG-7100 1/22. Since with 23.05.01. cannot work in a professional environment. We will report a bug to Netgate.

Gertjan

@hsrtreml said in Full functionality Captive Portal with version 23.05.1:

DHCP server leaves fixed addresses in IDLE status; no further access possible (... other device has this address...)

My captive portal DHCP setup :

as you can see, IP 192.168.2.2 to 192.168.2.9 are not in the DHCP lease pool, which goes from 192.168.2.10 to 192.168.2.254 (the end).

I reserved these 8 addresses for my access points (a captive portal is mostly a Wifi network after all).
My 3 APs can communicate just fine, because I've added them here :

The DHCP server doesn't deal or interact with devices that have a static IP setup. These device do not emit any DHCP requests.

If a device uses a static IP, and that IP is part of a DHCP pool, then, yes, troubles are incoming.

@hsrtreml said in Full functionality Captive Portal with version 23.05.1:

Captive portal does not work on local area connections (no redirection)- it works with WLAN!

A WLAN or Wirelles LAN is something like this :

[pfsense](portal Network) <=> (cable)<=>(AP network port)[AP](radio transmitter)

The AP itself is completely transparent for the device using the AP, and pfSense. pfSense 'sees' (uses) the IP of the wireless device, and sees/uses the MAC of that device.

A wired connection : exactly the same thing, without all the radio stuff. Again, pfSense sees/uses the IP and MAC of that wired device.

If I activated the captive portal on my pfSense right now, I would lose connection to this forum.
I would have to simulate a link down and link up on the wired NIC of my PC - I could do that by de-activating and then activating the Network adapter (NIC).
Windows (7,8,10 or 11) would show a popup with the message 'some user attention is needed' : clicking on it would open up a browser, and .... I would see the pfSense login page.
After login, my PC will be connected to the Internet again.
I tried this many times, works always.

I just connected my PC to the captive portal instead of the my LAN : works, I saw the portal login page.

So, there is good news : it works for me. And impossible to speak for others, but I presume I'm not the only one

@hsrtreml said in Full functionality Captive Portal with version 23.05.1:

We will report a bug to Netgate

What about posting your findings here and the very needed 'do these steps to reproduce the issue' ?

hsrtreml

@Gertjan Thanks for your helping; meatime i found some problems/solutions:

simple: one IP-Adress was double

difficult: i get the portal login on LAN connection only with http://xxxx/index.php?zone=xy

Is that a problem with our Mac-System OS or a bug of pfsense?

Gertjan

@hsrtreml said in Full functionality Captive Portal with version 23.05.1:

difficult: i get the portal login on LAN connection only with http://xxxx/index.php?zone=xy

Is that a problem with our Mac-System OS or a bug of pfsense?

I propose an test.

Disconnect everything - no exceptions - from your portal network.
Add a swicth to the portal network, and make the wired connection between the pfSense portal network NIC and the switch.

Use the Diagnostics > Packet Capture and select the interface you use for the captive portal.
Set the "View options" to High.
Set the packet counter to "100" (probably enough.
Start it.

Nothings happens .... because there is no traffic yet.

Now, connect the NIC of the MAC into to switch.

The packet capturing probably stops. As it captures 100 packets.

What you will see first :
DHCP negotiations.
Then you see a DNS request for some Apple site : probably "captive.apple.com" or "apple.com".
This DNS part is important. And that's why "if DNS is broken, the portal goes with it".

Then you will see that the MAC fires of a http (with port 80 as a destination !!) so not https, to http://captive.apple.com/hotspot-detect.html
And that is the moment you saw with your own eyes that captive portal support is not pfSense, ... no, it is your device ( !! )

The "Success" check should return the word "Success".
If not, the mac will presume that there is a portal present - and launch a browser - and repeats in the browser the same request.
What comes next is .... the pfsense captive portal shows up in the browser, as the browsers initial request "captive.apple.com/hotspot-detect.html" is redirect by the pfSEnse firewall to the pfSense captive portal webserver - and rewritten by that web server as ..... a web page where you can enter a user name and a password.
So captive.apple.com/hotspot-detect.html gets rewritten as http://xxxx:800x/index.php?zone=xy&redirlurl=captive.apple.com/hotspot-detect.html

I don't own a MAC, I do own iPhones, Ipads etc. They all behave the same way. They work just fine.

Btw : it is of course very possible that you changed your MAC's network parameters. Something 'not default'. Like "adding a firewall that breaks everything" or something else.
Very popular is also : using some Fortune 500 DNS server and not the pfSense DNS : that won't work, as the firewall blocks all outgoing connections (except to the pfSense local DNS port 53).

hsrtreml

@Gertjan yes I get:
The "Success" check should return the word "Success". As well as I use google-dns.

and i am try www.apple.com within allowed hostname, but no landing to portal login page.

What can I do for my captive portal user? There are not IT professionals ...

Gertjan

@hsrtreml said in Full functionality Captive Portal with version 23.05.1:

As well as I use google-dns

Ok to use the resolver as a forwarder to google-dns.
But the captive portal users should have DHCP activated, and no static IP, Gateway or DNS settings. This means that for a portal user, when you look at the DCP lease they obtained, they should have the DNS IP set to the pfSense portal IP. I other words, for a portal user, the DNS should be pfSense.
For a Windows user : type "ipconfig /all".

@hsrtreml said in Full functionality Captive Portal with version 23.05.1:

and i am try www.apple.com within allowed hostname

Why www ?
No need. I never had to do this. It even might break portal.
The thing is : captive.apple.com is resolved by the MAC / iPhone OS.
It should receive a valid answer, an A record like "17.253.109.202".
So, DNS should work for the portal client. you can check this even before login in to the portal.
You should be able to do a nslookup (Windows PC) on the client, and "nslookup captive.apple.com" should show something like this :

Serveur par defaut :   pfSense.bhf.net
Address:  192.168.2.1

> captive.apple.com
Serveur :   pfSense.brit-hotel-fumel.net
Address:  192.168.2.1

Réponse ne faisant pas autorité :
Nom :    captive.g.aaplimg.com
Addresses:  17.253.109.202
          17.253.109.201

Then it connects to this IP "17.253.109.202" using TCP, to port 80, and it want to get a page back that shows "Success". If that's the case, the device knows that it has a direct Internet connection.
If not (something else came back), then it presumes a captive portal. Etc.

@hsrtreml said in Full functionality Captive Portal with version 23.05.1:

What can I do for my captive portal user? There are not IT professionals ...

I use the captive portal for a hotel. We receive mostly people that know nothing about "IT" or anything related.

I don't know these people. They are probably not even aware they use something that is called a "captive portal". Some of them are over 80 years old ! They saw a login page, they were asked to enter their room number and the password noted down in the leaflet on the desk in their room.
This works just fine for the last decade or so.
And it doesn't matter if they use a PC, a pad, a phone or whatever. the younger ones even connect their Play station or whatever.

I brought with me my Windows 11 portable this morning.
I selected the hotel's public Wifi network, and click "connection".
I had noting more to do .... my default browser opened up by itself (I ditched Edge, its Firefox) and the portal's login page was showing up.
This is probably not a default behavior I guess. More default would be : the browser opens, and at the top of the empty window there is a line that says :

You can also see that I'm using the https login page, and that the Microsoft captive portal test has this URL : http://www.msftconnecttest.com/redirect
I think I've instructed my browser (Firefox) that it is ok to open this page.
Otherwise the page would have been blank, and I had to hit the :

button.

The warning is understandable,as the browser wanted to visit :
www.msftconnecttest.com
and it got a redirect answer form a RC1918 (your pfSense captive portal IP !) like 192.168.2.1 and that is not where www.msftconnecttest.com is pointing to : 17.253.109.202 or 17.253.109.201.
As this is 'http' and not 'https' : so no big deal, http redirecting this is allowed, but modern browser do warn the users.
As said, they have to hit the button if they want to continue.

Take note : my portal is using https.
So the http request is redirected to (for me) : https://portal.bhf.net:8003/index.php?zone=cpzone1&redirurl=www.msftconnecttest.com/redirect

Side note : my captive portal is using port 8002 for TCP http connection, but this one isn't used in my setup. It does exist, though.
My captive portal users are redirected to port 8003, which is using https (normally port 443).

This means I have to use a recognized certificate that says it's "portal.bhf.net". This certificate is signed by a known signer (for me : Letsencrypt). And of course, I 'own' (rent !) the domain name "bhf.com".
https usage is somewhat mandatory these days. Used certificates have to be signed by known signers, otherwise the browser will error out, and my no-IT-captive-portal-users will not proceed .... (they are not that stupid).

hsrtreml

I brought with me my Windows 11 portable this morning.
I selected the hotel's public Wifi network, and click "connection".
I had noting more to do .... my default browser opened up by itself (I ditched Edge, its Firefox) and the portal's login page was showing up.
This is probably not a default behavior I guess. More default would be : the browser opens, and at the top of the empty window there is a line that says :

You can also see that I'm using the https login page, and that the Microsoft captive portal test has this URL : http://www.msftconnecttest.com/redirect
I think I've instructed my browser (Firefox) that it is ok to open this page.
Otherwise the page would have been blank, and I had to hit the :

button.

The warning is understandable,as the browser wanted to visit :
www.msftconnecttest.com
and it got a redirect answer form a RC1918 (your pfSense captive portal IP !) like 192.168.2.1 and that is not where www.msftconnecttest.com is pointing to : 17.253.109.202 or 17.253.109.201.
As this is 'http' and not 'https' : so no big deal, http redirecting this is allowed, but modern browser do warn the users.
As said, they have to hit the button if they want to continue.

FIREFOX it woks, but not with SAFARI (no information to connect ....)

Gertjan

@hsrtreml said in Full functionality Captive Portal with version 23.05.1:

SAFARI (no information to connect ....)

Using a MAC ?
When I use my iPhone (also apple), when I connect to the portal, I see :

so it has an IP, DNS, and a gateway. So everything needed to connect.

On my iPhone, no need to open a browser.
The OSX will open up (a very limited) browser, probably a low-bud Safari browser as it is build in. This browser shows the login page.

My PC which I wired up with wires, no Wifi, to the captive portal network : it got an IP etc :

Carte Ethernet Ethernet 3 :

   Suffixe DNS propre à la connexion. . . : bhf.net
   Description. . . . . . . . . . . . . . : Realtek USB GbE Family Controller
   Adresse physique . . . . . . . . . . . : 00-E0-4C-68-E5-8D
   DHCP activé. . . . . . . . . . . . . . : Oui
   Configuration automatique activée. . . : Oui
   Adresse IPv6 de liaison locale. . . . .: fe80::67c3:138e:1597:1ac7%15(préféré)
   Adresse IPv4. . . . . . . . . . . . . .: 192.168.2.197(préféré)
   Masque de sous-réseau. . . . . . . . . : 255.255.255.0
   Bail obtenu. . . . . . . . . . . . . . : jeudi 10 août 2023 12:20:27
   Bail expirant. . . . . . . . . . . . . : vendredi 11 août 2023 12:14:41
   Passerelle par défaut. . . . . . . . . : 192.168.2.1
   Serveur DHCP . . . . . . . . . . . . . : 192.168.2.1
   IAID DHCPv6 . . . . . . . . . . . : 788586572
   DUID de client DHCPv6. . . . . . . . : 00-01-00-01-2A-DE-37-69-14-5A-FC-59-27-FF
   Serveurs DNS. . .  . . . . . . . . . . : 192.168.2.1
   NetBIOS sur Tcpip. . . . . . . . . . . : Activé

This tray icon, the wired connection symbol, had a message that said : "connection ok but you have to do something".
I opened my browser ..... the captive portal login page was shown.

I'm using a close to default Windows Pro 11 PC.

So, wired or Wifi : no difference.

Btw : I can not test with a real MAC ...... but 'they' have told me : works fine. My portal clients bring along ones in a while a MAC : works.

hsrtreml

@Gertjan said in Full functionality Captive Portal with version 23.05.1:

@hsrtreml said in Full functionality Captive Portal with version 23.05.1:

SAFARI (no information to connect ....)

Using a MAC ?
When I use my iPhone (also apple), when I connect to the portal, I see :

so it has an IP, DNS, and a gateway. So everything needed to connect.

On my iPhone, no need to open a browser.
The OSX will open up (a very limited) browser, probably a low-bud Safari browser as it is build in. This browser shows the login page.

My PC which I wired up with wires, no Wifi, to the captive portal network : it got an IP etc :
Carte Ethernet Ethernet 3 :

   Suffixe DNS propre à la connexion. . . : bhf.net
   Description. . . . . . . . . . . . . . : Realtek USB GbE Family Controller
   Adresse physique . . . . . . . . . . . : 00-E0-4C-68-E5-8D
   DHCP activé. . . . . . . . . . . . . . : Oui
   Configuration automatique activée. . . : Oui
   Adresse IPv6 de liaison locale. . . . .: fe80::67c3:138e:1597:1ac7%15(préféré)
   Adresse IPv4. . . . . . . . . . . . . .: 192.168.2.197(préféré)
   Masque de sous-réseau. . . . . . . . . : 255.255.255.0
   Bail obtenu. . . . . . . . . . . . . . : jeudi 10 août 2023 12:20:27
   Bail expirant. . . . . . . . . . . . . : vendredi 11 août 2023 12:14:41
   Passerelle par défaut. . . . . . . . . : 192.168.2.1
   Serveur DHCP . . . . . . . . . . . . . : 192.168.2.1
   IAID DHCPv6 . . . . . . . . . . . : 788586572
   DUID de client DHCPv6. . . . . . . . : 00-01-00-01-2A-DE-37-69-14-5A-FC-59-27-FF
   Serveurs DNS. . .  . . . . . . . . . . : 192.168.2.1
   NetBIOS sur Tcpip. . . . . . . . . . . : Activé
This tray icon, the wired connection symbol, had a message that said : "connection ok but you have to do something".
I opened my browser ..... the captive portal login page was shown.

I'm using a close to default Windows Pro 11 PC.

So, wired or Wifi : no difference.

Btw : I can not test with a real MAC ...... but 'they' have told me : works fine. My portal clients bring along ones in a while a MAC : works.

Yes it is a MacPro Book, OS 12.6.8 with Safari
The device get form dhcp an IP. Only within Safari I get not a "Button" to connect the Internet/Portal...

all WiFi-Devices, like IPad, IPhone as well as MacPro (see above) are ok.

Gertjan

@hsrtreml

Google gave me a good tip.
I asked : Mac Pro OS 12.6.8 captive portal connect and found a probable issue.

The thing is : you've probably used this device already to the SSID and router/firewall pfSense when there was no captive portal activated. So your MAC is not going tot auto prrtal detects, as it knows that that isn't the case - but now it is.
Solution : delete the SSID profile in your MAC, and connect again. This time, the captive portal detection will work (because it's, after all, a new 'unknown' network).