Captive Portal bypass issue

[Gertjan]

@michmoor

The pfSense captive portal, the firewall, doesn't handle MAC "pass" as it does MAC "block".
"pass" MACs are in the frrewall - "block" are not.
But, when the user authenticates, at that moment, it's IP is known, and also it's MAC.
After posting the login and password, this this is done :
https://github.com/pfsense/pfsense/blob/db6dd2d2d288fdd64b9e741db0900c5eb15ba9fb/src/usr/local/captiveportal/index.php#L181

and if the test is 'true', the MAC of that is user is in the blocked list, the message "This MAC address has been blocked" is shown.

Take note : the code I've shown in redmine, still contains the bug : the variable $macfilter is never set to a value like 'true', so that test always fails, so blocked MACs are not blocked.

[michmoor]

@gertjan yep I see what your talking about. Thanks for the detailed input.
Is it resolved in beta?

[Gertjan]

@michmoor said in Captive Portal bypass issue:

Is it resolved in beta?

I'm not sure.

This is github master : https://github.com/pfsense/pfsense/blob/master)/src/usr/local/captiveportal/index.php

That file still has the issue.

[stephenw10]

I can replicate this easily. I set the bug to confirmed: https://redmine.pfsense.org/issues/13747

[michmoor]

@stephenw10 So im confused. I know you tested prior you stated you couldnt replicate but now you can? So its not fixed in 23.01 ?
So my original post was that MACs added to bypass can cross vlans - i can reproduce on my end.
Then it went into MACs on the bypass set to deny are still allowed to access the portal - this is reproducible by you Stephen.
Overall, there seems to be a fault just in general with the MAC bypass ability in the captive portal but it seems this shouldn't be used in prod at the moment unless im not understanding the other details here.

[stephenw10]

I can't reproduce the issue you reported with adding pass MACs.

When I tested that the host passes the portal but is still filtered by the layer3 pf rules on the interface as expected. That was in 23.01 but @Gertjan tested it in 22.05 and also couldn't replicate it.

I can reproduce the issue will add block MAC entries. That appears to do nothing currently in 23.01.

Steve

[marcosm]

Regarding the original issue that we have not been able to reproduce:

So my original post was that MACs added to bypass can cross vlans - i can reproduce on my end.

You can determine what rule created the state that is incorrectly passing the traffic - this should help narrow down the issue. Using the previous screenshots/states as an example:
Find the relevant open state:
pfctl -vvss | grep -A4 '192.168.11.28'

Look at the rule <number> part of the relevant state and check it (e.g. rule is 123):
pfctl -vvsr | grep -A3 '@123'

[michmoor]

@marcosm understood. Will follow up tonight and respond back here.

[michmoor]

@michmoor Well cant reproduce my issue. I truly dont get it. The things i tried tonight.

1. Radius auth as always. MAC bypass with PASS. Unable to browse other vlans. Internet access is fine.
2. Radius auth as always. MAC bypass with block. Still able to sign-in but unable to browse other vlans. Internet access is fine.
3. No auth. MAC bypass with block. Still able to sign-in but unable to browse other vlans. Internet access is fine.

The only significant change made from when the issue was reported to now is that pfblockerNG is set up for bypass for the whole /24 Guest range. I dont think pfblcoker is in anyway related but wanted to be transparent with what changed for the guest vlan.
Other than that, i cant explain why the rules are working now but they were not working before as i shown in the pictures above. I will continue to test with different devices.

[Gertjan]

These two :

@michmoor said in Captive Portal bypass issue:

Radius auth as always. MAC bypass with block. Still able to sign-in but unable to browse other vlans. Internet access is fine.
No auth. MAC bypass with block. Still able to sign-in but unable to browse other vlans. Internet access is fine.

That is the "MAC block" not working issue. You are using 22.05 ?

[michmoor]

@marcosm I will say i am getting these messages in my syslog in abundance now.

login-to-view

Checking the last 30 days it hasnt been as present but a huge uptick since last night testing.

login-to-view

@Gertjan I am on 22.05

[stephenw10]

That is IPv6 traffic hitting the IPv4 Limiters

It's fixed in 23.01: https://redmine.pfsense.org/issues/13290

[michmoor]

@stephenw10 Confirmed. Kicked off a iPhone client on the captive portal and those messages are gone.

[the other]

sorry for being kinda offtopic:
just wanted to say thanks for you guys/girls(?)...
...a) pointing out this "problem"
...b) having a discussion about it
...c) trying to reproduce the issue
...d) helping me getting my peace of mind back

:)
Seriously: thanx for your ongoing support and (my personal opinion) the good work with pfsense so far...hope Santa has you on his list.

[stephenw10]

The MAC address block entries now work as expected with the newly added patch.
https://redmine.pfsense.org/issues/13747#note-11
Please test and let us know.

Steve

[michmoor]

@stephenw10 How do i apply the patch?

https://github.com/pfsense/pfsense/blob/483512b3a3226132b7b249f7ea3e2146d3829c23/src/usr/local/captiveportal/index.php#L181

[marcosm]

You may use the commit ID 7e5dbbfca68179fd29a685363625c810d4da6417 in the System Patches package - see here: https://docs.netgate.com/pfsense/en/latest/development/system-patches.html

[stephenw10]

Just add the commit ID in the patches package:

login-to-view

7e5dbbfca68179fd29a685363625c810d4da6417

[michmoor]

@stephenw10 @marcosm
Thanks gents. I couldnt find the commitID.
I can confirm that this is fixed. The mac addresses not only cannot get on the network but there is a message indicating to the client that they are blocked.

Also syslogs confirms block

login-to-view

I really dont know what to say but this has been a journey in troubleshooting and talking to the netgate team. Truly appreciate it.

Time to whip out the old wallet for that TAC sub

[Gertjan]

@michmoor said in Captive Portal bypass issue:

talking to the netgate team

Euh .... the solution was already on the forum.
13747 went from Not a bug, to Duplicate, to Bug again to get solved. I guess it's a question of finding the right words when writing feedback.

The official patch, as always, is much nicer : why adding a line if removing something does the job

And be careful : https://redmine.pfsense.org/issues/13784 was added on the fly : A MAC can (23.01) be blocked the soft way, the user will see the message that his MAC is blocked. You can chose bewteen an error message, or a MAC block portal page to be uploaded. See here for info and example how to implement that.
Or : new, see 13784 : totally rejected : the MAC becomes part of the pf rules that block any interaction with the captive portal interface. I guess the user would be able to get a DHCP lease sorted out, and that's it, nothing more.