Freeradius: after upgrade from 0.15.10 to 0.15.10_1: error during authentication: Operation timed out

Luca De Andreis

@johnpoz

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

Luca De Andreis

@johnpoz

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 :)

johnpoz

@Luca-De-Andreis and you validated before the update that it was checked to no wipe the config?

Luca De Andreis

@johnpoz

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.

johnpoz

@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 problem

https://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..

Luca De Andreis

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>

Luca De Andreis

@johnpoz

but... if I save the configuration (with no modify):

tman222

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.

johnpoz

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..

Gertjan

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

tman222

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)?

Gertjan

@tman222

[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>

johnpoz

@tman222 I just looked at one from 9/3 and the setting was there.

edit: found an old one from 2/19 and yeah settings is there.. One from 8/23 and yup there.

tman222

Thanks guys, I think that explains it then. I did have the "Save settings..." option checked, but the tag was not present in the configuration back up files. Maybe I never hit Save on that screen. In any case, it appears to resolved now.

whorfin

Same boat; that wrecked my evening, but fortunately I found this thread after moving to a privileged machine not needing radius authentication.

Upgrade from 0.15.10 to 0.15.10_1 blew away all freeradius config.
Restored pfSense from a backup config.
Confirmed that the GUI showed "Save settings after deletion" was ticked
...but the config file had no entry for <keep_settings> it was simply missing
Unticked/saved/Ticked/saved and then exported a new config
<keep_settings> is now present and set to on

ps - unable to check the redmine link above, the site is currently busted:

This website is under heavy load (queue full)
We're sorry, too many people are accessing this website at the same time. We're working on this problem. Please try again later.

stephenw10

The redmine site is available again. That bug is now fixed.

Viper_Rus

This post is deleted!

c0ff33h4x

@Luca-De-Andreis said in Freeradius: after upgrade from 0.15.10 to 0.15.10_1: error during authentication: Operation timed out:

/diag_authentication.php: Error during RADIUS authentication : Operation timed out

Is there a fix for this specific error? I'm in a (presently unique but likely soon to be more common for other users) scenario where I'm installing a fresh 2.7.1 build with no backup to restore from so I only have freeradius3 0.15.10_1 available which isn't functional and results in the above Operation timed out message.

stephenw10

The only reason OP in this thread was seeing that is because all radius config was lost at upgrade. That shouldn't affect you on a clean install so I'd suggest it's just not configured correctly.
We're going to need more info to diagnose that further.

c0ff33h4x

@stephenw10 I configured it the same on 3 previously 2.7 builds with no issue, and followed the same instructions for this. Also wiped and did a fresh reinstall and reconfigure with the same result. Followed these instructions to a T: https://www.netgate.com/blog/freeradius-on-pfsense-for-2fa but that timed out error is the only log indicating the failure. I am human though so I could have make a mistake and then replicated the same mistake over again but comparing build to build, I don't see any difference in settings.

Is there something else I can check to diagnose this further? I need to get this functional so I'll probably need to take a backup of one of the other systems I tweak that to work but it would be nice to know why this is failing so that it ca be fixed in an _2 release.