Captive Portal stopped working suddenly

[michmoor]

I am able to successfully authenticate but afterward, pfsense doest not move forward and give me internet access. This was a working setup up until a few days ago. No config changes were made. I do see people complaining about captive portal in prior releases but honestly, I haven't had an issue on 22.01.
I want to stress that once I get authenticated , I get the connected message but usually the NetGate splash page would disappear and I have internet. This no longer happens.
Don’t want to reboot the firewall as other functions are working just fine but that is my last resort.

/root: ipfw show
00999 1719125 469279395 allow tagged 1
01000 5791553 4927969729 skipto tablearg ip from any to any via table(cp_ifaces)
01100 9188348376 8025262060486 allow ip from any to any
02100 0 0 pipe tablearg MAC table(guestwifi_pipe_mac)
02101 0 0 allow pfsync from any to any
02102 0 0 allow carp from any to any
02103 20 0 allow layer2 mac-type 0x0806,0x8035
02104 0 0 allow layer2 mac-type 0x888e,0x88c7
02105 0 0 allow layer2 mac-type 0x8863,0x8864
02106 0 0 deny layer2 not mac-type 0x0800,0x86dd
02107 226 19080 allow ip from any to table(guestwifi_host_ips) in
02108 312 238062 allow ip from table(guestwifi_host_ips) to any out
02109 4 1312 allow ip from any to 255.255.255.255 in
02110 0 0 allow ip from 255.255.255.255 to any out
02111 0 0 pipe tablearg ip from table(guestwifi_allowed_up) to any in
02112 0 0 pipe tablearg ip from any to table(guestwifi_allowed_down) in
02113 0 0 pipe tablearg ip from table(guestwifi_allowed_up) to any out
02114 0 0 pipe tablearg ip from any to table(guestwifi_allowed_down) out
02115 212 22186 pipe tablearg ip from table(guestwifi_auth_up) to any in
02116 356 209258 pipe tablearg ip from any to table(guestwifi_auth_down) out
02117 123 14848 fwd 127.0.0.1,8003 tcp from any to any 443 in
02118 92 8247 fwd 127.0.0.1,8002 tcp from any to any 80 in
02119 76 25614 allow tcp from any to any out
02120 108 9504 skipto 65534 ip from any to any
65534 33716 26213831 deny ip from any to any
65535 18 630 allow ip from any to any

ipfw table all list
--- table(cp_ifaces), set(0) ---
igb2.11 2100 1527 547983 1649724715
--- table(guestwifi_auth_up), set(0) ---
192.168.11.6/32 0699:13:c3:2f 2000 212 22186 1649724715
--- table(guestwifi_host_ips), set(0) ---
192.168.11.254/32 0 538 257071 1649724682
--- table(guestwifi_pipe_mac), set(0) ---
--- table(guestwifi_auth_down), set(0) ---
192.168.11.6/32 2001 356 209258 1649724715
--- table(guestwifi_allowed_up), set(0) ---
--- table(guestwifi_allowed_down), set(0) ---

ipfw table guestwifi_auth_up list
192.168.11.6/32 0699:13:c3:2f 2000 212 22186 1649724715

ipfw table guestwifi_auth_down list
192.168.11.6/32 2001 356 209258 1649724715

[michmoor]

[22.01-RELEASE][admin@GA-FW1]/root: ipfw table guestwifi_auth_down list
192.168.11.6/32 2001 188 100560 1649725610

[22.01-RELEASE][admin@GA-FW1]/root: ipfw table guestwifi_auth_up list
192.168.11.6/32 0699:13:c3:2f 2000 141 12905 1649725621

[michmoor]

@michmoor so reviewing past forum posts I see this is still a bug in the code. Reboot of firewall solved this issue but yikes…..don’t run CP on production system. I transitioned to no authentication until a maintenance window to reboot (it helps). Or don’t use pfsense for captive portal which is advisable

https://forum.netgate.com/topic/137824/pfsense-no-internet-when-it-is-said-you-are-connected/161

[Gertjan]

@michmoor

Right now, there are no portal issues.
That is, I use 2.6.0, not 22.01.

There is / was one major issue. You have to make it go away.
Install this pfSense package :

and then you have hit Apply for this this patch :

Furthermore : remove everything everywhere under Firewall => Traffic shaper.
There is a current non resolved issue between ipfw and pf.
So, if you want to use the captive portal (uses ipfw) remove all traffic shaping.

See the many recent forum posts about the subject.

I don't know why you refer to a forum post form 2021. Issues mentioned over there are long gone or implemented.

When I reboot right now, connected users before the reboot will be logged in after the reboot. That works just fine.

I understand that you do not like a reboot, at it would introduce a 60 seconds ( ? ) down time.
But nothing more.
If you even think a reboot might break something, consider already your system broken and fix this asap.

See here my connected portal users.
These are hotel clients, they don't know anything about portals, but can handle the login page just fine.
I use FreeRadius for the accounting and authentication - no issue neither.

[michmoor]

@gertjan A few assumptions made in your response so lets deail with them accordingly.

