Discussed here: https://forum.netgate.com/topic/183065/upgrade-of-freeradius3-from-0-15-10-to-0-15-10_1-sets-all-configuration-values-to-default/7

@Gertjan
Thank you for this clarification!

Today I did set up another test BIND server under linux configured it from ground up. And result is exactly the same. So this problem is not pfsense related. Its something I do not understand in Bind...

@SteveITS
I agree in terms of the function. It seems to work with other tools like Suricata or pfBlocker but with similar functionality.
I'm willing to give it a shot once its available officially tho. Could be interesting.

@slu said in Restore missing FreeRADIUS config:

same problem after the upgrade to 0.15.10_1 today

Hmmm, rereading https://redmine.pfsense.org/issues/14806, if the issue happens on uninstall, that would always be the "old" package and therefore the issue is going to affect everyone until after they get on 0.15.10_1. :(

Oof, this wiped out my FreeRADIUS config as well. Did a full restore from a manual backup and a reboot. Thank goodness for backups.

Can this FreeRADIUS security issue get some love? I deleted all my users (1 user for each phone, iPad, laptop, etc.) to test it, and they're all still able to connect. Using EAP-TLS. That checkbox basically does nothing. Thanks

Check Client Certificate CN
Validate the Client Certificate Common Name

When enabled, the Common Name of the client certificate must match the username set in 'FreeRADIUS > Users'. (Default: Unchecked)

Hi @FrankoniaDKB, did you find how to this? I'm trying the same, I want auth users on a Wireless Network but i can't make this work

Hello. Please tell me, is there any plans to fix the bug in FreeRadius XMLRPC Sync in which certificate settings disappear on the recipient after synchronization?

https://redmine.pfsense.org/issues/11802
more than two years have passed

@bigtfromaz Agreed. I'm also looking for a way to monitor logs, and potentially send out notifications on abnormal connections, eg. Connection from a previously unseen country, etc.

So far the only remote solution would be: https://github.com/MindFlavor/prometheus_wireguard_exporter

I don't feel like installing additional software on my router, but on the other hand, there doesn't seem to be a way to monitor these logs externally.

Please let me know if you find anything interesting.

@eroji well you have from the gui some previous process running..

What you see via some browser and a url isn't always going to be what is going on in the background..

Kill off that old upgrade process, and try with the gui..

edit: I just fired up my 23.05.1 VM and installed package just fine

works.jpg

My problem was resolved by messaging one of the admins who work for Netgate. The issue was due to the fact I had to change out my 4 port NIC on my home built pfsense plus for a new one and it changed my NDI. Once I gave that to them and they updated it to the registered e-mail on file, the Available Packages came back. I hope this helps.

@Gertjan

Thanks for all of your help with this issue. I'm unsure why yours is working when you use the actual ip address of your server in CRON, but mine is not.

Because of what I saw in the packet capture, I decided to imitate what the GUI is doing. I changed the command in CRON to:

/usr/local/bin/wol -i 192.168.2.255 bc:ee:7b:db:fc:f4

The above command works in CRON to wake up my server. From what you said, I'm guessing this is because "192.168.2.255" is the "broadcast address" of the LAN interface of the $(bcip) as described in your post.

/usr/local/bin/wol -i 192.168.2.4 bc:ee:7b:db:fc:f4

The original command above did nothing and didn't even show up in "packet capture" until after the server was already up and running, then I would get something similar to what you got in your packet capture in your screenshot above, as you can see from my previous post. However, the command with the actual ip address reserved for my server in Pfsense fails to wake-on-lan my server, but 192.168.2.255 does work.

Thanks for all of your advice and help which resulted in changing "4" to "255" and now it works.

It's relevant for me too, thank you for explanation

That error was probably from when the package was being removed. That particular error has been fixed in the 2.7.0 package for quite a long time:

https://redmine.pfsense.org/issues/13775

Just wanted to post as I ran into this issue today. I was able to fix this by submitting a TAC ticket with my NDI and SN. The team found a mismatch in their database to which they fixed, and I was able to update all my packages.