Strange (occasional) malfunction on captive portal and mac address whitelist

Luca De Andreis

Hello everyone,
I use two PfSens 24.11 (with all additional patches installed) in HA configuration.
A problem has been occurring on the captive portal for some time, but it is occasional and not methodical (and I don't understand the trigger).
Premise: I use the captive portal in voucher mode without external authentication radius.
If I white list mac address in the captive portal on a new PC, everything works perfectly.
As time went on, I realised that.... (and the same happened a little while ago) occasionally a PC in the whitelist mac address would log in, not allowing it access to the WAN (no authentication nor voucher request, simply.... isolated PC).
If I go into the configuration of the whitelist mac address of the captive portal, display the rule with the correct MAC (always that one) and click Save, without making any useful changes, it works perfectly again

Repeat.... the problem appears occasionally and apparently without any logical sense (the same whitelist rule worked correctly yesterday, today I had to apply this "workaround").

Thanks

Luca

Gertjan

@Luca-De-Andreis

You use a HA setup - and vouchers.
I do use the captive portal with the user/password mode. I'm not using the portal myself a lot, and the ones who do are hotel clients. The connection is 'free' (if it works) and also 'free' if it doesn't, so there I don't receive lot a feedback.

That said, I can only offer you what I know.

What gets logged when the user - who use the connection before, and who's voucher isn't timed out yet - tries to connect again ?
Is he using the same Wifi AP ? Another ne ? Was he using another IP ? or, because another SSID, another MAC (also) ?

occasionally a PC in the whitelist mac address would log in, not allowing it access to the WAN

You mean : it's MAC listed here :

but the user (= device) still gets blocked ?

Norlmally, you should be able to use

pfSsh.php playback pfanchordrill

see here : Troubleshooting Captive Portal.
but the interesting parts are not show ( ?? ) :

[25.03-BETA][root@pfSense.bhf.tld]/etc/phpshellsessions: pfSsh.php playback pfanchordrill

cpzoneid_2_allowedhosts rules/nat contents:

hostname_0 rules/nat contents:
pfctl: DIOCGETRULES: Invalid argument
pfctl: DIOCGETRULES: Invalid argument

which stops somewhat me from proposing you '25.03 Beta' which works fine for me btw (and has less issues / bugs).

Thee "DIOCGETRULES" aren't a good sign ..... pfanchordrill => pfctl => ome low level pf thing is broken again ... Not sure if this is related, though.

edit :

[25.03-BETA][root@pfSense.bhf.tld]/etc/phpshellsessions: /sbin/pfctl -vsA
  cpzoneid_2_allowedhosts
  hostname_0
pfctl: DIOCGETRULESETS: No such file or directory

Luca De Andreis

@Gertjan

First of all, thank you very much for your reply !!!!

And yes... when the captive portal does not work as it should, a whitelisted MAC address is blocked.

My workaround is simple... I go into the MAC whitelist configuration make a trivial change and click save.

Since then the device is unlocked.
But it happens from time to time (normally the mac address whitelist works) ... normally.

Gertjan

@Luca-De-Andreis said in Strange (occasional) malfunction on captive portal and mac address whitelist:

when the captive portal does not work as it should, a whitelisted MAC address is blocked.

The captive portal, on the pfSense sid, actually doesn't really exist.

It a couple of firewall rules (initially : none) and one final rule, pf's classic behavior : "Block all".
These initial (top) firewall rules are special : these are rules that contain tables that can contain IP and or MAC addresses.

When network devices are :
connect with a username/password (== authenticated)
or
connect and use a voucher code
or
IP is whitelisted
or
MAC is whitelisted

so the IP and or MAC of he devices are added to the 'pass' tables firewall rule.

Not really straight forward, but you can see here : Diagnostics > Limiter Info for every device (logged,in, whitelisted by MAC / IP / host name ) as for every device a 2 direction "pipe" is created. This pipe could be used for individual bandwidth control.

For 'debug' purposes, what works, is this : https://forum.netgate.com/topic/173973/freeradius-and-quotas-doesn-t-work-since-22-05/8?_=1750851234161

So, if you have a logged in user :

then this should produce some info :
[25.03-BETA][root@pfSense.bhf.tld]/root: pfctl -a cpzoneid_2_auth/192.168.2.104_32 -se
ether pass in quick proto 0x0800 from 56:a6:fa:c8:1c:11 l3 from 192.168.2.104 to any tag cpzoneid_2_auth dnpipe 2022
ether pass out quick proto 0x0800 to 56:a6:fa:c8:1c:11 l3 from any to 192.168.2.104 tag cpzoneid_2_auth dnpipe 2023

To see all avaible anchors :

[25.03-BETA][root@pfSense.brit-hotel-fumel.net]/root: pfctl -sA
  cpzoneid_2_allowedhosts
  ipsec
  natearly
  natrules
  openvpn
  tftp-proxy
  userrules
  cpzoneid_2_allowedhosts
  cpzoneid_2_auth
  cpzoneid_2_passthrumac

Note that, for me, cpzoneid_2_allowedhosts exists twice. That can't be good (and most probably not related to your issue *- you don't use 25.03 Beta)

