Bug #13742
closed
Captive Portal MAC bypass - pf rules are not enforced
0%
Description
I am able to bypass all firewall rules for an Interface that has Captive Portal enabled using MAC or IP bypass.
This is reproducible with any client. If a MAC address is added to the bypass list the client can bypass radius authentication that is configured for the Captive Portal zone as expected. The same client is then able to navigate to any VLAN although firewall rules should prevent that client from doing so. A firewall state is created.
- If MAC/IP bypass is NOT used and instead the client is forced to log-in through the portal which uses Radius, Firewall rules are enforced and client traffic is rejected from flowing between interfaces.**
Additional details are found in my post
https://forum.netgate.com/topic/176356/captive-portal-bypass-issue/12
Related issues
Updated by Kris Phillips almost 2 years ago
I tested this in Dec 10th build of 23.01 pfSense Plus and was unable to reproduce this. I did the following:
1. Created a Captive Portal on LAN1 with a subnet of 192.168.1.0/24 and an interface called LAN2 with 192.168.2.0/24.
2. Created a firewall deny rule for LAN1 subnet to LAN2 subnet.
3. Connected a desktop to the LAN1 segment, verified that it was getting the captive portal, and then added it to the MAC bypass list
4. I verified I was able to get on the internet without signing in. Pinging the LAN2 interface IP of 192.168.2.1 produced no response or states
I would test this on the latest DEV builds of 23.01 as I suspect this was already fixed in the several other CP bugs that have been squashed between 22.05 and 23.01.
Updated by Mike Moore almost 2 years ago
Can you help me diagnose this then because im really not understanding how this is currently possible?
I cant use any DEVL image now as i dont have another netgate 6100 to test on.
There has to be some condition that is being met from what im doing that is making this possible. I am creating firewall state and accessing LAN networks from an Interface that has a deny all rule
Updated by Mike Moore almost 2 years ago
Ive noticed that there are anchor rules that do not apply as there is no MAC bypass available. Its as if the config is not cleaning itself up. Is it safe to delete these manually in a text editor?
cpzoneid_2_auth/192.168.11.23_32 rules/nat contents:
ether pass in quick proto 0x0800 from 70:31:7f:cf:a5:11 l3 from 192.168.11.23 to any tag cpzoneid_2_auth dnpipe 2000
ether pass out quick proto 0x0800 to 70:31:7f:cf:a5:11 l3 from any to 192.168.11.23 tag cpzoneid_2_auth dnpipe 2001
cpzoneid_2_auth/192.168.11.27_32 rules/nat contents:
ether pass in quick proto 0x0800 from 32:13:57:3c:c5:6c l3 from 192.168.11.27 to any tag cpzoneid_2_auth dnpipe 2000
ether pass out quick proto 0x0800 to 32:13:57:3c:c5:6c l3 from any to 192.168.11.27 tag cpzoneid_2_auth dnpipe 2001
Updated by Jim Pingle almost 2 years ago
- Project changed from pfSense Plus to pfSense
- Category changed from Captive Portal to Captive Portal
- Target version set to 2.7.0
- Affected Plus Version deleted (
22.05) - Plus Target Version set to 23.01
Updated by Jim Pingle almost 2 years ago
- Related to Regression #13747: Captive Portal blocked MAC addresses are not blocked added
Updated by Marcos M almost 2 years ago
- Status changed from New to Not a Bug
I was unable to reproduce the reported issue on the latest snap - the client with the bypass MAC correctly bypasses RADIUS authentication and the traffic is filtered by the corresponding interface's rules.
FYI Those rules are generated dynamically, hence deleting them from that file won't do anything (also editing that file wouldn't affect the currently loaded rules anyway). For now, I recommend following up on the forums if needed.