Captive Portal Pass-through MAC Auto Entry is registering unauthenticated users

darnoldvcs

Hello NetGate Community,

I am attempting to setup a Guest Portal that allows:

Guests to connect to the WiFi for a limited time (e.g. 1hr) without credentials.
Allow Staff personal devices to connect for extended periods after they authenticate with their AD credentials (RADIUS/MS-NPAS).

I have tried a number of configurations, but the solution that appears to suite is to set Pass-through credits allowed per MAC address to a fixed period (1hr) with Pass-through MAC Auto Entry/automatic additions enabled. My understanding is this should allow a device to connect unauthenticated for up-to the defined period, and then redirected to the portal login page. Once successfully logged in from the portal page, the user's device MAC will be added to the Captive Portal MAC Address table and they will not need to authenticate again.

What actually happens is a MAC Table entry is created immediately after a device connects to the Guest WiFi (user has not authenticated), and the user is never redirected to the portal login page (as they have a MAC table entry). Please attached images showing an auto added mac table entry for an unauthenticated user.

Has anyone successfully configured Pass-through MAC Auto Entry/automatic additions in this manner and/or could suggest any configuration changes I should make?

Here's a high level overview of the Captive Portal setup:

Hard Timeout: 1
Pass-through credits per MAC address: 1
Waiting period to restore pass-through credits. (Hours): 1
Pass-through MAC Auto Entry: Checked/Enabled
Authentication: Use authentication backend -> RADIUS/MS-NPAS
Custom portal login page (tested an working with standard RADIUS auth portal)
No RADIUS MAC authentication and No Logout window

I have tested this on 22.05 & 23.01.

I had also raised a pfSense redmine ticket for this issue, but it hasn't received any comments from the NetGAte team yet.

Auto Added MAC Pass 8a.png Unauthenticated Guest Client 8a.png

Gertjan

@darnoldvcs said in Captive Portal Pass-through MAC Auto Entry is registering unauthenticated users:

I have tested this on 22.05 & 23.01.

What is / Is there a reason not to test de the current version - 23.05 ?

For good manners : I use 23.05, as it removes issues present in 23.01 ;)

With only this option checked :

@darnoldvcs said in Captive Portal Pass-through MAC Auto Entry is registering unauthenticated users:

Pass-through MAC Auto Entry: Checked/Enabled

I had to identify with valid credentials, and then the MAC was added to the MACs table.

These two :

I have never tested these .
But setting them to "1" both does expose what you've mentioned above.
I still don't know what "Pass-through credits per MAC address" actually is. 1 hour ? or 1 "something" ?

But, I've seen the same thing : with these to set to "1", the MAC address of my device was added right away in the MAC table, granting me indefinite access from that moment.
That behavior doesn't match with the description

When enabled, a MAC passthrough entry is automatically added after the user has successfully authenticated.

edit :

I've been looking around in the documentation.

In the captive portal /usr/local/captiveportal/index.php file, around line 192 :

The function "portal_consume_passthrough_credit($clientmac)" return 'true' if these 2 :

are set (bigger then 0).

The if statement is true, so a log line is add to the captive portal log :

captiveportal_logportalauth("unauthenticated", $clientmac, $clientip, "ACCEPT");

which means a user with MAC '$clientmac' and "unauthenticated" is added.
Like :

and then the mighty portal_allow( ....... ) is called.
This isn't a real login, an "unauthenticated", is more a "temporarily accepted auto login".
Nevertheless, because this is a new session, and "passthrumacadd" is set/checked (around line 2075 /etc/inc/captiveportal.inc) is now unconditionally added.

Easy way out : these options are somewhat 'mutually exclusive'.

The thing is : the captive portal logistics is ..... messy (I'm still looking for a better word) or somewhat what could be called as 'spaghetti code'.
The main settings page makes the portal admin think that all kind of option can me used together.
This is a typical case of : no way.

edit :

Change /etc/inc/captiveportal.inc : https://github.com/pfsense/pfsense/blob/5e92d678f642277642acb7f471cd430ed53aae16/src/etc/inc/captiveportal.inc#L2075

I tried to play with :

	if (isset($config['captiveportal'][$cpzone]['passthrumacadd']) &&
		empty($config['captiveportal'][$cpzone]['freelogins_count']) &&
		empty($config['captiveportal'][$cpzone]['freelogins_resettimeout'])) {

which stands for
If ("passthrumacadd" == checked) and
both 'freelogins_count' and 'freelogins_resettimeout' are not set,
then do the MAC add passtrough.
But this was not a solution.

There need to be a test to see if the MAC in case is in the grace ( freelogins_resettimeout ) period.
This could be done by checking /var/db/captiveportal_usedmacs_cpzone1.db (cpzone1 is my captive portal zone name) ...

My first advise still stands : @darnoldvcs please keep it simple(r).
If possible, ditch the "passthrumacadd" option - and say sorry to your visitors : after a while (hard reset or IP change) : they have to login again.
If these people are really, or more or less trusted users : give them another, more trusted network that doesn't use the captive portal.