CP w/ ext FreeRadius - Not all MACs authenticate - have to also use passthrough
-
I have a strange set of problems I just can not figure out.
I have Multiple PfSense servers each running a single Captive-Portal which MAC authenticates to my external FreeRadius servers.
It works almost perfect - almost -. On some of my PfSense Captive-Portal servers some customers that should get authenticated never get authenticated. This is forcing me to put about 1/2 a dozen or so customers in the CP Mac-Passthrough.
I am 100 percent positive my FreeRadius servers are configured correctly with the correct MAC address information in the user database - however - some MAC address fail to authenticate through Captive-Portal/FreeRadius. It is always the same MAC addresses. I am able to add and remove MAC addresses on my radius servers and have PfSense Captive-Portal do what it is supposed to do.
I have had this problem for years and tried solving the problem for years. The only option I have for the problem MAC address not authenticating is to use MAC-Passthrough for the few that can not authenticate.
The problem MAC customers that do not authenticate do get an IP address from my DHCP server. If I force a new IP address on the problem MAC devices, they still do not authenticate through Captive-Portal.
Furthermore - the same problem MAC address to not even get my redirect web page stating they need to call my office.
It is like something in PfSense Captive Portal has a stuck CP MAC addresses that will never get through the Captive-Portal.
I have examined the config.xml file many times and it looks correct.
Is there anything I can try or look at?
Note - I have had this problem on several versions of PfSense and through all of the updates that have come out.
Note - My FreeRadius do not even show a request from the PfSense Captive-portal query check for the few problem mac addresses - however for everybody else it logs the request and answers correctly.
Note - What is really interesting is if I take a problem MAC device and move it to another LAN on a different PfSense Captive-Portal network then it works - even though I am using the same Radius servers.
Note - the problem MAC addres that never work are normal MAC addresees (ie a proper correct MAC address)
Note - I do not have duplicate MAC addresses on my LAN network
Any help will will be nice
North Idaho Tom Jones
-
radiusd -X
pfsense:/var/log/portalauth.log
-
I have done the radius -X
Nothing shows up.I did not know about the "pfsense:/var/log/portalauth.log"
I will have to look at that -
One thing I am wondering is if a customer is not using my dns servers, then can Captive Portal sometimes fail.
Tomorrow, I am going to try the following:
- set up DNS forwarding in my on one PfSense server
- setup a Firewall > NAT, Port Forward to forward all LAN DNS requests to any DNS server anywhere out on the Internet to be redirected to my 127.0.0.1 address in my PfSense server.
I am using the information at: https://doc.pfsense.org/index.php/Redirecting_all_DNS_Requests_to_pfSense
Then test to see if the problem MAC address behind Captive-Portal suddenly start working.
I will post my results tomorrow
-
Are those clients behind a AP or something that is not in your NAS table?
Post your radius -X output.
-
re: Are those clients behind a AP or something that is not in your NAS table?
I am not sure I understand your question.
My PfSense servers are configured normally like this:
WAN - A live IP address (default route out here)
Opt1 - An internal Lan directly talking to the Radius servers
LAN - Customer LAN (Live IPs - No NAT - DHCP forwarder out to my dhcp server located on the LAN - No DNS server - No DNS forwarderMy LAN(s) then get layer 2 transported to a network of APs (Mikrotik AP) in rural areas. I own all equipment that connects to my APs. The remote APs are only bridging the wireless to the LAN back to the Pfsense LAN (No NAT on my APs). My remote customer microwave client devices that connect to my APs get a Live IP address and then perform NAT for the remote customer LAN. Thus each customer LAN will NAT to a unique Live IP address.
Re the radius - X, nothing shows up for the few clients that do not get authenticated. It is like the request from the PfSense Captive-Portal does not even make a request for the few problem MAC addresses. However the radiusd -X does show everything for everybody else that is working normally. This is why I suspect there is something else going on in CP or with DNS.
North Idaho Tom Jones
-
If DNS is broken users behind the portal will never request a page and will not generate a portal event. What happens if you try to go to something like http://10.10.10.10 in a browser? A browser not IE, that is.
I doubt this has to do with the "MAC address" per se, and is more the configuration of the stack on that host.
-
I just took a look at /var/log/portalauth.log and all logs there also
There are not warnings or error messages - and there the problem MACs are not in there also.
I am going to try some other things next
It is almost like there is some internal PfSense database that contains this MAC and not letting it get checked to the Radius servers - really strange
FYI - The redirect all DNS to 127.0.0.1 did not fix this either.
What is also strange is I have 4 other different PfSense Captive-Portal boxes running in other areas (with lots of working users). However each different PfSense Captive-Portal has 1 up to 5 MAC addresses that just never get through Captive-Portal unless I use Mac-PassThrough. Nothing in the logs - just like a black hole for authentication.
I will try to get to a customer side and manually try pulling up some IP addresses of my equipment.
North Idaho Tom Jones
-
What happens if you try to go to something like http://10.10.10.10 in a browser?
Did you do this?
Again. If they don't get DNS they will not hit the portal at all and there will be no logs.
Another possibility is a proxy configured on the host. If they don't send requests to pfSense on port 80 they will not hit the portal and there will be no logs.
You'd probably be better served unwrapping "MAC addresses" from around your axles and looking at the configuration of the problem devices.
Install wireshark on one of the problem computers and see what's actually happening.
-
I have not tried the http yet.
Re Proxy - I know that can't be it. My client microwave devices which connect to my microwave Lan(s) are owned by me and they are all configured exactly the same. One thing I tried today was I did a remote connection to a problem MAC device and turned off the LAN to prevent customer traffic from getting through to my PfSense Captive-Portal. Rebooted everything including my PfSense server and still the remote problem MAC device could still not get through.
(FYI - I own almost 1,000 remote microwave client devices that connect to my bridging AP. Mikrotik microwave devices - some customers are 10+ miles away and still can get a 150 meg wireless connection rate - using TDMA timing).
So as far as the http or proxy, I suspect that is not the problem - however I will still test the http portion.
I am beginning to thing there is some kind of a db cache file in the PfSense Captive-Portal that is stuck or corrupted or not getting cleared.
O - I almost forgot - a distant memory - about a year ago I replaced a PfSense with another cold box configured from scratch scratch and then uploaded the config.xml and the problem MACs suddenly started working.
North Idaho Tom Jones
-
I am beginning to thing there is some kind of a db cache file in the PfSense Captive-Portal that is stuck or corrupted or not getting cleared.
That's about the last thing I would suspect. portalauth.log should log something. You can also run a packet capture on the portal interface and see what's going on. You can do that from remote if you can get into the pfSense captive portal node in question. Save the pcap, download it, and pull it into wireshark.