Pfsense, No internet when it is said "You are connected".
-
- we have over 100 so it’s not isolated
2 they stopped working with a recent update.
3 you’re getting dhcp because you are getting redirected to the page that says your connected
4 if it’s the first time logging in you connect fine. Not dhcp/ipfw/dns
5 users are reporting that downgrading fixed their issue.
Seems like a ton of technical information right there to me.
- we have over 100 so it’s not isolated
-
Still nothing actionable. What did you contribute to a better understanding of the issue?
-
@MTNet said in Pfsense, No internet when it is said "You are connected".:
Seems like a ton of technical information right there to me.
Actually ZERO of it!!
-
Well, we're talking about the "You are connected" bug, so, the why and what is known for months now.
There was a solution, actually two solutions available as patches, one was abandoned and the remaining one isn't compatible with 2.4.4-p3 at the moment.
https://github.com/pfsense/pfsense/pull/4042 - see the bottom.A initial work around works well, though :
Do not edit portal settings when users are connected.
Or
If you have to edit portal settings , just hit this button after the edit :
-
That wouldn't be fixed by downgrading pfsense.. According to the redmine all version are affected by this bug.
So he is saying he is editing the CP settings at 100 sites? To cause this?
There is zero "technical" information provided by him..
-
Mmm, editing the captive portal at every site seem unlikely at best.
If that is the case though a better post would have been 'We are seeing the same symptoms described here: https://redmine.pfsense.org/issues/8616'.
You say you have tried 'all of the above', does that mean you tried that patch and it didn't work for you?
Steve
-
^ exactly zero useful info..
If you read his first post from another thread he is running "2.3.4 p1" and can not update, etc..
So he has 100 sites all running 2.3.4 - WTF???
-
@stephenw10 said in Pfsense, No internet when it is said "You are connected".:
you tried that patch and it didn't work for you?
I used one of the patches, the now retired version of @free4, on 2.4.4-p2.
That solved the issue that wasn't really an issue for me. I stopped editing the captive portal config years ago. -
That’s fine then. If you are from Netgate you know who we are and we are not lying about the number of units. If you would like to ASK questions that would help solve this feel free. I’m not going to argue with if enough information was provided.
As said the only difference is updating. And they are updated to the latest.
We are not editing CP.
-
@Gertjan that helped initially then we had users report it again.
-
My point was not that you were lying about the number of units.. Not trying to argue with you... My point is that you have provided ZERO info in trying to help you that is worth anything..
So you updated all of your 2.3.4p1 boxes to 2.4.4p3 and now they have a connected but no internet problem... And you are not editing any captive portal settings when this happens?
And then you roll back to what 2.4.4p1? And your saying you have no issues? Or you rolling them back to 2.3.4?
If your not editing the captive portal then your issue is not related to the current redmine issue being discussed..
I find it difficult to comprehend that someone that has 100 some deployments has no clue how too provide actual useful info the problem they are experiencing.
-
Your first post said you called BS. Sorry but that’s not how we prefer to operate. It puts people that could help in a defensive position and that doesn’t seem to be a good spot to help.
You are still insulting us. Have a good day.
-
@MTNet said in Pfsense, No internet when it is said "You are connected".:
If you are from Netgate you know who we are and we are not lying about the number of units.
Indeed I do and you are not.
So you are seeing something slightly different to what others here have reported though it seems likely to be related.
It's the first time I'm been made aware that this is affecting users when the captive portal has not been changed and re-saved.
Just to be clear do you know what version you first saw this on? It looks like the re-saving issue appeared in 2.4.4. It would not surprise me to find whatever variant you are hitting did also.
Steve
-
Hello everyone,
Let's try to calm down okay?@ohbobva , @MTNet and @jurhein I understand that this problem is very annoying. To this date, you (and everyone having facing this captive portal problem) have 3 options :
- Click on "Disconnect All" every time you reboot your pfSense or edit some captive portal settings
- Install the patch that has been chosen to address this issue. I updated my previous post to provide guidelines on how to install this patch on 2.4.4-p3.
- Downgrade your pfSense to a previous version. This issue is present on all 2.4.X version, 2.3.X are unaffected. Because of the multiple production and security fixes made in 2.4.4 I would not recommend doing this however.
On Netgate side ( @Derelict , @stephenw10 @rbgarga )...would it be possible to merge pull request 4042 quite quickly, if possible ? This PR is ready to be merged, and is resolving a very impacting problem for pfSense's captive portal (as you can see from angry comments on this thread...)
-
I'll poke the devs.
Have you seen this issue outside making changes to the captive portal?
Steve
-
@stephenw10 yes..kind of.
I originally faced the issue as a regular pfSense user. I am part of a network/infra team for an IT university, we are running pfSense captive portal for LAN events. We encountered the issue during one of these events.
Few weeks/month after the event, I tried to reproduce the bug using lab environment/VM (the idea was to check vaguely what caused this issue, was it reproducible?). I created the redmine ticket at that time.
I tried to understand the root cause ("when and what introduced this bug?") only few month later (for those interested, the root cause is explained at the end of this post)
-
Update :
I re applied the patch https://github.com/pfsense/pfsense/pull/4042.diff (this is the "patch ID" I used).
/etc/inc/captiveportal.inc was complaing with one chunck (the 12th one) because in "master" there is a new function :
function captiveportal_reserve_ruleno($ruleno)
so I decides to make a backup of my /etc/inc/captiveportal.inc and and replace it with the master version ( https://raw.githubusercontent.com/pfsense/pfsense/master/src/etc/inc/captiveportal.inc ).Now, the patch applies perfectly well.
Great work !
Again : applied against "2.4.4-p3" with updated (current Master) /etc/inc/captiveportal.inc
-
Ok, great.
@Gertjan I assume you are seeing this fix the issue that locks users out if you edit the captive portal?
@MTNet Can you test this patch to confirm it fixes the variant you're seeing? I'm not sure anyone else is seeing this without editing the config. If anyone else is though please test this patch against 2.4.4p3.
Steve
-
@stephenw10 said in Pfsense, No internet when it is said "You are connected".:
@Gertjan I assume you are seeing this fix the issue that locks users out if you edit the captive portal?
Yep.
It's all here : https://github.com/pfsense/pfsense/pull/4042 ^^@stephenw10 said in Pfsense, No internet when it is said "You are connected".:
I'm not sure anyone else is seeing this without editing the config.
Oh, they will. It's a valid for every captive portal setup.
- Your portal is used.
- You edit the portal config page : ipfw firewall rules are flushed, but database contains still the logged in user.
- You win : you'll see the "You are already logged in" text.
But .... because there are close to none-admins that edit their captive portal settings page after an initial system setup,, the error isn't really known - doesn't show up ...
I could see the error because I actually was looking for it.Btw : I borrowed the latest version /etc/inc/captiveportal.inc from "Master" so I might benefit other pull requests.
-
Right exactly. That patch was proven against p2 to fix the issue after editing. I would expect it to work against p3 also.
The question is; is anyone else, other than @MTNet, seeing this issue without editing the config?
If they are it needs testing against that situation.Steve
