Captive Portal bypass issue
-
The concern here though is if clients that are added to he MAC bypass list are then not filtered the the firewall rules on the interface the captive portal is active on.
Obviously that shouldn't happen but I could potentially see how it could have been introduced by moving from two separate packet filters to everything in pf.Stevce
-
@stephenw10 exactly the point I was attempting to illustrate. There’s two issues at play with me. 1. MAC bypass just simply doesn’t work. There’s a fix for it as pointed out above. 2. MACs or IPs in the bypass list has full access to other networks bypassing firewall rules. As I demonstrated there is state being created. This is reproducible for me.
The fix for both issues is making sure that the client signs in on the portal and is not in either the MAC or IP bypass list. -
Have you tested this in 23.01? I can't replicate it there in todays snapshot. Traffic is passed by the CP from the allowed MAC but still subject to the firewall rules on the interface.
Steve
-
@stephenw10 is it “stable” enough to treat one of my spoke sites as a test?
-
Well I'm running it everywhere now and not seeing any issues. It's still hard to recommend you run it in production though.
If you're able to test a config that's known to be giving problems in 22.05 in a test environment I would certainly do that first. -
@stephenw10 said in Captive Portal bypass issue:
The concern here though is if clients that are added to he MAC bypass list are then not filtered the the firewall rules on the interface the captive portal is active on.
If you're able to test a config that's known to be giving problems in 22.05 in a test environment I would certainly do that first.
Not filtered ?
That's known to be giving problems ?I really like to understand.
What am I doing wrong here :I've a LAN, it's the pfSense default 192.168.1.24/24 - this LAN contains all our printers, PCs and servers, a NAS, a DVR, several APs so our own phones and PC's can access it over Wifi, airco system, impatient terminals, everything that a company need to function.
I've a captive portal on a seperate, 192.168.2.1/24 - with, of course, 4 AP's as its wired structure. The DHCP portal pool is 192.168.2.10->192.168.2.254.
I enter the MAC of my iPhone on the MAC list as a pass :
I've connected my iPhone to the captive portal.
Let's double check the MAC : 14:c2:13:c9:1e:77
and I also see the iPhone IP : 192.168.2.168.
My iPhone has an app that I can use to access my DVR on LAN where it uses 192.168.1.8.
This app works fine when I connect my iPhone to an AP present on the LAN interface, pfSEnse doesn't come into play here.
The app also works fine when I connect my iPhone to pfSense WAN using the OpenVPN (192.168.3.1/24 network) server.But : according from what I understand, I should be able to connect to any LAN devices on (192.168.1.1/24) because of my iPhone is on the MAC pass list ?
My firewall logs says different :
Where 192.168.2.168 is my iPhone, connected to the captive portal network.
192.168.1.8 is the DVR on LAN, port 37777 is de DVR app port.The blocking firewall rule, on the captive portal is the one before last here here called "LAN Block" :
Really, my mind is set to see this issue.
My test is wrong ?Again :
LAN and captive portal are different networks / different NICs.I'm using 22.05
Basically, I'm doing what Kris Phillips did here : https://redmine.pfsense.org/issues/13742 but again, on 22.05
-
Nope your test looks correct as I understand the suspected issue. I couldn't replicate it either, though I only tested in 23.01.
Do you see the ether pass rules for that MAC created when you add it?
There were also reports of changes to the pass MAC table not being applied without restarting the CP. I saw no issue in 23.01 though.
Steve
-
@stephenw10 said in Captive Portal bypass issue:
Do you see the ether pass rules for that MAC created when you add it?
Yes, a "MAC pass" entry :
Gives me :
[22.05-RELEASE][admin@pfSense.home.net]/var/unbound: pfSsh.php playback pfanchordrill ...... cpzoneid_2_passthrumac rules/nat contents: cpzoneid_2_passthrumac/001122334455 rules/nat contents: ether pass in quick from 00:11:22:33:44:55 l3 all tag cpzoneid_2_auth dnpipe 2010 ether pass out quick to 00:11:22:33:44:55 l3 all tag cpzoneid_2_auth dnpipe 2011Btw :
@stephenw10 said in Captive Portal bypass issue:
There were also reports of changes to the pass MAC table not being applied without restarting the CP. I saw no issue in 23.01 though.
I'm using 22.05 'stock'.
When I edit the MAC pass list : see the image above 00:11:22:33:44:55 to 55.44.33.22.11.00, and then I execute a pfSsh.php playback pfanchordrill :cpzoneid_2_passthrumac/554433221100 rules/nat contents: ether pass in quick from 55:44:33:22:11:00 l3 all tag cpzoneid_2_auth dnpipe 2010 ether pass out quick to 55:44:33:22:11:00 l3 all tag cpzoneid_2_auth dnpipe 2011which is correct : the rule got modified.
The anchor cpzoneid_2_passthrumac/001122334455 became cpzoneid_2_passthrumac/554433221100.
I did not restart or disable and then re enable the captive portal. Just a "Save" on the MAC edit page. -
@gertjan @stephenw10 I will be trying this out on the BETA release to see if the issues are fixed.
For now, im able to block the MACs at least on the switch level. That prevents the device from hitting the captive portal. -
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#L181and 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.
-
@gertjan yep I see what your talking about. Thanks for the detailed input.
Is it resolved in beta? -
@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.
-
I can replicate this easily. I set the bug to confirmed: https://redmine.pfsense.org/issues/13747
-
@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. -
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
-
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' -
@marcosm understood. Will follow up tonight and respond back here.
-
@michmoor Well cant reproduce my issue. I truly dont get it. The things i tried tonight.
- Radius auth as always. MAC bypass with PASS. Unable to browse other vlans. Internet access is fine.
- 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.
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. -
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 ?
-
