Captive Portal bypass issue

Gertjan

I start with 3 pass entries :

'anchordrill' tells me :

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 2000
ether pass out quick to 00:11:22:33:44:55 l3 all tag cpzoneid_2_auth dnpipe 2001

cpzoneid_2_passthrumac/5a50915fec65 rules/nat contents:
ether pass in quick from 5a:50:91:5f:ec:65 l3 all tag cpzoneid_2_auth dnpipe 2014
ether pass out quick to 5a:50:91:5f:ec:65 l3 all tag cpzoneid_2_auth dnpipe 2015

cpzoneid_2_passthrumac/d235342eb039 rules/nat contents:
ether pass in quick from d2:35:34:2e:b0:39 l3 all tag cpzoneid_2_auth dnpipe 2018
ether pass out quick to d2:35:34:2e:b0:39 l3 all tag cpzoneid_2_auth dnpipe 2019

so there is correspondence.

When I change the first MAC entry from pass to block, the first thing I notice is that that MAC address isn't listed no where anymore in the "anchor drill".
That's ok, as the mac blocke devcies still can reach the portal login page, but after login, they receive a informative message :

"This MAC address has been blocked"

Btw : found an error, also called bug.
You will not receive that message, and devices are not blocked based on their MAC.
Have a look at /usr/local/captiveportal/index.html
and locate } elseif (($_POST['accept'] || $cpcfg['auth_method'] === 'radmac' || !empty($cpcfg['blockedmacsurl'])) && $macfilter && $clientmac && captiveportal_blocked_mac($clientmac)) {

You'll find it in this line :

} elseif (($_POST['accept'] || $cpcfg['auth_method'] === 'radmac' || !empty($cpcfg['blockedmacsurl'])) && $macfilter && $clientmac && captiveportal_blocked_mac($clientmac)) {

and that's the only occurrence. The variable $macfilter is never set .... oops.

Do this :

and that takes care of correctly listed "block" MAC devices.

About the pass issue that can visit LAN devices from the portal network :

I've added my MAC - see list above. The 5a:50 and d2:35 MAC's.
With these two devices, I could NOT access any device on my LAN.

To be sure, I had my dedicated "Do not access LAN from Portal" firewall line log :

and used the 5a:50 to visit my NAS web interface, a printer web interface, etc :
The result was :

So, my GUI firewall rules are blocking.
192.168.2.142 is my Phone on the Portal interface, trying to connect to a device on LAN, 192.168.1.33 port 443, a LAN device web a https web interface.

So, again : rules on the portal interface prohibit LAN interface access.

I'm pretty sure you'll find out why ;)

michmoor

@gertjan Appreciate your feedback here.
As a final test, I moved authentication from Radius to using local auth. Have a phone on the blocked list for MACs. Maybe there is some issue with how im performing radius is what im thinking but....Nope. The phone is able to get on the network but is not able to go between VLANs. Firewall rules are enforced. As I have evidence showing above, firewall state is being created where it shouldn't. No one can explain why that is happening.

So firewall rules are only bypassed if using MAC or IP bypass only. Thats the only condition thats been consistent. Blocking MACs does not work.

Checking redmine, there seems to be a few fixes to captive portal in the next release but i cannot move to a Devel image at this time.

For the time being the only way to get Portal to work reliably is by having the client authenticate on the landing page. I can also limit by mac address per user account so there isnt account sharing but i cannot block MACs.
Another workaround that we are testing is having the Unifi controller run the portal. So far this works as expected. Further evidence showing pf is not in a good place with the captive portal feature

As an aside, Netgate devel could not replicate my issue. Just like you, it "works" but as i told the developer there is clearly some error condition im hitting thats preventing MAC/IP bypass from working as it should. I am open for further debugging if required.

michmoor

@Gertjan Some positive updates. I tried a different interface for a captive zone. A wired vlan. Set up just the same with Radius authentication. MAC and IP Bypass works without issue.
There is something about the Guest VLAN setup where this just doesnt work and that funky behavior is found. I can't explain it.
The difference between the Guest network and the other zones is that this passes through a Unifi AP. This shouldnt matter as the IP given on this network is from pfsense DHCP server and the rules apply to that interface.

Gertjan

@michmoor said in Captive Portal bypass issue:

but i cannot block MACs.

As I mentioned above :

@gertjan said in Captive Portal bypass issue:

Btw : found an error, also called bug.

Which means : MAC blocking doesn't work right now for me - I'm using 22.05.
So I applied the patch / edit shown above. Now it works.

So you have to :
a) wait for an update.
b) solve that issue yourself. Get a keyboard, edit the file I've shown above, and blocking will work for you.

edit : https://redmine.pfsense.org/issues/13747

stephenw10

Hmm, so to be clear you are no longer seeing clients in the bypass MAC list also bypassing the firewall rules on the interface?

I could certainly see how that might happen with the change to layer 2 pf rules in 22.05. But I wasn't aware of it being an issue.

Steve

michmoor

@stephenw10 if I add a MAC to the bypass list, those clients are still able to access the network.

Gertjan

@michmoor said in Captive Portal bypass issue:

if I add a MAC to the bypass list, those clients are still able to access the network.

Not clear (to me).
When you add a MAC, you have to lake a choice : pass or block.
When it's a pass, traffic will not get redirected to the captive portal login page. The device can access what has been set by the GUI captive portal firewall rule set.
When it's a block, you will see the captive portal login page. After entering valid login credentials, you see the message : "This MAC address has been blocked". This is what my redmine 13747 is all about.

The thing is : 'blocking' doesn't work, the device with the blocked MAC can authenticate, and gains access ....

Ok, 13747 Appears to be a duplicate of #13742 ... IMHO : it is not.
13742 is now also closed.

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.

I agree : a "pass" listed MAC bypasses the login page, and passes, as this is the expected behavior.

Redmine 13747 is about MACs being listed as blocked, and they are not blocked (that is : I'm using 22.05).

Eeuh .... Houston, I have a problem !!
(can you take at look at it ?)

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

} elseif (($_POST['accept'] || $cpcfg['auth_method'] === 'radmac' || !empty($cpcfg['blockedmacsurl'])) && $macfilter && $clientmac && captiveportal_blocked_mac($clientmac)) {

The variable $macfilter is never touched, set or whatever.
So it is what ? false ?!
The result is : the elseif never yields true.
The result is : blocked MACs are not blocked.

Easy to test :
Activate a vanilla captive portal.
Take a device, add its MAC to this captive portal instance as a "block", not a "pass"
Connect the device : you'll see the login page.
You'll pass login, and you're logged.
The thing is : you shouldn't be able to do that.
You should see the captive portal error login page with the message :
"This MAC address has been blocked"
But you don't.

Bonus : sooooo easy to solve

Look at this :

My iPhone MAC is listed as blocked.

I can connect, see the login page, login and :

@michmoor
I was not able to access, with my "blocked MAC device that wasn't blocked" any of my LAN (192.168.1.x/24) network devices.
My portal network uses 192.168.2.x/24 - and my portal firewall rules forbid LAN access.

stephenw10

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

michmoor

@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.

stephenw10

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

michmoor

@stephenw10 is it “stable” enough to treat one of my spoke sites as a test?

stephenw10

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.

Gertjan

@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

stephenw10

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

Gertjan

@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 2011

Btw :

@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 2011

which 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.

michmoor

@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.

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