Captive Portal MACs not working as of 1/1/2017
-
are you sure this is a problem on the captive portal?
maybe another member of the staff configured the wireless-controller(or AP's) into tunnel/router-mode with NAT?check the CP logs what mac-addresses get logged & if they are corresponding to the actual mac of the clients
-
Yep, I checked that in the first few minutes back in on 1/1/17. I can PING every client's IP address from the pfSense router and verified that their MAC addresses are being associated with their IP addresses in the pfSense ARP table. But thanks for asking.
I'm just about to destroy the primary router and configure it by hand so we'll see in a few minutes whether this does anything.
-
Final update:
-
Wiped the primary firewall, reinstalled, restored configuration file ("All"), continued ignore MAC bypass list.
-
Reinstalled again, then restored restored only firewall rules, NAT, Aliases, and Captive Portal sections, then entered the rest of the configuration manually, and now IT'S WORKING AGAIN!!
If I do a page-by-page comparison with the backup firewall (where the captive portal still ignores the MAC list) everything is exactly the same.
If anyone wants to see the config file that breaks the Captive Portal MAC bypass, let me know.
-
-
it might be good to post a santized config of the broken one & the working one.
maybe someone can find a clue in there
-
For anyone who might be interested in finding the issue with Captive Portal.
To reiterate, we use Captive Portal to control access to the Internet, with all authorized workstations listed in the MAC bypass table so they never see the login prompt. Sometime between Dec 31, 2016 and Jan 1, 2017, the Captive Portal began ignoring the MAC pass-thru list and it displayed the login prompt to everyone. Restoring any backup configurations from previous two months didn't solve the problem. Setting the date back (via root) to something prior to 2017 didn't work. Reinstalling pfSense and restoring a configuration from 2016 resulted in the same problem.
The problem was finally solved by reinstalling pfSense on a clean machine, restoring only Aliases, Captive Portal, NAT and Rules, and entering the rest of the configuration manually.
Attached are the two backup files, with private info cleaned (enough) but everything otherwise intact.
Note: the new "working" configuration does not have as many packages installed as the old configuration, e.g. I had Snort running to watch what it detected but wasn't blocking anything yet, and is not installed in the new configuration (yet).
Good luck with this. I'm just glad it's working again so I can control individual bandwidth-wasting morons before I go postal on the whole organization.
Cheers and Happy New Year everyone.
[Captive Portal issues.zip](/public/imported_attachments/1/Captive Portal issues.zip)
-
I'd blame the leap second. :P
-
You mean the stupid physicists who want the sun to be exactly overhead at noon are to blame?? OFF with their HEADS!!
-
Hi h2professor,
I am very new to pfsense and have taken over a customer who is having the same issues as you describe. is it a case of importing the .xml file? Do I assume correct that all MAC's will need to be re-entered as they have similar numbers? -
Here is what I did. It's actually in my reply above, but I'll break it down into steps.
1. Download a full configuration backup of the router. (debugging/backup/all)
2. Be sure to go through every page of the configuration and print/write down/screen capture the configuration so you can go back and enter it again.
3. Wipe the configuration clean and reinstall pfSense.
4. Assign IP addresses to the ports and verify basic connectivity to the Internet, then allow pfSense to detect and install the latest version.
5. Using the downloaded configuration from step 1, use the debug/restore and restore only Aliases, Captive Portal, NAT and Rules
6. Go through every page of the config and enter the configuration manually that you kept in step 2.These are the steps I took to get mine working again, and it's still working.
Best of luck to you. -
If you are able, please post your saved (broken) configuration to a message here. I would really be curious to compare yours with mine.
-
Well here's a new twist. This morning (specifically, exactly at midnight between Jan 17 and Jan 18) the captive portal reverted to ignoring the MAC address bypass list again. !!?!
On a whim I decided to upgrade to the latest development snapshot, because what the hell, I would have to reinstall anyway. So I'm running on 2.3.3-DEVELOPMENT (amd64) built Tuesday Jan 10
And it worked! Problem gone.
So I would assert that the MAC address bypass in version 2.3.2-RELEASE-p1 has a bug that is fixed in the latest development snapshot. I just hope it doesn't blow up on me, but it's currently working just fine. (I like the new look, too.)
So pfSense developers, I'm your biggest fan now.
-
Thanks h2professor for the update as I too was having similar after re-installing. I have updated to the latest development build as per your post and hopefully have no further issues.
-
Hi h2professor, just wondering if your captive portal is still working as mine has reverted back to allowing access ignoring MAC addresses.
-
I have not had any further problems now that I upgraded to a development version.
So just to clarify, in your situation it is allowing access to systems that are not listed in the MAC bypass list?
-
Yes, it is allowing any system to access that is not in the MAC bypass list
-
Your problem is completely opposite from the problem we were having. In our case nobody was getting through. In your case everyone is getting through. Be sure to check the settings on the Captive Portal Configuration, especially the two "Enable pass-through MAC automatic addition" checkboxes.
Upgrading to a development release ended up being the solution to our problem, but since yours is completely opposite, there's no way for me to say that would work in your situation.
-
Thanks h2professor. Back to the drawing board so.
-
To whomever is tracking this issue, we upgraded to 2.3.3-RELEASE (amd64) and we continue to operate without problems. Just because I was curious, however, I reinstalled the older 2.3.2 version on the backup router and restored the configuration that was attached in this forum and it does revert to ignoring the MAC bypass list, but then I upgrade it to 2.3.3 and once again the problem went away. So congratulations on the new version, and thank you very much for your excellent work.
-
This morning at 4:00am sharp the router rebooted for no apparent reason (no error in the logs) and it is back to ignoring the MAC address bypass list in the Captive Portal settings just like it did back on January 1 of this year (hence the bump of this topic, because all of the conditions are the same).
I've had to turn off Captive Portal to prevent denying access to the Internet for all of the workstations on the network. Current version 2.3.4-RELEASE-p1. Rebooting the router again didn't solve the problem. No configuration changes have been made this week. The router has been rebooted a number of times without this problem. Etc etc.
System configuration AMD FX-8370 Eight-Core 4.2 GHz with Intel Quad Gigabit Ethernet card, dual HGST hard drives, 8G RAM (barely used), etc etc about 300 workstations to dual upstream gigabit Ethernet WAN. All overkill.
I was already planning to upgrade to 2.4 this weekend, so we'll see if that fixes the problem.
-
Upgrading to 2.4.0.RC solved the problem. Captive portal now recognizing the MAC bypass list.