Pfsense, No internet when it is said "You are connected".

andresense

Sorry for the delay in replying

I solved the problem in another way. I created a script that inserted users back into the portal at boot time.

Thanks for the feedback

michaeleino

So, as this issue becomes a nightmare for us and wasn't fixing by any patch :(

now, what the case with 2.4.5 ? I can hit the same issue after every reboot.
I can't apply the patch to 2.4.5, and not sure what to do now to keep using the pfsense CP !!

Any help please?
Thanks

stephenw10

Try: https://github.com/pfsense/pfsense/compare/RELENG_2_4_5...Augustin-FL:fix-reconfig-for-2-4-4.diff

That will apply against 2.4.5 and looks exactly the same patch. I have no way to test it here though right now.

Steve

Gertjan

@stephenw10 said in Pfsense, No internet when it is said "You are connected".:

Try: https://github.com/pfsense/pfsense/compare/RELENG_2_4_5...Augustin-FL:fix-reconfig-for-2-4-4.diff

That will apply against 2.4.5 and looks exactly the same patch. I have no way to test it here though right now.

Steve

I'm still using this patch as of today - now running 2.4.5. - it auto applied itself right after updating.
The patch applies well because the files changed by the patch were not modified since 2.4.4-p3.

@michaeleino said in Pfsense, No internet when it is said "You are connected".:

I can't apply the patch to 2.4.5,

Make sure the original files (edit : 2.4.4-p3 or 2.4.5) are in place.

@michaeleino said in Pfsense, No internet when it is said "You are connected".:

and not sure what to do now to keep using the pfsense CP !!

Don't forget the most easy solution : don't edit portal settings while users are connected.
And if you have to edit settings, disconnect them all right afterwards.

michaeleino

