Captive Portal stops working after 2.7 upgrade

moeller

tldr: If you having problems with portal page timeout: uncheck "Disable HTTPS Forwards"

Happy new year. I am back at work and redid the update to pfsense 2.7.2. First i screenshoted all captive portal relevant options, to compare if problems occur.

After the update i had the same problems:

Captive Portal stopped working:

User entering the Network
redirecting to the portal page
==> getting timeout opening the portal page

but my first guess was right. I've had checked the last option at the captive portal settings page: "Disable HTTPS Forwards"
I unchecked the option, saved and immediately the portal page opened.
Checked the option again -> portal page timeout.
Unchecked again, portal page is loading again.

this was working at version 2.6.0. Can someone confirm this behaviour at version 2.7.2 with this option?

Gertjan

@moeller

If the https mode is set up, like :

or, like for me :

Disable HTTPS Forwards" should be unchecked because you actually want to use HTTPS, the pfSense web portal login HTTPS page server.

Keep in mind : the device that is connected to a captive portal network will 'never ever' use https.
It will do a http (not s ) request, using 'some' IP and port 80, and this request will get redirected by a pfSense captive portal portal web server to the identical https (so now using port 443, TLS), replacing the IP by the network host name, like 'portal.yourpfsense.tld'.

I guess ( ? ) that the "HTTPS Forwards" check box comes in handy when you are in the experimenting phase with the captive portal,and you don't have a certificate yet.
In the past, everything was http and https was for the geeks.
These days, http is close to being banned everywhere, everything is https, so a certificate is mandatory. No big deal, you can get them for free - that's what the acme.sh pfSense package is all about
That is : you need to own (rent) a "domain name".

moeller

@Gertjan I had the option checked for the scenario: User with opened browser and tabs connects to network. Browser tries to reload tabs, because now there is a network connection. CaptivePortal redirects the connection to the portal page -> Browser does a https cert warning because of not matching cert.
But i dont now if this problem still consists with modern browsers.

How should I deal with this now? It was working at version 2.6.0, and regardless how to use it, It should not block accessing the portal page.
Should i open a ticket/bug report/issue at redmine?

Gertjan

@moeller

In a perfect world, a captive portal user shouldn't need know "anything" upfront if he/she want to use a Wifi (or cable) connection.
But, when using a Wifi 'not from home' or some other not private SSID (family, fiends, work etc) they should be ware that the connection is temporary.
Connecting to such a wifi network : they select it, and the will think/say : "hey, no password is asked" ?
When they connect to an unknown SSID network, IMHO, "all browsers should be closed".

The simple fact they connect to a network (cable or SSID wifi) will fire up the OS 'portal detection system', right after the device's DHCP client did its work, and an IP, gateway, DNS, network has been obtained.
Needles to say : any unknown network should be accessed using DHCP, which is always the default interface setting.

The OS portal detection will do a DNS request for an OS depended URL, and then a 'hidden' web request using port 80 ( always ! ) to the DNS obtained IP. Note somewhere : don't break DNS.
If the/a magic word - the html page - like "Success" comes back, then the device knows that it has a direct Internet access is available. The portal detection ends there : there is no portal.

If something else comes back, the OS will signal this to the device user, most probably by opening the default browser, and repeat the URL(IP) request.

The browser isn't , originally, using an URL, but the IP of the URL, and retries to connect, using port 80.
The IP will get redirected on pfSense firewall level to the captive portal interface IP, and port '80' will get replaced by something like "8001".

If you do not use https login, a page will get shown : this is the http portal login page.
If you use https for the captive portal login page, the IP based request (using port 8001) will get redirected to URL/hostname of the pfSense portal, port 8002 (this is the https version of the portal login web server). The host name should match the certificate coming from portal web server ( ! ).
This works, because http can get redirected to another http, using IP or URL, or to a https (using URL !!) without the browser complaining.