1. Right now, there are no portal issues. That is, I use 2.6.0, not 22.01
   Clearly not accurate as I just reported an issue. Now if others are reporting or not is not known as we don't know how often captive portal services are used and how often problems arise. My CP has been operating without issue for months.

2. Furthermore : remove everything everywhere under Firewall => Traffic shaper.
   I gave no indication that I'm using any traffic shaping. I am not.

3. If you even think a reboot might break something, consider already your system broken and fix this asap.
   Huh? This statement is nonsensical on many levels. First of all this firewall is used in a business setting. Would need to schedule downtime in order to reboot. I've also rebooted my Juniper VCF a few weeks ago due to issues in software. Your thinking is the system already broken and fix it ASAP? What are you saying at this point? Rebooting is a fact of life and as much as we all love stability, sometimes long uptimes causes software instability.

4. Prior to editing your post you made mentioned as to why I was bringing up an old post from 2021. For an extremely obvious reason - the symptom of the issue is still present in the new release. Hence why I pointed to it. The fix then as was the fix for me was to do a reboot through the GUI to solve.

[Gertjan]

@michmoor

1. I should have said : I haven't, 'my' users are connected.
   A possibility is : you are using the portal differently as I am, so you've surfaced an issue ? That's what we should determine.

2. The bug that came with 2.6.0 (and 22.01 ?? I can't tell, but I do presume so) only passes TCP traffic, no UDP, no ICMP. The System_Patches was updated, and is now needed to apply rapidly patches. You have applied patch 12834 ?

3. A reboot takes time. It will take the connection off line. I thought you had other issues with that. I reboot a lot, you can see the stats, not for stability reasons. Just to test code that only executes at boot. Sorry for the misunderstanding.

4. the post from 2021 mentioned the fact that a database file that lists the connected users wasn't deleted after a reboot.
   It was this file /var/db/captiveportalcpzone1.db where cpzone1 is your zone name.
   pfSense would find this file when it rebooted, and users listed in it were considered as connected. But the related ipfw firewall rules were not re re created.
   These rules are actually entries in your tables :
   guestwifi_auth_down and table guestwifi_auth_up
   IP and MACs listed are the users that are connected.

With this new option (back then) :

the connected user list was preserved, and entries in the two tables are now added accordingly : upon reboot, the clients are still connected.
If you suspect a bug : remove the check to get the old (also good) behaviour back : all users will get disconnected upon boot.

The bug back then effect was : no ipfw firewall rule were created. The result : the user was told he was already connected, but this wasn't the case.

@michmoor said in Captive Portal stopped working suddenly:

This was a working setup up until a few days ago. No config changes were made.

If pfSense itself didn't change, neither the config, then something out of pfSense changed ?
Or hardware ?
I know, this doesn't make sense.

[michmoor]

@gertjan Let me turn down the temperature on my end. I came across as a bit too hot and there may have been some communication barriers with each other. I apologize for that.

The issue is resolved by rebooting the pfsense but the symptoms are the same as others reported. They are able to connect to the portal, sign-in, and it tells them they are connected but no Internet access is possible. The fix was to reboot but it was such a strange issue where everything about the firewall was working correctly except this package.

I did have the option "Preserve users database" checked. Once I unchecked that and rebooted it, I was able to sign-in and get Internet access. For now, that seems to be an issue that I discovered.

[Gertjan]

@michmoor said in Captive Portal stopped working suddenly:

.... for that.

Not needed. And ok anyway.

@michmoor said in Captive Portal stopped working suddenly:

but the symptoms are the same as others reported

Just for me, to check, to what forum messages are you referring to ?

What you can do at any time if you suspect an issue :
Don't reboot yet.

Inspect with 'ipfw' the tables guestwifi_auth_up and guestwifi_auth_up
Every MAC + IP must correspond with this list :

If you see in the GUI a connected client that is not present in the two ipfw tables, there is an issue.

@michmoor said in Captive Portal stopped working suddenly:

I did have the option "Preserve users database" checked.

This means that, upon boot, the list ( the data base file where all the connected users are stored )is used to create the corresponding entries in the two tables guestwifi_auth_up and guestwifi_auth_up.
At that moment, the devices using their MAC, and the IP, can pass.
If, for example, the device changed it's IP, well, the, yeah, it's blocked. But the client should be able to login again.

@michmoor said in Captive Portal stopped working suddenly:

Once I unchecked that and rebooted it

This is what was the default behaviour in the past.
Upon boot, the ipfw tables guestwifi_auth_up and guestwifi_auth_up. are empty, and the "connected users database" ( this file : /var/db/captiveportalcpzone1.db, an PHP SQLite file ) is reset to zero (zero file length ).

Btw : please confirm : You have installed the System_patches pfSense package, and activated the path I mentioned above ?
If not, pfSense 2.6.0 (and CE probably) is pretty broken. And not for the last days or so, but since you upgraded to 2.6.0 or 22.01.
I do think you did, as :

@michmoor said in Captive Portal stopped working suddenly:

00999 1719125 469279395 allow tagged 1

Looks like you did, but I'm not sure.

Also : if everything was working fine before, and nothing changed (no major upgrades) then the issue is most probably 'not pfSense' or the settings. Something else changed.