Captive Portal with Free-Radius - not all MACs authenticating - PROBLEM FOUND

tomj

I have been a PfSense Captive Portal user for several years now. I have had many CP with Radius authentication problems for years now where not all MAC addresses will authenticate. I have posted this several times and each time I get back some posts which point me in the wrong direction. This time, I have some hard documentation which I can repeat over and over.

First - some background information;

I run about 1/2 a dozen PfSense Captive-Portal servers. All of them authenticate MAC addresses to my external FreeRadius servers.
Sometimes, when a MAC address has been removed from my FreeRadius users file for a few days, the MAC address will no longer authenticate when I add the MAC address back into the FreeRadius users file.
To me, it appears there is some type of a MAC CP cache file that never gets updated and does not re-load when I do a reboot.

To prove this to myself, I built up a new fresh PfSense and configured Captive Portal to use my FreeRadius servers (under a VMware ESXi server). Prior to placing my newly built/configured PfSense on-line, I first made a full image clone backup of the entire hard disk. No configuration changes were made to PfSense or Captive portal after it was put into production use. About a week later, I removed some MAC addresses from my external FreeRadius users file. Then about a day later, I went to re-add those MAC addresses I had removed a day ago from my FreeRadius servers. Many of the re-added MAC addresses to my FreeRadius servers would not authenticate in Captive Portal. I even tried rebooting everything everwhere and still some MAC addresses would no longer pass through Captive Portal.

My FreeRadius logs do not even show an authentication check being made against the MAC addresses trying to authenticate in Captive Portal. I had about 6 MAC addresses that would no longer authenticate.

So - as a test, I turned off and shutdown my PfSense -and- then turned on a copy of the original build of my PfSense server - and presto - Captive Portal started working for the MAC addresses that were not authenticating.

Both PfSense Captive Portal machines have identical configurations - one was just an image backup of the original build - so I am able to duplicate the problem over and over again.

So at this time, I am 100 percent positive there is some type of a MAC CP cache file in PfSense that does not reset or clear when I restart PfSense. This MAC CP cache file is carrying the problem through a PfSense reboot and the problem continues after reboot. The only way to clear the problem is run a different copy of the original PfSense.

My question - if there some kind of a filter or CP MAC file clear procedure I can perform to clear the stuck MAC addresses in PfSense Captive Portal.

FYI - I have been able to verify this problem across several different PfSense Captive portal servers.

North Idaho Tom Jones

cmb

What do your portal auth logs show for MACs that won't authenticate?

tomj

CMB - thank you for any advice/input

On my PfSense server the /var/log/portalauth.log does not show anything.

With CP turned off, I did a "echo > /var/log/portalauth.log" to empty the file. Then I turned on CP. I then verified that some MAC address were passing through and that some were not. It is almost always the same MAC address that do not pass. Then I turned off the CP.

Checking my logs, it see no new information in /var/log/portalauth.log , it is still empty when I did the echo into it.
Checking my external Ubuntu FreeRadius logs, I only see the MAC address that authenticated correctly. The MAC address that were not passing through CP were also not in my FreeRadius logs.

I am 99.99999 percent positive I have all the settings in FreeRadius and PfSense correct - but I admit that it is possible I have been making the same mistake for many years. PfSense CP works when first fresh configured and installed. The only thing that changes is my FreeRadius users file where a MAC will be removed for days then re-added to make PfSense CP stop working with some MACs forever - forcing me to use MAC pass-through in CP for each problem MAC. I have 1/2 dozen PfSense servers and almost 1,000 identical client devices.

EDIT: I also want to add - the client devices that no longer authenticate to FreeRadius also do not get my external web page that states "call our office - your account is on hold".

Any ideas where to look/check next?

North Idaho Tom Jones

tomj

A question

Does anybody have a PfSense CP which authenticates MAC address to an external Radius server - where they have a hundred or more MAC address in the remote radius users file ?

No NAT - Routing only - using a WAN & LAN and possibly a 3rd network (OPT1) to access a radius server

If so, have you had any issues with some MAC address not authenticating vi radius which forces you to use the Mac pass-through to get a MAC on-line and talking?

cmb

You can't echo to a clog file, you broke your logging doing that. Clear the logs under Status>System logs, Portal Auth tab.

MACs that don't trigger RADIUS auth and get through the portal have to be allowed via some other means. Either already an active session, or in the MAC or IP passthrough.

Anfänger

Have you tried to change in CP the MAC-Adress-sending format ( i.e. "Default" or "ietf" ) to the one your radius server expects.
https://doc.pfsense.org/index.php/Using_Captive_Portal_with_FreeRADIUS
"Captive Portal configuration
Enable RADIUS MAC authentication
Enter any shared secret desired. This field must not be empty! but it is not important what is entered. This is not the shared secret which is used for communication between NAS(CP) and the FreeRADIUS server. I used blaaa
MAC address format. In general this may be left at default or any other option because FreeRADIUS is converting the MAC address (Calling-Station-ID) into the correct format. To be 100% correct choose here ietf "