Anyway, all this to say :
2.6.0 works, correct. It did so for me, if I recall well, as it is so old ...
2.7.0 idem.
2.7.2 idem.
Now I'm using pfSense Plus, 23.09.1, so I'm using that. The underlying "portal code" (some PHP script file etc) is the same.
I'm using it right now : my hotel client's are using it all the time.

rm

@Gertjan My HTTPS forwards is unchecked. I'll step through the upgrade again today to see if anything changes. I expect that once I do, captive portal will no longer present and everyone will just pass through. @Gertjan , you note the firewall change in the product upgrade, could this be the factor at play? I have no linux expertise and just configure via the web portal. Is there something else that should examined that functions differently via upgrade? Also noted this may be a 2 step upgrade, 2.6 > 2.7 > 2.72., at least what the GUI is showing this morning. I'll provide an update once completed.

rm

@rm So I did a flat 2.7.2 install and configured most items manually with no issue, Out of box captive portal works but any attempt to restore the old config will break it. There's some incompatibility I assume between versions. Couple of questions:

Is there any size limitation on the number of items than can be in the local database? I have about 312 mac addresses configured for passthrough
I have a custom captive portal page that on 2.6 renders on port 8003, the default on 2.7.2 seems to be 8002, can that be the issue? Not seeing where I can modify the redirect port in GUI

Tried pruning the xml file to use the 2.7.2 config but with certs, passthrough macs, custom logon page and certs from the 2.6 xml without success. Think I can download and rebuild the certs and page/image content if required but the macs will be a dealbreaker if I can't figure it out.

Thanks in advance for any guidance.

Gertjan

@rm said in Captive Portal stops working after 2.7 upgrade:

Out of box captive portal works but any attempt to restore the old config will break it.

That's more like it.
"Your settings break things". Easy solution : re do them. I know, this will take some time.

@rm said in Captive Portal stops working after 2.7 upgrade:

There's some incompatibility I assume between versions.

I haven't found any, and I'm using the portal since pfSense version 1; a decade or so ago.
It works for me.

Is there any size limitation on the number of items than can be in the local database? I have about 312 mac addresses configured for passthrough

The user database doesn't have a real limit, the system will just slow down. Portal with several thousand active users aren't uncommon. Just don't use a arm base SG1100 to handle it, get something beefier.
BTW : MAC pass-through declared devices isn't a captive portal thing. All the MACs are listed in a firewall table, like an alias, and an early portal firewall rule let traffic pass if it was emitted by a device using a MAC that is listed in the table used by the firewall rule.
312 MAC devices is 'nothing', even for a small pfSense.

@rm said in Captive Portal stops working after 2.7 upgrade:

I have a custom captive portal page that on 2.6 renders on port 8003, the default on 2.7.2 seems to be 8002, can that be the issue? Not seeing where I can modify the redirect port in GUI

You don't need to know, or handle, or set up, or do anything about the fact that the captive portal web server is using port abcd (maybe 8002 ?) for http and port efgh for https (8003 ?). If you need to hard code this port number somewhere, your setup is already not ok at all.

The device, when connecting to a cable or Wifi network (any network !!) will start a portal detection phase. All modern OSs do this these days. Which means that the captive portal support is actually build in your device, not pfSense.
The portal firewall will redirect a classic web request (TCP port 80) to the captive portal web server port, like abcd. You don't need to use yourself this abcd port number anywhere.

You can see this happening in the captive portal's firewall rule set :
Let's set up some stuff upfront :

igc1 is my portal interface.
<cpzoneid_2_cpips> is my portal's interface IP : it's defined in the rule set :

# Captive Portal
table <cpzoneid_2_cpips> { 192.168.2.1}

All traffic coming in on igc1, my portal's interface, is tagged :

# Captive Portal
ether pass on { igc1  } tag "cpzoneid_2_rdr"
ether anchor "cpzoneid_2_auth/*" on { igc1  }
ether anchor "cpzoneid_2_passthrumac/*" on { igc1  }
ether anchor "cpzoneid_2_allowedhosts/*" on { igc1  }

Here comes the action :

