Mobile clients do not reconnect to wifi (WPA2-Enterprise) with freeRadius when WAN1 goes down

newbie1975

Setup:

pfSense CE 2.9.0 on 192.168.0.1
Multi-WAN (WAN1: PPPoE and WAN2: DHCP)
freeRadius for mobile clients (phone / tablets 192.168.0.xxx) with WPA2-Enterprise with Mikrotik as AP Client for freeRadius on 192.168.0.10
Firewall rule for mobile clients (phone / tablets) via specific OpenVPN client gateway
OpenVPN client gateway is set to use gateway WAN2: DHCP

All mobile clients can browse the internet with no problem. Also routing is done according to firewall rule with IP is exit IP of OpenVPN-server/gateway.

What happens:

Unplug WAN 1
Mobile clients can still browse the internet
Shortly disable wifi (or get out of range) of the mobile clients and re-enable wifi (or get back into range): mobile clients refuse to connect to wifi

Questions:

How is this possible? Unplugging WAN1 should not give connection problems, as these mobile clients are firwall-ruled over WAN2 with OpenVPN over WAN2, which both are not down.
Why does it not reconnect to wifi? All components (mobile clients, freeRadius and the Mikrotik AP are in same local LAN and same subnet. Unplugging WAN1 should not prevent any communication between mobile clients, Mikrotik AP and pfsense.

I have tried every option in the General - Advanced - Miscellaneous - Gateway Monitoring options. Kill all, kill non, etc. Nothing changes: mobile clients are unable to reconnect to wifi when WAN1 does down.

All help or directions for solving this issues are appreciated.

keyser

@newbie1975 The issue is probably related to your Freeradius service acting up after link events (perhaps not restarting properly).
This causes AP’s to be unable to validate clients using radius (= no access).

Start by manually restarting the Freeradius service when yoy have cause/provoked the issue. Then you know it’s related to freeradius either not running properly or hanging when an interface events has occured.

Once that is confirmed you know what to troubleshoot. It could be related to the “check_reload_status” race condition that can occour on pfSense. See this thread:
https://forum.netgate.com/topic/201294/submitting-a-pr-for-check_reload_status

newbie1975

Thanks for the reply. But unfortanutely, manually restarting freeRadius after provoking the issue does not help with reconnecting the mobile client to wifi. Still refusing to connect.

Only when I reconnect WAN1-plug the wifi connection gets establised.

Any other ideas what this could be?

keyser

@newbie1975 Does restarting pfSense as a whole (still using the failover WAN2 link after restart) solve the problem? You need to know if its a “temporary” failover issue or a permanent issue in failover state.
Same goes with APs. Can clients start connecting again if you restart an AP when in WAN failover?

newbie1975

@keyser said in Mobile clients do not reconnect to wifi (WPA2-Enterprise) with freeRadius when WAN1 goes down:

Does restarting pfSense as a whole (still using the failover WAN2 link after restart) solve the problem?

Yes, it did solve the issue. Thanks! Didn't even need to restart the AP, only restarted pfSense as a whole.

This is good to know, but this prevents any automatic failover for mobile clients. Can this be solved?

keyser

@newbie1975 said in Mobile clients do not reconnect to wifi (WPA2-Enterprise) with freeRadius when WAN1 goes down:

This is good to know, but this prevents any automatic failover for mobile clients. Can this be solved?

Probably yes, but I was hoping it was a permanent issue when using WAN2 failover, because then it was 99.9% a config mistake/error.
A config error is still likely the case, but it could also be a software glitsch we need to identify and find a workaround for, and that’s much more difficult.

We need to logically isolate whats failing, and the most likely issue is still that it is some kind of Radius (freeradius) issue after interface events. IE: Radius does not work - as seen from the AP - after a failover.
We need to make sure that’s the case:

1: We need some logs/events from your AP’s and from FreeRadius when clients can no longer connect. Can you get both and post what they say?

2: At the same time, we also need a packet capture from the pfSsense DIAGNOSTICS menu. Set it to listen for packets that use port 1812 (radius) on the pfsense interface your APs are connected to, and then try connecting a wireless client to an AP. I’m guessing youll see the request from the AP, but there is no answer returned. Can you verify that?
If there is an answer we need the AP and Radius logs to find out why clients are being rejected instead of authenticated.

luckman212

@newbie1975 hello fellow 1975'er

What does your "System → Advanced → Miscellaneous → Skip rules when gateway is down" setting look like? Wondering if this may have something to do with it…

c174d009-0c06-4800-8f63-f3a6e9e30a26-CleanShot 2026-09-10 at 7.52.33 PM.png

Whatever it's set to, might be worth trying to toggle it the other way and re-test.

edit: forgot to add, would also like to peek at your Outbound NAT rules if you can post a screenshot.

newbie1975

@keyser
Below relevant logfiles during time one of the mobile client (iPad) tries to establish wifi connection after unpluging WAN1 and after short disable/enable of wifi:

1A: Logfiles of Mikrotik AP (first had to create new rule for Radius service):
Logfile - Mikrotik - Radius.png

1B: Logfile of pfSense (regarding Radius service):
There are no events available in System Logs with process "radiusd" (from relevant moment).

2: Packetcapture from pfSense on LAN0 port 1812, shows only incoming:
Log-file - pfSense port 1812.png

So, seems like there are multiple incoming requests from the AP/Mobile client, but no response from pfSense/freeRadius.

newbie1975

@luckman212 life is good from 1975

Skip rules is enabled, think long time ago, because of preventing outbound over WAN instead of outbound over OpenVPN client:
pfSense - skip rules when gateway is down.png

Outbound:
Set to " Manual Outbound NAT rule generation. (AON - Advanced Outbound NAT"
And made Outbound NAT rules from source LAN0 for WAN1, WAN2 gateways and OpenVPN gateway (in combination with firewall rules for mobile clients to use OpenVPN).

Gertjan

@newbie1975 said in Mobile clients do not reconnect to wifi (WPA2-Enterprise) with freeRadius when WAN1 goes down:

Thanks for the reply. But unfortanutely, manually restarting freeRadius after provoking the issue does not help with reconnecting the mobile client to wifi. Still refusing to connect.

Instead of clicking here to start FreeRadius :

use the console or SSH, menu option 8, and then

radiusd -X

and now you'll see radius starting with all the details, and if something fails, you'll know the exact 'why' part.

newbie1975

@Gertjan thanks for helping!

I think this part is relevant from the (very long) output when restarting in console:

radiusd: #### Opening IP addresses and Ports ####
listen {
  	type = "auth"
  	ipaddr = 192.168.0.1
  	port = 1812
Failed binding to auth address 192.168.0.1 port 1812 bound to server default: Address already in use
/usr/local/etc/raddb/sites-enabled/default[2]: Error binding to port for 192.168.0.1 port 1812

Seems problem with port binding, but I do not know what to do with this.

keyser

@newbie1975 Excellent troubleshooting, and it was indeed an issue with freereadius as I suspected. I think it's safe to say that the problem stems from when you have an interface event/WAN failover, and "Check_reload_status" runs to restart relevant services and processes. It would seem that the previous instance of freeradius does not stop properly or is otherwise left hanging as it still occupies the port.

I not sure how to proceed, but I would start by inspecting if it is indeed a general stop/restart issue with Freeradius by restarting pfSense entirely and then:

1: Try and go to Status -> Services, and click stop to freeradius. Once that "says" it's stopped, is it in fact stopped? Run a "ps -aux | grep freeradius" shell command from SSH or the Shell Command in diagnostics. Is there still a lingering Freeradius service?

If there is a lingering process, it would seem you have some sort of issue with your Radiusconfig that prevents it from shutting down normally and then we need to look into that.
If not, please click "start" to the freeradius services again , and see if Wifi Clients can connect successfully. If this test indicates that the freeradius service can indeed stop as normal/successfully, then your problem probably comes from the way "check_status_reload" interacts with your system when a link event happens.
Perhaps you should try and take a look at the revised and bug fixed issue of that very script I linked to I my my first response to this thread.

newbie1975

@keyser Thanks for all help, seems indeed issue with freeRadius.

I followed new instructions, with both WAN1 and WAN2 connected (didn't know if this should also be done with WAN1 unplugged).

Full output from "ps -aux | grep freeradius" shell command after stopping freeRadius:

root  48491   0.0  0.1  14864  3280  -  S    12:07    0:00.00 sh -c ps -aux | grep freeradius 2>&1
root  48911   0.0  0.1  14280  2740  -  S    12:07    0:00.00 grep freeradius

Seems no lingering processes are open.

After 'start' freeRadius again:
Mobile clients can reconnect.

When doing the same testprocedure, but now with WAN1 unplugged:

Output from command is same
Mobile clients, however, cannot reconnect anymore (orginal issue).

keyser

@newbie1975 Hmm, okay, them my command maybe wrong. Could be freeradius is with Capital F or so.

Can you do just a "ps -aux" and see if you can find a freeradius like process when you have just rebooted pfSense. Then you know what it is called , and then you can look for it as a lingering process when you attempt to stop it in the UI.

newbie1975

@keyser The process seems difficult to identify.

Directly after reboot "ps -aux", only one relevant item about radius:

root  28043   0.0  1.6 108272 65424  -  Is   13:15   0:00.04 /usr/local/sbin/radiusd

Stopping freeRadius and "ps -aux | grep radiusd": no relevant items (only this command itself)

Also saw "freeradius3 stopping" when restarting pfSense, so also did "ps -aux | grep freeradius3", however: no relevant items (only this command itself)

Also tried:

"ps -aux | grep *radius*"

This reports some items, but nothing relevant, I think, only items such as:

$tab_array[] = array(gettext("XMLRPC Sync"), false, "/pkg_edit.php?xml=freeradiussync.xml");
			<form action="freeradius_view_config.php" method="post">
							<button type="button" class="btn btn-default btn-sm" onClick="get_freeradius_file('radiusd');" id='btn_radiusd' value="radiusd.conf">

Maybe any other ideas? Would there be other options to release port 1812 after WAN failure?

keyser

@newbie1975 radiusd is the processname. So that’s the one you should inspect when and when it’s not there. Seems it stops fine when you do it manually then. That probably means there is some issue with how check_reload_status handles it. Try and see if you can see it lingering after a wan failover where it does not work

newbie1975

@keyser said in Mobile clients do not reconnect to wifi (WPA2-Enterprise) with freeRadius when WAN1 goes down:

Try and see if you can see it lingering after a wan failover where it does not work

Would it be possible to give a hint how to do this and where to see if anything is lingering from freeRadius? Doing it again with "ps -aux | grep radiusd" does not give any new info.

Gertjan

@newbie1975 said in Mobile clients do not reconnect to wifi (WPA2-Enterprise) with freeRadius when WAN1 goes down:

Address already in use

The question is : by who ?
The question won't last very long, as you know who knows the answer.
Ask him this :

sockstat -4 | grep '1812'

Example :

[26.07-RELEASE][root@pfSense.bhf.tld]root: sockstat -4 | grep '1812'
root    radiusd    42968 20 udp4  *:1812                *:*
root    radiusd    42968 23 udp4  127.0.0.1:18127       *:*
root    radiusd    42968 24 udp4  127.0.0.1:18128       *:*

After all : who use 'port 1812' on a system ? Just like ports 80 and 443, you knows who uses these ports : a web server.
Port '1812' is normally always : a radius server.

So, before you start a radiusd process, you have to remove the one already in a running (or more probably : zombie-) state.
You do this with the command.

kill 42968

where 42968 is the process id.

After this kill command, re check with the sockstat command if the previous 'radiusd' is really gone.

You probably also found the core issue of your problem.
Normally, pfSense can stop and start and restart process just fine.
But if some process goes 'haywire' and can't be stopped (killed) anymore, it states in memory, and keeps on using resources like RAM, and also network ports.
The ordinary user would just 'pull the plug' or reboot the device.
An admin would investigate and kill the process who causes issues ^^

keyser

@newbie1975 use @Gertjan s method to see what is using the port, but it must be a dead instance since it is no longer a running process named radiusd (if that was running it should be showing in your ps -aux.

I’m pretty sure you are hitting issues with check_reload_status not doing things right, and perhaps you should try the patched version to see if that behaves different.

newbie1975

@keyser @Gertjan Now it is getting weird:

Both WANs attached;
Normal reboot of pfSense as whole;
All up, everything working;
Command "sockstat -4 | grep '1812'" gives expected result: 3 lines;
Unplug WAN1;
Check wifi of mobile client after short disconnect: cannot connect (orginal problem);
Stop freeRadius;
Again using command "sockstat -4 | grep '1812'" gives no result: no reporting lines/empty.

So, somehow it reports "Address already in use", but when checking which process id this is, nothing is reported.

How would this be possible? I am testing wrong?