Regression #13747: Captive Portal blocked MAC addresses are not blocked - pfSense - pfSense bugtracker

Actions

Copy link

Regression #13747

closed

Captive Portal blocked MAC addresses are not blocked

Added by Gertjan KROEB about 2 years ago. Updated about 2 years ago.

Status:

Resolved

Priority:

Normal

Assignee:

Marcos M

Category:

Captive Portal

Target version:

2.7.0

Start date:

Due date:

% Done:

100%

Estimated time:

Plus Target Version:

23.01

Release Notes:

Default

Affected Version:

2.7.0

Affected Architecture:

All

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

captive_portal_blocked.png (143 KB) captive_portal_blocked.png

Steve Wheeler, 12/20/2022 02:40 PM

Related issues

Actions

Copy link

Updated by Jim Pingle about 2 years ago

Status changed from New to Duplicate

Appears to be a duplicate of #13742

Actions

Copy link

Updated by Jim Pingle about 2 years ago

Related to Bug #13742: Captive Portal MAC bypass - pf rules are not enforced added

Actions

Copy link

Updated by Steve Wheeler about 2 years 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

Actions

Copy link

Updated by Marcos M about 2 years ago

Assignee set to Marcos M

Actions

Copy link

Updated by Marcos M about 2 years ago

Status changed from Confirmed to In Progress

Actions

Copy link

Updated by Marcos M about 2 years 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

Actions

Copy link

Updated by Gertjan KROEB about 2 years 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 !

Actions

Copy link

Updated by Marcos M about 2 years 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

Actions

Copy link