CP w/ ext FreeRadius - Not all MACs authenticate - have to also use passthrough

Derelict

radiusd -X

pfsense:/var/log/portalauth.log

tomj

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

tomj

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

EMWEE

Are those clients behind a AP or something that is not in your NAS table?

Post your radius -X output.

tomj

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 forwarder

My 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

Derelict

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.

tomj

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

Derelict

@Derelict:

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.

tomj

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

Derelict

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.