Captive Portal MACs not working as of 1/1/2017
I'm running the latest stable release 2.3.2 (Sep 27) and I have 182 MAC addresses in Captive Portal to allow all Internet-authorized workstations to bypass the login screen. We use this as a MAC filter to prevent certain departments from accessing the Internet for internal security reasons.
As of about 1:00am 1/1/2017, everyone is getting prompted for a login. The MAC address list is suddenly being ignored. I can't understand why because the configuration did not change from Dec 31 to Jan 1.
Has this happened to anyone else? Does anyone have any suggestions on what to check?
I have restored backup configurations from December and November to see whether that would fix the problem (it did not). I'm at my wits end with this one.
Thank you :-)
Following up on this:
- No log entries out of ordinary compared to any other day in the last 30 days. No errors.
- I restored a complete pfSense configuration from two weeks ago, no change (still not allowing MACs through)
- I've tried deleting the captive portal and restoring the configuration from backup, no change
- I deleted the captive portal configuration, created a new one and manually added just one MAC address (my desktop), and still won't let it through.
Tomorrow I'll try setting the system date back to 2016 and reboot, since moving to 2017 is so far the only thing that happened to make this stop working. (I can only work on this 4am-5am)
For anyone who might be curious about this issue:
This morning I tried setting the date back on the firewall to April 1, 2016 since the problem started on the transition from 2016 to 2017. (Setting it to April Fools seemed appropriate.) The firewall still ignored the MAC addresses listed in the captive portal.
I have tried setting up a new captive portal and populating it with MAC addresses, still not working.
I setup an identical machine (4.2Ghz 8-core 64-bit with 8 gigs RAM and dual 500G HDD Quad GigE) and setup Sync and copied the configuration to the new machine, made sure all was stable and then shut down the primary router. The MAC address in the bypass list are still being ignored. So whatever is going on is moving to a mirror machine as well. (I guess the good news is the failover worked perfectly.)
Ran out of time. Tomorrow I'm going to start completely over with a blank machine and enter all of the configuration manually and see if I can get it to work again.
Pulling what's left of my hair out.
heper last edited by
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.
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.
heper last edited by
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)
doktornotor Banned last edited by
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!!
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.