Captive Portal bypass issue

[michmoor]

I will preface this by saying i can reproduce this issue and i have opened a RedMine https://redmine.pfsense.org/issues/13736

I want to know if anyone has come across this problem. Running PFsense Plus

If you use Captive Portal and use the MAC bypass feature. The first problem is that it doesnt work unless you restart the Captive Portal. A bug but not a problem per-se.
The bigger and potentially dangerous issue is that now that the MAC address has been bypassed firewall rules no longer control what happens to the IP address given to that MAC. To provide some more color, CP is enabled for my GuestVLAN - 192.168.11.0/24. My test client receives an IP of 192.168.11.2. That IP will no longer show ip in the firewall logs. Furthermore that IP address can now access resources outside the GuestVLAN (Storage or even LDAP services). This is reproducible on my end.
Has anyone ever seen this?
@stephenw10 this feels like a huge issue.

[Gertjan]

@michmoor

Read MAC Address Control again.

What I make out of it : enter a MAC, and the entire "captive portal" functionality will get bypassed (or blocked, depending on your choice) for the device that use that MAC.

IMHO : the big issue is : you understood something else.
I'm not sure why that should be huge ;) It's ok to have your own interpretation

Btw : the traffic from devices listed like this :

login-to-view

still have to comply with the GUI firewall rules present on captive portal network interface, the GUI firewall page of that NIC.

For example :

@michmoor said in Captive Portal bypass issue:

That IP will no longer show ip in the firewall logs

Was I filtering for this device, the IP or network it is using, and make a matching firewall rule that also logs, then I would have a log line in the firewall log.

Test :

I've added the MAC of my Phone :

login-to-view

I did not restart the captive portal.

pfSsh.php playback pfanchordrill
.......

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/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

confirmed me that the MAC was loaded into the 'pf' firewall.

I could not access any devices on my LAN with my " d2:35:34:2e:b0:39" phone device.
My LAN is 192.168.1.1/24
And my captive portal is 192.168.2.1/24 - my phone had IP 192.168.2.52.
Because my firewall rules on my "captive portal interface" forbid the access to my LAN network.

I'm using 22.05 on a 4100.
But the behaviour was the same for 2.6.0, if I recall well.
I'm using the captive portal for a hotel. The portal is used by people I don't really know (they are my "clients" as they rent rooms), I don't know their intentions. I just want to give them an 'Internet access'.
Basically the reason why the captive portal was invented.
What I do know : they can not access my company's LAN, and all it's PC's, printers, NAS, DVR and all the other 'connected stuff'.

[michmoor]

@gertjan said in Captive Portal bypass issue:

IMHO : the big issue is : you understood something else.

Lets say i misunderstood it. Totally possible. Im willing to bet on it :)
The issue i found is that now that MAC/IP (client) can go anywhere on the network. Rules defined for Guest Network in my example are ignored. I dont even see Firewall logs for the IP thats bypassed.

[Gertjan]

@michmoor said in Captive Portal bypass issue:

Rules defined for Guest Network

Show them.

And play with this rule :

login-to-view

Now you can't get no where - right ?
Change this block rule to a pass rule - now the captive portal login page does show up, and you can get everywhere - right ?

Then you make something that looks like :

login-to-view

depending your needs, of course.

The one before last line is my blocks access to my LAN network ( == 192.168.1.0/24) and believe me, it works, as the hit counter at the beginning of the line shows.

[michmoor]

@michmoor Just tested again and yeah i do need to restart the Captive Portal service each time. There has been some fixes to CP in the latest devel snapshots but that will take some time to spin up and test.

The other point is still worrisome. Once my MAC is bypassed i do not get prompted for authentication anymore but I am able to browse other VLANs without issue. Going to post the relevant part of my rules.debg as it pertains to captive portal

# Captive Portal
table <cpzoneid_2_cpips> { 192.168.11.254  } 

# Captive Portal
ether pass on { igc1.11  } tag "cpzoneid_2_rdr"
ether anchor "cpzoneid_2_auth/*" on { igc1.11  }
ether anchor "cpzoneid_2_passthrumac/*" on { igc1.11  }
ether anchor "cpzoneid_2_allowedhosts/*" on { igc1.11  }

# Captive Portal
rdr on igc1.11 inet proto tcp from any to ! <cpzoneid_2_cpips> port 443 tagged cpzoneid_2_rdr -> 192.168.11.254 port 8003
rdr on igc1.11 inet proto tcp from any to ! <cpzoneid_2_cpips> port 80 tagged cpzoneid_2_rdr -> 192.168.11.254 port 8002