well,
thanks Steve, Gertjan
now I can patch 2.4.5,
Now should I change any settings in the CP ?
as after each reboot, I still hit the "You are connected" :(

@Gertjan said in Pfsense, No internet when it is said "You are connected".:

Don't forget the most easy solution : don't edit portal settings while users are connected.
And if you have to edit settings, disconnect them all right afterwards.

the issue doesn't happen if i modify the CP configuration... it happens after every reboot.

Gertjan

@michaeleino said in Pfsense, No internet when it is said "You are connected".:

as after each reboot, I still hit the "You are connected" :(

The patch enforces that the database with connected users is deleted at boot time.
The related pipe-rule list is also deleted.
See /etc/inc/system.inc - lines 21345-2137 after the patch is applied.

The GUI Status > Captive Portal > YOURZONE should be empty after a pfSense rebooting.
Right ?

Now, you enter a user on the portal.
You are connected - right ? The user shows up in the GUI Status > Captive Portal > YOURZONE, right ?
Is that the moment you see You are connected", right after identification ?

michaeleino

Hello, i was just unable to reboot the firewall since last time :)
the issue has been magically gone, the captive portal status page is empty after reboot, so the users is able to re-authenticate again.

Hope this patch be included in the next release!
Thanks all

michaeleino

Hi All!
got the magic...
reboot/halt from pfsense GUI is OK,
The GUI Status > Captive Portal > ZONE is empty after a pfSense rebooting.

but reboot/shutdown from acpi is NOT OK
The GUI Status > Captive Portal > Old auth sessions are still there... very weird, as acpi should trigger the same runtime cycle!

VM hosted on bhyve/freenas 11.3U2.1
Virtual CPUs:8
Memory Size:8.00 GiB
Boot Loader Type:UEFI
System Clock:UTC

the issue originally, when we suffer a power outage and the UPS will not survive anymore, the Host OS is doing a clean shutdown for VMs then to itself, and after power return everything should come back again...
except this captive portal :(

any help ? Does it clean sessions on startup or shutoff ?

Gertjan

@michaeleino said in Pfsense, No internet when it is said "You are connected".:

the Host OS is doing a clean shutdown for VMs then to itself,

The question is : is it halting ?

See /etc/inc/system.inc - aroujd lin e2094 : on system_halt() system_reboot_cleanup() is called.
An that function, a couple of line further bellow, will delete the portal session database(s).

It plays also the shutdown notification sound

	mwexec("/usr/local/bin/beep.sh stop");

If the host puts the VM in some sort of suspended or sleep mode, all this might no happen.
Check the logs if it really shuts down.

Put a log line in the function system_reboot_cleanup() so you can check if it is reached, if the database is wiped, etc.

michaeleino

Hi all!
I have tried to add echo message inside each function, to see it while execution .. but i can't see them on any shutdown procedure neither "acpi" nor "pfsense halt"
for ex:

function system_halt() {
        global $g;
        echo "Hey, This is a system halting process";
        system_reboot_cleanup();
 
        mwexec("/usr/bin/nohup /etc/rc.halt > /dev/null 2>&1 &");
}

should I redirect it to console like this or what?

>/dev/console

something to note, "acpi" or "pfsense halt" is showing this on the console:
Screenshot from 2020-05-02 19-35-29.png

and pfsense is starting cleanly after both shutdowns ... can we execute this cleanup during Bootup ? is it better idea ?

Gertjan

The several shutdown functions that exist in /etc/system.inc have to be called for pfSense maintenance purposes.

I tend to say : redo your ACPI (bios ?) settings.

michaeleino

Can't get your message :(
I'm using the UEFI boot loader, what BIOS should I check ?

I have other virtual machines like ubuntu/windows, they are going to perform soft shutdown normally.

chanrio13

@andresense

can you share a script on how to do this on boot time? been seeing this issue in the past 4 releases of pf and it seems its not gonna be included in the next release at all but a patch.

andresense

@chanrio13

dude i don't know if the solution i made will work for you

What I did was check if the user's mac address is in the database and on the firewall, if it is only in the database, I remove it from the database
and the captive is shown to him again

this is for you?

Novacom

Hello !

I'm trying to understand this issue I have with captive portal users being left stuck in "you're connected" after a pfSense reboot. Clearly this have been an issue for which patches have been made until 2.5 arrives (master).

@stephenw10 said in Pfsense, No internet when it is said "You are connected".:

https://github.com/pfsense/pfsense/compare/RELENG_2_4_5...Augustin-FL:fix-reconfig-for-2-4-4.diff

The patch does not seems to download anymore.

Here are some info and what I tried :

I'm on 2.4.5-RELEASE-p1
I did not change the Captive Portal config after initial reboot.
Log into Portal, browse fine, all OK, reboot pfSense, "you're connected" but in fact firewalled.
https://github.com/pfsense/pfsense/pull/4042.diff Fetches but do not apply (fails at line 1954)
https://github.com/pfsense/pfsense/compare/RELENG_2_4_4...Augustin-FL:fix-reconfig-for-2-4-4.diff does not fetch
https://github.com/pfsense/pfsense/compare/RELENG_2_4_5...Augustin-FL:fix-reconfig-for-2-4-4.diff does not fetch
@andresense's script could fix it quickly for me, as I could live with removing connected users at reboot but as I digged through the rabbit hole of this thread, the patch does this.

Thank you for any pointers for me...

Gertjan

Hummmm.

I'm using 2.4.5-RELEASE-p1 myself, and I guess w"re back at the beginning.

When editing the Services > Captive Portal, the ipfw tables that contain the authorized users is reset / emptied.
The connected user database isn't purge.
Where back where we started last year.

https://github.com/pfsense/pfsense/compare/RELENG_2_4_4...Augustin-FL:fix-reconfig-for-2-4-4.diff might have been useful - again, but is probably not 'clean' to patch automatically (code base changed).

Well ... what about the initial solution :

If you have users connected, do not edit the portal settings.
If you have to edit, disconnect connected users right after you hit the blue Save button.

It's probably time to re open the (a) bug report at pfSense-redmine.

edit : a reboot : same scenario : no firewall rules, and the connected users data base stays intact. Great.

edit 2 : I get it. @Novacom - patches were applied ... against 2.50.

free4

@Novacom hi,

I am the one who made this patch. I deleted it but I guess I can restore it

Would you like me to restore it?

Tenshou

Can you restore this patch?
This bug still exists in 2.4.5 -p1.

The same "You Are Connected" message. The only way to fix this is to disconnect all users and they need to sign in again.

This issue is marked as resolved but it is definitely not resolved.

"Here are some info and what I tried :

I'm on 2.4.5-RELEASE-p1
I did not change the Captive Portal config after initial reboot.
Log into Portal, browse fine, all OK, reboot pfSense, "you're connected" but in fact firewalled.
https://github.com/pfsense/pfsense/pull/4042.diff Fetches but do not apply (fails at line 1954)
https://github.com/pfsense/pfsense/compare/RELENG_2_4_4...Augustin-FL:fix-reconfig-for-2-4-4.diff does not fetch
https://github.com/pfsense/pfsense/compare/RELENG_2_4_5...Augustin-FL:fix-reconfig-for-2-4-4.diff does not fetch
@andresense's script could fix it quickly for me, as I could live with removing connected users at reboot but as I digged through the rabbit hole of this thread, the patch does this."

Same thing is happening to me. This is definitely not resolved.

Gertjan

@Tenshou said in Pfsense, No internet when it is said "You are connected".:

This bug still exists in 2.4.5 -p1.

Yep.
The patch was integrated in 2.5.0-dev, the version that comes out .... later.

Novacom

Sorry for the delay, I somehow was made aware of replies only this morning...

@free4 Yes I think the patch against current versions could mitigate the issue.

The issue was becoming less urgent since my client dropped the idea of using captive portal. Still, I think we must have a way to fix the issue while waiting 2.5.0 to get current. Reboots might be more frequents in some installations and manual interventions (flush database) should be limited.

Thanks