You can now inspect the 'state' of the other anchors, like 'cpzoneid_2_passthrumac' and 'cpzoneid_2_auth'.

I suspect, using simple words ^^ that during firewall reloading a known whitelisted (?) or authorized voucher user gets lost "some how".

Luca De Andreis

@Gertjan

OK, so what can I do?
Do I wait for version 25.03 in the hope that it will have a “better” captive portal function ?

In truth it works “quite” well, the problem, as explained before, is that it behaves (occasionally) incorrectly.

Gertjan

@Luca-De-Andreis said in Strange (occasional) malfunction on captive portal and mac address whitelist:

Do I wait for version 25.03

If you want to wait ....
If you have 10 minutes :
Make a new Boot env.
Boot into it.
Upgrade to 23.03 beta.
Reboot.
Test and tell me if things are better ?

You encounter the slightest issue, Boot-click back in 24.11 land.

That said, I don't think 25.03 (beta) behaves differently.

I was somewhat hoping, that, now you have some CLI commands avaible, you could find when/why the issue happens.
From there, as the problem has been found, acknowledged and can be reproduced at will, a solution will be found and your time and hard work will be part of "25.03".

Still, using HA a,d vouchers, how many are there out there ? You and 10 others ? (and 9 don't even know this forum exist).

Anyway, If I presume that this isn't a HA issue, and that vouchers or user/passwords can be used, I could test this also.
I actually already do so all the time :

I've 5 devices MAC listed : my 5 Unifi APs which are part of the captive portal.
The communicate with a Cliud key gen unfi box, present on my LAN, and this gen gen box generates constantly stats like :

and it doesn't miss one beat .... for nearly a year now.

Not sure if the cloud key gen contacts the APs, or if its the other way around. I know they sync up every xx seconds and that loads of 'analytic' traffic is send :

Luca De Andreis

@Gertjan

I know it's very easy to do this using ZFS snapshots, but on those HA firewalls I have more than 600 users on 18 vlans I don't think it's a good idea to experiment.

For more detail I can say that authentication via AD (by LDAP) on the captive portal and authentication via voucher has always worked perfectly.

The problem is in the MAC address white list which is not "always perfect".

Luca

Gertjan

@Luca-De-Andreis said in Strange (occasional) malfunction on captive portal and mac address whitelist:

I have more than 600 users on 18 vlans I don't think it's a good idea to experiment

Ah .. ok.
Way more serious as my setup - just one interface - one captive portal instance - 5 AP's and that's enough for me.
Do you use several portal instances ?

That said, all my AP equipment uses the MAC list like this :

Luca De Andreis

@Gertjan said in Strange (occasional) malfunction on captive portal and mac address whitelist:

Do you use several portal instances ?

Yes I use two portal instances:

The first one for guest users (MAC white list and vouchers)
The second one use MAC white list and LDAP auth,

Indeed, there have only been reports of problems on the first one and not on the second one (in relation to the MAC white list) but it could be that users use the former much more while the latter is little used except with authentication by LDAP working properly.