Captive Portal breaks policy routing for bypassed MAC addresses after upgrade to 22.05 [fixed]
-
@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!
-
@turntheterribletank Did you try the patch?
-
@turntheterribletank Mine can even authenticate to radius... does the patch resolve this?
-
@backlash619 I don't know if the patch fixes your issue. Not sure if what you're facing is related. I don't use RADIUS authentication on my Captive Portal, so I'm not able to answer that. It's simple enough to apply the patch to test it out though. You can always disable the patch afterward if it doesn't solve your issue although I would apply it anyway because it does fix a problem.
-
This is a backup router, so I'm interested in a fixed release and not necessarily looking to patch. No issues with radius, etc. That's all fine.
Production and backup are both 7100 1u. The ability to roll these back will be nice. -
@turntheterribletank I have no issue applying an official patch that will go into the next official release, so I can have an important fix today. But you do you :)
-
@bitrot Yep. We won't be updating to 22.05 and patching. We'll wait.
-
@bitrot Sorry..
the patch file 13323.patch is different from patch https://github.com/pfsense/pfsense/commit/add6447b9dc801144141bb24f8c264e03a0e7cae
and in the patch file:
Luca
-
-
@bitrot OK applied https://github.com/pfsense/pfsense/commit/add6447b9dc801144141bb24f8c264e03a0e7cae
but before authentication it is not possible to reach the DNS (the firewall itself that acts as a resolver). The same configuration with version 22.01 worked correctly.
In addition, the console displays:
-
@luca-de-andreis
I think your other two issues are unrelated.
Here's the bug report for the dummynet message in your console: Bug 13290 -
@bitrot The criticality is that if the captive portal is active, the client correctly acquires IP, GW and DNS, but does not have DNS resolution, consequently it cannot proceed with authentication via the captive portal.
The same configuration worked perfectly with previous releases, nothing was touched. -
@luca-de-andreis said in Captive Portal breaks policy routing for bypassed MAC addresses after upgrade to 22.05 [fixed]:
but does not have DNS resolution, consequently it cannot proceed with authentication via the captive portal.
The hidden 'pf' captive firewall rules are allowing TCP/UDP incoming traffic on port 53 on its interface. A working DNS is mandatory for a working portal.
What are your GUI firewall rules on the captive portal interface ?
When you connect to the captive portal, without logging in, you should be able to dig, nslookup etc.
When logged in, run the ifconfig or ipconfig /all command and check your IP, mask, gateway and DNS. The last two should be the IP of the captive portal.Also check and double check that the resolver unbound is actually listening on the captive portal's interface. A command on pfSense like :
sockstat -4 | grep ':53'should say :
unbound unbound 18042 3 udp4 *:53 *:* unbound unbound 18042 4 tcp4 *:53 *:*which means unbound is listing on every existing ( == 'All') interface on pfSense.
-
@gertjan Thanks for the detailed explanation ...
Look ... I'm done talking to TOC support now, call code 1006603521.
I am truly speechless.
Yesterday I updated PfSense I tried the captive portal and it worked, shortly after it stopped working and I left it disabled (after restarting the service several times) so that users could still use that network segment.
Now I get TOC support into the system, enable the captive portal and ... IT WORKS.
Tried with disposable code, tried with whitelisted MAC, it works as expected ... and I haven't touched a comma if it doesn't enable / disable.
I left the ticket pending, let's see how it behaves. Really, I have no words, thank you!
-
@luca-de-andreis
I understand you are upset about this problem but why are you hijacking my post with your issue that is completely unrelated instead of creating your own post and/or bug report? -
@bitrot you're right, I thought of doing it, but then for the hurry and thinking about the same problem (at least yesterday) I wrote here, sorry.