# Captive Portal
rdr on igc1 inet proto tcp from any to ! <cpzoneid_2_cpips> port 80 tagged cpzoneid_2_rdr -> 192.168.2.1 port 8002

This says : REDIRECT traffic coming IN on interface igc0 using protocol TCP and port 80 that does NOT go to <cpzoneid_2_cpips> ( == 192.168.2.1 for me) and is tagged "cpzoneid_2_rdr"
TO 192.168.2.1 port 8002.

And guess what : the captive portal login web server listens on interface 192.168.2.1 port 8002.

Btw : this : [ traffic coming IN on interface igc0 using protocol TCP and port 80 that does NOT go to <cpzoneid_2_cpips> ] is normal http (port 80) web request to "some webs server on the Internet". This web request is the captive portals detection URL.
For an Apple device, this is "http://captive.apple.com/hotspot-detect.html".
If there is NO portal present, a known answer will show : to see it, click on the link ;)
If there is a portal, something else will get shown.

@rm said in Captive Portal stops working after 2.7 upgrade:

Tried pruning the xml file to use the 2.7.2 config but with certs, passthrough macs, custom logon page and certs from the 2.6 xml without success

Use a clean config file.
Importing a couple of certs - or make new certs. Old certs might use old certificate related stuff that has been ditched now. My portal certs are auto regenerate with acme.sh package, so I can just get a new one with a click.
My OpenVPN CA and certs are valid xx years, so you have to redo them ones a decade or so.

I've added a couple of IPs and MAC into my captive portal, and I agree : adding many of them is tedious.
What you might do : add just one :

Export your cnfig.xml.
Use the SFTP (FTP over SSH) access and Notepad++ from now on.
Locate where the MAC is stored :

Your job : copy paste as many if you want and there is just one rule :
don't f*ck *p with the syntax / file (XML) format.
Tabs, spaces, EOL everything should be the same.

save and import the file.

My advice : don't use the bandwidth limits, as I suspect there is an issue with that ( up or down, I don't recall).

Btw : if you have that many MACs to white list, I tend to say these devices do not belong on the portal network, but some other network, as these devices are, unlike portal users, trusted.

You should keep complex systems always as simple as possible.
Just because you can make complex stuff doesn't mean you should do so : if you have to redo the config, you'll be able to rebuild your portal and firewall as fast as possible.

rm

@Gertjan Lol on xml syntax. Thanks for the detailed reply, Been using Pfsense for about as long as you and really the first hiccup. I'll rebuild from scratch when I get the time.
You are correct on the passthrough being trusted or registered devices. Our wifi is still basically an untrusted network, but we want to know who's connecting and trace the macs back if needed. Sounds like you have a different model in mind?

Thanks again,
R.

Gertjan

@rm said in Captive Portal stops working after 2.7 upgrade:

Our wifi is still basically an untrusted network, but we want to know who's connecting and trace the macs

Trace MACs ?
They will be shown in the captive portal authentication log.
They will be shown in the captive portal DHCP server log.
They will be complete unreliable info, as most devices now (can) randomize their MACs.

When a MAC is added in the pass mode, the device (the user) won't see a login page anymore, traffic just passes. JUst like if the portal functionality wasn't even there.
I added the MAC's of all my APs present on the portal network so they can NTP out, check for updates, and they can send notification to me, like new year wishes etc.

If the added MAC is in blocked mode, the user will actually see a (not) login page with the message : "Your MAC is blocked".

rm

@rm yeah, we they have to turn off the private to passthrough, the mac list correlated to user/device which makes things easier. Rebuilt from scratch, merged all the passthrumac, allowedhostname and allowedips in xml without issue. thanks for all the input! Here's hoping upgrades are a non-event for the next decade.

rm

@rm MAJOR UPDATE: So while comparing and applying previous settings I found the setting that was breaking my captive portal from functioning.

SystemAdvancedFirewall & NAT :Disable all packet filtering. When checked this breaks captive portal redirect on 2.7.2 and allows traffic.