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

johnpoz

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

Luca De Andreis

Sure:

johnpoz

@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

Luca De Andreis

@Luca-De-Andreis

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.

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.