Regression #13747
closed
Captive Portal blocked MAC addresses are not blocked
Added by Gertjan KROEB over 1 year ago. Updated over 1 year ago.
100%
Description
See here https://forum.netgate.com/topic/176356/captive-portal-bypass-issue/13
This test : https://github.com/pfsense/pfsense/blob/483512b3a3226132b7b249f7ea3e2146d3829c23/src/usr/local/captiveportal/index.php#L181
uses $macfilter, a variable that is never initialized, so default to 'false'. The elseif will never get executed.
Files
Related issues
Updated by Jim Pingle over 1 year ago
- Status changed from New to Duplicate
Appears to be a duplicate of #13742
Updated by Jim Pingle over 1 year ago
- Related to Bug #13742: Captive Portal MAC bypass - pf rules are not enforced added
Updated by Steve Wheeler over 1 year ago
- Tracker changed from Bug to Regression
- Status changed from Duplicate to Confirmed
- Target version set to 2.7.0
- Plus Target Version set to 23.01
This isn't a duplicate of #13742.
MAC addresses added as block entries are not blocked. Hosts are still redirected to the login page and can login and that pass the captive portal.
The MAC address added do not appear either in the captive portal anchors or in the main ruleset. Nor does it prevent the host traffic being redirected.
<passthrumac>
<action>block</action>
<mac>00:1e:33:a8:6d:7d</mac>
<descr><![CDATA[Test block]]></descr>
</passthrumac>
[23.01-BETA][admin@1100.stevew.lan]/root: pfctl -vse ether pass on mvneta0.4091 l3 all tag cpzoneid_2_rdr [ Evaluations: 898705 Packets: 74015 Bytes: 73119884 ] ether anchor "cpzoneid_2_auth/*" on mvneta0.4091 l3 all [ Evaluations: 286490 Packets: 0 Bytes: 0 ] ether anchor "cpzoneid_2_passthrumac/*" on mvneta0.4091 l3 all [ Evaluations: 74015 Packets: 0 Bytes: 0 ] ether anchor "cpzoneid_2_allowedhosts/*" on mvneta0.4091 l3 all [ Evaluations: 74015 Packets: 0 Bytes: 0 ] [23.01-BETA][admin@1100.stevew.lan]/root: pfSsh.php playback pfanchordrill ipsec rules/nat contents: natearly rules/nat contents: natrules rules/nat contents: openvpn rules/nat contents: tftp-proxy rules/nat contents: userrules rules/nat contents: cpzoneid_2_allowedhosts rules/nat contents: cpzoneid_2_auth rules/nat contents: cpzoneid_2_auth/192.168.201.10_32 rules/nat contents: ether pass in quick proto 0x0800 from 00:1e:33:a8:6d:7d l3 from 192.168.201.10 to any tag cpzoneid_2_auth dnpipe 2000 ether pass out quick proto 0x0800 to 00:1e:33:a8:6d:7d l3 from any to 192.168.201.10 tag cpzoneid_2_auth dnpipe 2001 cpzoneid_2_passthrumac rules/nat contents:
Tested: 23.01.b.20221217.1429
Updated by Marcos M over 1 year ago
- Status changed from Confirmed to In Progress
Updated by Marcos M over 1 year ago
- Subject changed from Captive portal : MACs listed as blocked are not blocked. to Captive Portal blocked MAC addresses are not blocked.
- Status changed from In Progress to Pull Request Review
- Affected Version changed from All to 2.7.0
This regression was introduced in 22.05. Fix:
https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/990
Previously, MAC addresses weren't actually blocked in pf, but rather they were prevented from authenticating via the Captive Portal login page. This allowed "blocked" clients to still access DNS, NTP, and any other services on the firewall itself. Now that pf has the capability to block at L2, this can be improved. With this MR, block rules are added to completely block the address (excluding DHCP since DHCP bypasses pf).
[23.01-BETA][root@gw]/root: pfSsh.php playback pfanchordrill ipsec rules/nat contents: miniupnpd rules/nat contents: natearly rules/nat contents: natrules rules/nat contents: openvpn rules/nat contents: tftp-proxy rules/nat contents: userrules rules/nat contents: cpzoneid_2_allowedhosts rules/nat contents: cpzoneid_2_auth rules/nat contents: cpzoneid_2_passthrumac rules/nat contents: cpzoneid_2_passthrumac/1491823bc048 rules/nat contents: ether block in quick from 14:91:82:3b:c0:48 l3 all ether block out quick to 14:91:82:3b:c0:48 l3 all
Updated by Gertjan KROEB over 1 year ago
Previously, ....
But is that they way to block ?
'Hard MAC blocking' with pf firewall rules, now possible, is an new possibility, and needs more GUI control.
It will disturb the end-user as when she/he could connect to the portal network : DHCP still works, but nothing more will happen on the device used. This will bring confusing.
In the past, if the user uses a MAC that is listed as block ed, passes authentication, she/he is informed what happened as the error message gets set to "This MAC address has been blocked".
Right now, it's just a silly bug, a variable is used in the elseif that is never set, the elseif always yields false, this is what broke current MAC block behavior.
See /usr/local/captiveportal/index.php line 181 and ask yourself : where is $macfilter" set ? No where !
Updated by Marcos M over 1 year ago
Good feedback - I fixed the regression and kept the old behavior. The new blocking functionality will be a new optional feature on a separate redmine issue: https://redmine.pfsense.org/issues/13784
Updated by Marcos M over 1 year ago
- Has duplicate Regression #13490: blocking mac addresses in captive portal added
Updated by Jim Pingle over 1 year ago
- Subject changed from Captive Portal blocked MAC addresses are not blocked. to Captive Portal blocked MAC addresses are not blocked
Updated by Marcos M over 1 year ago
- Status changed from Pull Request Review to Feedback
- % Done changed from 0 to 100
Applied in changeset 7e5dbbfca68179fd29a685363625c810d4da6417.