Captive Portal breaks policy routing for bypassed MAC addresses after upgrade to 22.05 [fixed]
-
Something seems to be broken with Captive Portal after upgrading to pfSense+ 22.05
Relevant information about my network
LAN segment
VLAN for IoT and wifi devices
WAN1 is used as the default gateway
WAN2 is used as the gateway for devices on the IoT and wifi VLAN
Captive portal is configured on the IoT and wifi VLANHere is the issue:
When the captive portal is disabled everything is routed as described above.But when I enable the captive portal, devices that are allowed to bypass the captive portal via mac address are suddenly routed through the default gateway instead of WAN2. But devices that authenticate through the captive portal are still correctly routed over WAN2. Additionally, the console repeatedly shows the message "dummynet: bad switch 21!" when the captive portal is enabled.
I updated from 22.01 to 22.05 and prior to the upgrade, this worked correctly.
Could this be a bug related to the captive portal switching from IPFW to PF?Thanks
Edit:
Bug report here: (https://redmine.pfsense.org/issues/13323)
Patch that fixes the problem is here: (https://github.com/pfsense/pfsense/commit/add6447b9dc801144141bb24f8c264e03a0e7cae) -
-
You are not alone. Same here....
dummynet: bad switch 21!
Disabling captive portal is the only way to bring it back to normal. Here I thought this version would fix my captive portal + limiter problems for good - NOPE!!
-
I'm having the same issue. One more customer eagerly waiting for a solution.
-
Based on the comments in bug 13290 there are two separate problems.
- problem causing the dummynet message
- problem breaking policy based routing
I've opened a new bug for issue #2
https://redmine.pfsense.org/issues/13323 -
I've since reverted back to 22.01
-
After upgrading to 22.05 from 22.01 when enabled Captive Portal bypass all the firewall rules on the Interface!!
-
@stefanoluchetta This has been fixed already now. Check the bug I created, there's a patch you can apply to fix it.
-
We also have a Problem since Update. The Problem is that the Login Page dont appear. Any one else have this Problem?
-
@opit-gmbh said in Captive Portal broken after upgrade to 22.05:
The Problem is that the Login Page dont appear. Any one else have this Problem?
You've read the entire thread, have you ?
I didn't saw someone saying that the login page doesn't appear.
So whatever you issue is, it isn't "dummynet: bad switch 21!" or "bug 13290" or bug "https://redmine.pfsense.org/issues/13323".For what it's worth : I'm using 22.05 and the captive portal. Authentication is handled by FreeRadius, the pfSense package. https login is enabled. No other fancy stuff.
It works.I did saw these "dummynet: bad switch 21!" in the logs, - the portal functionality was doing fine - so I added the patch https://redmine.pfsense.org/issues/13323 and that took care of things.
-
Any idea what can cause my problem or how to debug it?
-
@bitrot How did you apply the patch? Did you go into System >> Patches >> Add New Patch... then upload the .patch file from Bug #13323
-
If you use the captive portal, you should bookmark this page.
Troubleshooting Captive Portal. -
@bobcat05 Yeah, System >> Patches >> Add new patch and then use the URL/Commit ID for the patch to upload it. (https://github.com/pfsense/pfsense/commit/add6447b9dc801144141bb24f8c264e03a0e7cae)
This fixes the Captive Portal policy routing issue. I don't think this fixes the dummynet message. I haven't tested for that. There's a separate bug report for that. https://redmine.pfsense.org/issues/13290#change-61935
-
@gertjan yeah i know this site. but all worked perfectly before i upgraded to 22.0.5. We have multiple Netgate's running with mostly the same config. The Problem with the not upcoming Captive Portal is just on some of them, not on all! So i don't know what can cause this problem. Maybe some have a tipp where i can have a look.
An all our Netgate's we have running: pfBlockerNG und Snort (not in blocking mode) -
@opit-gmbh said in Captive Portal broken after upgrade to 22.05:
The Problem with the not upcoming Captive Portal is just on some of them, not on all!
Then you have the solution already available.
On two pfSense sites, only the settings and surrounding hardware are different.
pfSense on two systems is always identical.
So, compare the settings of a working and non working site.
Most often, its a broken DNS. -
@bobcat05 Is there an easy way to revert back too 22.01?
-
@backlash619 unfortunately not... You have to open up a support ticket requesting access to the version of firmware you want. Then, they send you an image file that you have to write it to a USB stick and completely reinstall pfsense using the console port on the device.
-
@bobcat05 said in Captive Portal broken after upgrade to 22.05:
@backlash619 unfortunately not... You have to open up a support ticket requesting access to the version of firmware you want. Then, they send you an image file that you have to write it to a USB stick and completely reinstall pfsense using the console port on the device.
a) there are reinstall instructions for each model, e.g.
https://docs.netgate.com/pfsense/en/latest/solutions/netgate-2100/reinstall-pfsense.html
(if not Netgate hardware, per other posts one installs 2.6 and re-upgrades to Plus)b) going forward, ZFS and Boot Environments should make rolling back easier. See the Netgate video linked from https://www.netgate.com/blog/pfsense-plus-software-version-22.05-now-available
-
@backlash619 @bobcat05 @steveits The procedure for a re-install is the same as for a downgrade. I did such a re-install after upgrading to 22.05 just recently exactly because I wanted ZFS Boot Environments capability going forward. The re-install/downgrade process is a lot less difficult than some people make it out to be. Even creating a ticket with support for a firmware download isn't a big deal. They responded to my request with a download link within minutes.
-
I also have the issue on 22.05. A captive portal user can blow past the firewall rules and get access to another secured LAN on the same router, etc. Luckily this is testing on a backup router and this didn't happen in production!