# Captive Portal
pass in quick on igc1.11 proto tcp from any to <cpzoneid_2_cpips> port 8003 ridentifier 13001 keep state(sloppy)
pass out quick on igc1.11 proto tcp from 192.168.11.254 port 8003 to any flags any ridentifier 13002 keep state(sloppy)
pass in quick on igc1.11 proto tcp from any to <cpzoneid_2_cpips> port 8002 ridentifier 13003 keep state(sloppy)
pass out quick on igc1.11 proto tcp from 192.168.11.254 port 8002 to any flags any ridentifier 13004 keep state(sloppy)
pass in quick from any to any tagged cpzoneid_2_passthru ridentifier 13005 keep state
block in quick on igc1.11 from any to ! <cpzoneid_2_cpips> ! tagged cpzoneid_2_auth ridentifier 13006

login-to-view

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/3213573cc56c rules/nat contents:
ether pass in quick from 32:13:57:3c:c5:6c l3 all tag cpzoneid_2_passthru dnpipe 2000
ether pass out quick to 32:13:57:3c:c5:6c l3 all tag cpzoneid_2_passthru dnpipe 2001

[michmoor]

@michmoor @Gertjan
My rules as requested

login-to-view

[Gertjan]

@michmoor

Saw your rules.
The look fine, but I can't test them as I don't know what the Aliases are.

And "! RFC1918" always means : problems ....

What is your LAN interface ? Let's say "192.168.1.1/24" ?
Use that hard coded network as a 'destination', don't even bother indicating the Source, and put this as a rule on line 1 - so at the top, as a block rule.
NO aliases, nothing (== less possible errors).
Bang : no more LAN access.

Now, draw your conclusions ^^

[michmoor]

@gertjan said in Captive Portal bypass issue:

And "! RFC1918" always means : problems ....

I like the negate rules as its explicit. Anything not matching my local nets is permitted.

Rules aside, there is no way any user can leave this vlan and jump to another one. There is something that MAC BYPASS does within PF that allows it to move between networks regardless of the firewall. The fact that there is nothing in the firewall logs for this is concerning.

[Gertjan]

@michmoor

Did you try he rule with the explicit "block to LAN" as a first rule - and make it log ?
When you access LAN from portal, it should match so it will log a line.
The pf MAC anchor rule are valid for the captive portal interface, and not the LAN NIC. So if the MAC pf captive portal rules matches, traffic can come into the captive portal interface without further "captive portal" matching. But other, GUI rules, are also used.

For me, the MAC pass (or block) does not grant my users access to my LAN from my captive portal interface. It would be a massive 'security' issue for me.

So the question is, as your code and my code (scripts .... pfSense) is the same : how are your settings different.

[michmoor]

@gertjan
I amended my firewall rules and added in my DMZ network as the destination.

login-to-view

The Block Internal doesnt get hit when going to my DMZ.
I got rid of the temp rule and so far so good. My MAC address doesnt need to sign in but i am getting blocked from accessing other internal sites.

Not sure whats going on here tbh.

edit: Ok i see how perhaps you can reproduce it. So if i have the client log in first just so i can grab their MAC address. I add that MAC to be bypassed. I have the user login to Guest again which they do not get prompted for a sign-in. That part works. But the client can now access internal LAN networks despite the firewall rule.
See if you can reproduce it on your end based on what i got outlined above.

[michmoor]

Here is proof. State was created. Based on existing firewall rules this should not happen, do you agree?

This isnt right...Something is wrong...

login-to-view

login-to-view

[michmoor]

Based on the screenshots below this shouldnt be possible. So how is it happening?
edit: In case anyone asks, this isnt an existing state. This is a newly created state. I created the firewall rule then had the client join the Guest Network through captive portal.

login-to-view

login-to-view

login-to-view

login-to-view

[michmoor]

@Gertjan update. I have recreated the captive portal zone. I have rebooted the firewall just in case. Dont understand how this is even working.

cpzoneid_2_passthrumac/70317fcfa511 rules/nat contents:
ether pass in quick from 70:31:7f:cf:a5:11 l3 all tag cpzoneid_2_passthru dnpipe 2000
ether pass out quick to 70:31:7f:cf:a5:11 l3 all tag cpzoneid_2_passthru dnpipe 2001

Thats my phone which is set up for bypass.
The GUI has it set to Block the MAC and yet...

login-to-view

[Gertjan]

@michmoor

I start with 3 pass entries :

login-to-view

'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 :

login-to-view

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 :

login-to-view

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

login-to-view

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 :

login-to-view

My iPhone MAC is listed as blocked.

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

login-to-view

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