Clients can't reconnect after pfsense reboot
-
Click here :
-
Ok, this is what i'm actually doing to restore the service.
But of course i can't do this each time pfSense is rebooted and have 300 clients blocked waiting for my action, so i was looking for a long term solution.Thank you
-
I have the exact same issue. Can someone help?
-
As there is no solution yet, I will try to install 2.3.5 and see if its better with that. I will post again for updates
-
@kengo i still can't understand what's going on. I tried to manually re-insert client IPs from sqlite (as they still exist there) in ipfw relevant tables (auth_up, auth_down) but they still can't reconnect.
I must be missing something running under the hood
-
@prophet I'm trying 2.3.5 at this moment and I still have the same problem. If you turn off captive portal, does the problem persist? Mine doesn't so I think its a captive portal issue
-
@kengo I confirm that the issue is related to captive portal
-
@kengo if you dive deeper you will find that Captive portal status is fine after reboot (you can see authenticated clients, stats etc), while firewall is flushed. But based on what i see, it is not enough to recreate firewall rules in auth_down and auth_up tables (the only ones that seem to change when a client connect to captive portal) to make it work again, so there must be something else going on...
-
@prophet thanks for all the info. i actually have an older box running pfsense 2.4.1 and there are no issues so far with the captive portal. i will try to update this version of pfsense to 2.4.1 and see how it goes.
-
@kengo so with 2.4.1 everything works after reboot? did i get it right?
-
@prophet no, i was trying to upgrade the 2.3.5 version of pfsense to 2.4.1 (according to the dashboard) but what happened was it upgraded directly to 2.4.4 and still the same issue persists. i cannot get it to work. as soon as i turn on captive portal, the internet connection is lost.
-
@prophet said in Clients can't reconnect after pfsense reboot:
@kengo I confirm that the issue is related to captive portal
2.3.5 == 2.4.4 main difference is the code-base. The first is 32 bits - the latter 64 bits.
So, totally normal that you found the same issue.The issue has a name and a number : https://redmine.pfsense.org/issues/8783
-
@gertjan sorry but this isn't the same issue.
When pfSense is up i can save/edit anything without problems.I only have problems after reboot, with clients stuck at "You are connected" message in their browser.
-
@prophet said in Clients can't reconnect after pfsense reboot:
@gertjan sorry but this isn't the same issue.
When pfSense is up i can save/edit anything without problems.Can't tell what happens with 2.4.1 - that's old code and ditched because of "security issues".
There is no such thing as a bug list "2.4.1". You're free to use it as long as you accept that product is unsupportable.
So, again, ok to me
I only have problems after reboot, with clients stuck at "You are connected" message in their browser.
And that's the situation right now with 2.4.4 and 2.3.5 (can't test that - have no 32 bits devices).And "Save" on the captive portal's setting will "redo" the ipfw firewall rules and tables. The captive portal's "connected client database" will not get emptied. This is what this issue is all about.
-
-
@prophet said in Clients can't reconnect after pfsense reboot:
by the way bug #8783 is marked as "resolved", so it can't be the same issue. if it was i wouldn't be here :)
You're right.
When 8783 repaired something, this arrived https://redmine.pfsense.org/issues/8616 (other might exist). -
Will be testing older versions of pfsense 2.2 and 2.3 tonight. i will post an update again.
-
@prophet I'm using 2.3.2 and its working like a charm so far. I will post again after 24 hours as I continue to monitor this
-
@kengo excellent!
does it also "remember" clients/users across reboot or do they have to sign in again?
-
I'm curious too.
I've been using 2.3.2 for a while, and I don't remember if users are all logged out. Normally, yes, they would have been.Most of the captive portal settings don't have anything to do with created entries in the related ipfw tables. Better yet : back then, there were no "tables" to hold the authorized devices, there were just rules.
Only this one : "Per-user bandwidth restriction" ( Default download (Kbit/s) and Default upload (Kbit/s)) are used when creating rules.I can imagine that, when FreeRadius is used to restrict "bandwidth restriction" or "Amount of Download and Upload Traffic" is counted, and the rule (and related limiter/pipe) vanishes a moment for a device, things really start to break.
So, saving the config == everybody has to start over. This is far more saver.Btw : Why should one want the captive portal setting regularly ? I didin't touch mine for weeks, if not months. Ones set up as needed, no need to change something.
