Freeradius: after upgrade from 0.15.10 to 0.15.10_1: error during authentication: Operation timed out
-
Hi all,
we use several VPN heads with PfSense plus 23.05.1 with professional license, yesterday I upgraded on one server the version of radius package from 0.15.10 to 0.15.10_1 and problems appeared immediately.
We use freeradius with PIN +TOTP authentication (Google auth), fully functional in version 0.15.10, no modifications made other than simply upgrading to 0.15.10_1
The problem is this:
/diag_authentication.php: Error during RADIUS authentication : Operation timed out
Even simulating authentication, previously instantaneous, waits a llong time and then goes into timeout.
-
@Luca-De-Andreis not using anything with pin+totp, but just updated and not having any issues
Sep 26 02:43:32 radiusd 79670 (4) Login OK: [JohnsIphone/<via Auth-Type = eap>] (from client uap-pro port 0 cli DC-B5-4F-E0-CB-0A) 192.168.2.2 Auth-Type: eap
-
@johnpoz
I understand... but I use the PIN + TOTP method with Freeradius, I tried on n.3 PfSense plus and the problem occurs on all systemsOn 0.15.10 works perfectly
-
I understand...
after the upgrade ALL FreeRadius configuration was completely lost: -
@Luca-De-Andreis well that would explain the problem.. I just updated mine to the 10_1 and did not have that problem.. Kind of hard to work without any config.
my guess is you didn't have this checked?
-
Sure:
-
@Luca-De-Andreis well that not good if you had that set.. Not sure what could of gone wrong? I had no issues with upgrade on my 23.05.1 box.. but it happened on 3 different installs? Ugghhhh
-
Yes confirmed. On three different devices (I didn't initially check the Freeradius configuration and so in the immediate instance I didn't realize it was completely zeroed out).
The problem occurred on both VM-KVM and Netgate 6100, same issue.
-
I just updated a new PfSense 23.05.1 server (Freeradius to 0.15.10_1)
This time I did a full backup first.I confirm that after the Freeradius upgrade the configuration was completely deleted.
Restore configuration: ok
-
I have now updated FreeRadius to a fifth PfSens 23.05.1
Same problem.Now I proceed with backup and restore of the configuration and off I go :)
-
@Luca-De-Andreis and you validated before the update that it was checked to no wipe the config?
-
Yes
This PfSense 23.05.1 server was updated yesterday (I mean the radius package) and had the same problem (I didn't notice yesterday that it had lost the configuration).
Then a VM level restore was done and it was back to how it was before the upgrade.
You can see the Freeradius configuration and the version that was before the upgrade. -
@Luca-De-Andreis well that is good that you can rollback.. Maybe someone like @stephenw10 or @Derelict could help us figure out what is going on then.
I was not able to reproduce the issue.. But since you have seen it on multiple boxes - I will look in redmine to see if anything has been reported..
edit:
This looks like the problemhttps://redmine.pfsense.org/issues/14806
Looks like should check your actual xml file - and possible simple solution is to just go in and save the settings, and then recheck your xml to see if the save setting is there.
edit2:
So I just downloaded the xml for package manager - and looking through.. I find this in mine
<freeradiussettings> <config> <varsettingsmaxrequests>1024</varsettingsmaxrequests> <varsettingsmaxrequesttime>30</varsettingsmaxrequesttime> <varsettingscleanupdelay>5</varsettingscleanupdelay> <varsettingsallowcoredumps>no</varsettingsallowcoredumps> <varsettingsregularexpressions>yes</varsettingsregularexpressions> <varsettingsextendedexpressions>yes</varsettingsextendedexpressions> <keep_settings>on</keep_settings>
Notice the keep_settings is set to on... I would look in your xml and validate that is there..
-
This is the section (in the above server)
<freeradiussettings> <config> <varsettingsmaxrequests>1024</varsettingsmaxrequests> <varsettingsmaxrequesttime>30</varsettingsmaxrequesttime> <varsettingscleanupdelay>5</varsettingscleanupdelay> <varsettingsallowcoredumps>no</varsettingsallowcoredumps> <varsettingsregularexpressions>yes</varsettingsregularexpressions> <varsettingsextendedexpressions>yes</varsettingsextendedexpressions> <varsettingslogdir>syslog</varsettingslogdir> <varsettingsauth>yes</varsettingsauth> <varsettingsauthbadpass>no</varsettingsauthbadpass> <varsettingsauthbadpassmessage></varsettingsauthbadpassmessage> <varsettingsauthgoodpass>no</varsettingsauthgoodpass> <varsettingsauthgoodpassmessage></varsettingsauthgoodpassmessage> <varsettingsstrippednames>no</varsettingsstrippednames> <varsettingshostnamelookups>no</varsettingshostnamelookups> <varsettingsmaxattributes>200</varsettingsmaxattributes> <varsettingsrejectdelay>1</varsettingsrejectdelay> <varsettingsstartservers>5</varsettingsstartservers> <varsettingsmaxservers>32</varsettingsmaxservers> <varsettingsminspareservers>3</varsettingsminspareservers> <varsettingsmaxspareservers>10</varsettingsmaxspareservers> <varsettingsmaxqueuesize>65536</varsettingsmaxqueuesize> <varsettingsmaxrequestsperserver>0</varsettingsmaxrequestsperserver> <varsettingsmotpenable></varsettingsmotpenable> <varsettingsmotptimespan></varsettingsmotptimespan> <varsettingsmotppasswordattempts></varsettingsmotppasswordattempts> <varsettingsmotpchecksumtype>sha1</varsettingsmotpchecksumtype> <varsettingsmotptokenlength></varsettingsmotptokenlength> <varsettingsenablemacauth></varsettingsenablemacauth> <varsettingsenableacctunique></varsettingsenableacctunique> </config> </freeradiussettings>
I've not a voice:
<keep_settings>on</keep_settings>
-
but... if I save the configuration (with no modify):
<freeradiussettings>
<config>
<varsettingsmaxrequests>1024</varsettingsmaxrequests>
<varsettingsmaxrequesttime>30</varsettingsmaxrequesttime>
<varsettingscleanupdelay>5</varsettingscleanupdelay>
<varsettingsallowcoredumps>no</varsettingsallowcoredumps>
<varsettingsregularexpressions>yes</varsettingsregularexpressions>
<varsettingsextendedexpressions>yes</varsettingsextendedexpressions>
<keep_settings>on</keep_settings>
-
I was also affected by this issue. Upgraded the freeradius package to 0.15.10_1 on two 23.05.1 machines yesterday and both lost the freeradius configuration in the process.
Got back up and running quickly though:
- Restored a recent backup (configuration). Once firewall had finished rebooting all freeradius configuration settings were back. Confirmed everything was working.
- Went into freeradius settings, unchecked "Save settings after deletion", and saved settings. The re-checked "Save settings after deletion" and saved again. Not sure if this step was necessary after upgrading the package, but I performed it just in case.
- Downloaded a configuration backup and can see that the
<keep_settings>
tag is now there under the freeradius configuration settings.
-
I take it I could not reproduce because not all that long ago, I had changed all my certs for my eap-tls setup, and hit save settings at some point..
-
Somewhat anti-productive, but I found no issues while upgrading to "_1".
I've found this subject the moment I had hit "upgrade" ....
I knew I had a fresh backup of the config, as I have these created twice a day.But nothing happened : all is well ..... euh
-
I checked some older configuration backup files as well and the
<keep_settings>
tag was not present. I assume this must be why the freeradius configuration settings were lost during the package upgrade to 0.15.10_1.@Gertjan @johnpoz - is the
<keep_settings>
tag present in all your configuration back up files (i.e. in ones created prior to the package upgrade)? -
[23.05.1-RELEASE][root@pfSense.bhf.net]/root: grep 'keep_settings' /conf/config.xml <keep_settings>on</keep_settings>
Yep.
edit : that is, somewhere below
<freeradiussettings> <config>