Clients can't reconnect after pfsense reboot

Gertjan

@kengo said in Clients can't reconnect after pfsense reboot:

as for my setup, I added all the mac address of my routers/access points to the Mac filter in captive portal, not sure if that helped.

I did the same thing.
Even basic access points could have NTP services (time keeping) or could need updates, so these should be able to communicate with the net.

@kengo said in Clients can't reconnect after pfsense reboot:

upon reboot of the 2.3.2 machine, users need to login again. I think this is the intended behavior

Exact.

@kengo said in Clients can't reconnect after pfsense reboot:

captive portal works flawlessly now and doesn't kick machines off the internet after a period of time.

by default, a captive portal should kick of user after a certain time (hard or soft time out).
Except the ones listed on the MACs / Allowed IP / Allowed host names tabs

ontzuevanhussen

@prophet I have same problem :(

darkblack

I have the exact same problem of OP @kengo which he mentioned in the 1st message. I cannot downgrade now. Is there a fix or workaround? Does setting an hard and idle time out fix the issue? Is there a way we can automatically log all users out of the captive portal every time the firewall reboots? Please advice. Thanks.

prophet

@darkblack to solve problems after reboot i just customized pfSense-rc script to automatically truncate captive portal sqlite3 database.

Still looking for a way to automatically login devices after reboot, but i'm working with Fauxapi and i could be discovering something useful soon.

darkblack

@prophet Thanks a lot for your response. Can you please tell me what piece of code you added and at what position (between which lines), it will be helpful and others who stumble on this rather frustrating issue

prophet

@darkblack

in /etc/pfSense-rc, at the very end just before "exit 0".

sqlite3 /var/db/captiveportalyourname.db <<EOF
DELETE FROM captiveportal;
EOF

Where "yourname" is obviously the name of your captive portal.

Gertjan

Instead of deleting files - and editing pfSense core fils, I prefer to use the API.

Consider this :
Install the Shellcmd package which permit us to execute 'commands' at startup.

Place a file called "captiveportal_disconnect_all.php" in the directory /root

#!/usr/local/bin/php -q
<?php
	/* Disconnect all clients on all captive portal instances */

	require_once("/etc/inc/util.inc");
	require_once("/etc/inc/functions.inc");
	require_once("/etc/inc/captiveportal.inc");

	global $g, $config, $cpzone, $cpzoneid;

	/* Are there any portals  ? */
	if (is_array($config['captiveportal'])) {
		/* For every portal (cpzone), do */
		foreach ($config['captiveportal'] as $cpkey => $cp)
			/* Sanity check */
			if (is_array($config['captiveportal'][$cpkey])) 
				/* Is zone enabled ? */
				if (array_key_exists('enable', $config['captiveportal'][$cpkey])) {
					$cpzone = $cpkey;
					$cpzoneid = $cp['zoneid'];
					captiveportal_disconnect_all();
				}
		log_error("All users disconnected after system start-up");
	}
?>

Add a command in the Shellcmd package :

0_1542297148892_9003a358-315a-4155-805f-139923138a46-image.png
Done.

prophet

@gertjan much better, thanks.
do you have something similar to programmatically login users? given that we already have mac address, last ip, username.

Gertjan

@prophet said in Clients can't reconnect after pfsense reboot:

do you have something similar to programmatically login users? given that we already have mac address, last ip, username.

You were reading my mind

What you're asking for is the other way around : if a database exists with logged in user(s), why not rebuilding the ipfw rules for them ?!
Right ?

I guess it's possible.
But : it's time out for me right now. I wrote the lines in the post above on a live system, throwning out users and restarting pfSense while testing : people are yelling all around me.
I'll have a shot at it tomorrow.

Basically, it should be a loop that iterates the database, and for every user

function portal_allow($clientip, $clientmac, $username, $password = null, $attributes = null, $pipeno = null, $authmethod = null, $context = 'first') {

should be called (see /etc/inc/captiveportal.inc, around line 2212)

Except that this function does all the work (a lot of work !), and adds the user to the database

Keep in mind : firewall states and stuff like that will be gone.
It should be something that is "voucher compatible", "Radius compatible", etc.

darkblack

Thanks @prophet @Gertjan , will try the shellcmd fix today. Wondering, why this buy isn't fixed yet (officially) if it affects wide scale of users..

Gertjan

@darkblack I'm using the captive portal for years, but yesterday, during testing, I saw for the first time that connected users during a Diagnostics => Reboot are still listed as connected, but the related ipfw firewall rules were gone.
My pfSense never reboots by itself - it has an UPS. I never saw the issue before.
So, for myself, I can't call it an urgent matter. This issue exists only in the latest version or two.

I guess the pfSense authors should wipe the sqlite file during reboot, as @prophet proposed.

darkblack

I understand. But our case is where, the entire office powers down at EOD (UPS, lighting, et al) and powers up the next morning. . So a major headache for us. Eager to try the solution today.

prophet

@gertjan said in Clients can't reconnect after pfsense reboot:

What you're asking for is the other way around : if a database exists with logged in user(s), why not rebuilding the ipfw rules for them ?!
Right ?

Yes sir.
But which firewall rules are created for a succesfully authenticated client?
I notice ipfw creates these rules, output filtered with relevant tables:

--- table(captive_auth_up), set(0) ---
172.17.17.11/32 18:65:90:82:81:c3 2004 181565 12852760 1542305056
--- table(captive_auth_down), set(0) ---
172.17.17.11/32 2005 418527 595361621 1542306032

I tried to manually recreate these but i couldn't figure out how to make mac address based rules in ipfw.
Aren't these rules just doing some traffic shaping? How are they critical to the system?

Thank you

Gertjan

@prophet said in Clients can't reconnect after pfsense reboot:

I tried to manually recreate these but i couldn't figure out how to make mac address based rules in ipfw.

ipfw : you have 2 possibilities : the easy one : the manual. https://www.freebsd.org/cgi/man.cgi?ipfw(8)
How pfSense makes rules is not hard to find : it all in /etc/inc/captiveportal.inc ^^

@prophet said in Clients can't reconnect after pfsense reboot:

I notice ipfw creates these rules, output filtered with relevant tables:
--- table(captive_auth_up), set(0) ---
172.17.17.11/32 18:65:90:82:81:c3 2004 181565 12852760 1542305056
--- table(captive_auth_down), set(0) ---
172.17.17.11/32 2005 418527 595361621 1542306032

Exact.
Here are the details https://www.netgate.com/docs/pfsense/captiveportal/captive-portal-troubleshooting.html

@prophet said in Clients can't reconnect after pfsense reboot:

Aren't these rules just doing some traffic shaping? How are they critical to the system?

Exact. Pipes, (queues ?) are build for every connection.
Because this option exists :
0_1542367388504_884d9813-3b41-4ebc-8e92-d358b5f74fcc-image.png

Pipes exists, wether you use them, or not.
These pipes have to be created when entering the IP's of the client into the two tables myzone_auth_down and myzone_auth_up.

ghinthsh

@prophet said in Clients can't reconnect after pfsense reboot:

Configured everything (I'll use pfsense as captive portal) and everything worked perfectly as captive portal without user authentication (a simple splash screen with login button and no auth is enough for me).

I had PFBox 2.3 and clean installed 2.4.4 and have the same problem i resolved it somehow by setting Idle timeout to 3 to 4 hours and it work like charm.

@Gertjan said in Clients can't reconnect after pfsense reboot:

Instead of deleting files - and editing pfSense core fils, I prefer to use the API.

Consider this :
Install the Shellcmd package which permit us to execute 'commands' at startup.

Place a file called "captiveportal_disconnect_all.php" in the directory /root

#!/usr/local/bin/php -q
<?php
	/* Disconnect all clients on all captive portal instances */

	require_once("/etc/inc/util.inc");
	require_once("/etc/inc/functions.inc");
	require_once("/etc/inc/captiveportal.inc");

	global $g, $config, $cpzone, $cpzoneid;

	/* Are there any portals  ? */
	if (is_array($config['captiveportal'])) {
		/* For every portal (cpzone), do */
		foreach ($config['captiveportal'] as $cpkey => $cp)
			/* Sanity check */
			if (is_array($config['captiveportal'][$cpkey])) 
				/* Is zone enabled ? */
				if (array_key_exists('enable', $config['captiveportal'][$cpkey])) {
					$cpzone = $cpkey;
					$cpzoneid = $cp['zoneid'];
					captiveportal_disconnect_all();
				}
		log_error("All users disconnected after system start-up");
	}
?>

Add a command in the Shellcmd package :

0_1542297148892_9003a358-315a-4155-805f-139923138a46-image.png
Done.

I wanna try @Gertjan API :)

1ntr0v3rt3ch

@gertjan

do we still need this also for pfsense 2.5 sir? I'm using this also for my captive portal in 2.4.4 p3 before with the system patches fix for "You are connected". just recently upgraded to 2.5.

Gertjan

@1ntr0v3rt3ch Why asking the same question again ?

1ntr0v3rt3ch

@gertjan said in Clients can't reconnect after pfsense reboot:

@1ntr0v3rt3ch Why asking the same question again ?

oh! sorry sir! I thought this is different from the patches. my mistake.

didiosn

I thought the same like @1ntr0v3rt3ch , I hoped that 2.5 version, will have all those fixes, but I was wrong, and it was messing with my hardware, so I came back to 2.4.4 p3, with patches ...

Gertjan

@didiosn said in Clients can't reconnect after pfsense reboot:

I hoped that 2.5 version, will have all those fixes

Hoping ?

I'll present you the uther simplicity of open source code.
You can checks things out yourself.
The 2.4.4-p3 (2.4.5) code base is here : https://github.com/pfsense/pfsense/tree/RELENG_2_4_5
The current 2.5.0 is here (I used the Switch branches/tags button) : https://github.com/pfsense/pfsense/tree/RELENG_2_5_0

Based of the "RELENG_2_4_5" version, you will be able to find the patch. The patch that works if it 'finds' 2.4.5 code
This patch, and all the others, are what makes up '2.5.0'.
So, 2.5.0 == 2.4.5 + "all the patches = "2417 commits behind master. " Master = 2.5.0 plus newer patches, what make up the current version, to be released in the future.

If "2.4.5 + patch to resolve "Clients can't reconnect after pfsense reboot" which is actually 2.5.0 does not resolve your issue, your actual issue is something different.

The silly thing is : I can't not easily test if your wrong or right : my pfSense rarely restarts. I do not have to, I do not want to shut it down or reboot : it serves as a company router with connected users, our own systems and out clients. The power stays up, it has even its own UPS ..... so, no issues for me. I advise you to do the same.
I will reboot the system this mornin, with some connected users (myself with some devices) to test if the issue still exist with vanilla "2.5.0".
It shouldn't - as it has the patch.

The test is easy :
This "connected users list" visible in the GUI, after reboot :

6 clients connected.

should look like this list :

[2.5.0-RELEASE][admin@pfsense.local.net]/root:  ipfw table all list
.........
--- table(cpzone1_auth_up), set(0) ---
192.168.2.38/32 74:e5:f9:76:xx:08 0 416726 35157523 1616656367
192.168.2.41/32 00:b5:d0:c6:xx:bb 0 21666 3376893 1616655996
192.168.2.44/32 08:cc:27:fa:xx:e2 0 24971 3309541 1616656369
192.168.2.131/32 6c:96:cf:dc:xx:93 0 165657 13800625 1616656371
192.168.2.178/32 62:7e:05:73:xx:04 0 3235 788929 1616656317
192.168.2.215/32 46:0b:2d:xx:ee:b0 0 391648 31807701 1616656371
.......
--- table(cpzone1_auth_down), set(0) ---
192.168.2.38/32 0 803791 1085868854 1616656367
192.168.2.41/32 0 30903 30311706 1616655996
192.168.2.44/32 0 39878 52533628 1616656354
192.168.2.131/32 0 362751 508494209 1616656371
192.168.2.178/32 0 3342 2165841 1616656317
192.168.2.215/32 0 819045 1150064899 1616656371
.....

== 6 clients connected -> 6 entries for the down traffic and 6 for the up traffic.

The two tables xxxxx_auth_up and xxxxx_auth_down should contain the same IP's as the GUI shows.