The PHP error is a symptom of the configuration file being corrupted in some way. If I remember correctly, the corrupted configuration file is kept either in /tmp or /conf. If it exists, you can do a diff of the good and bad configuration file and post that here for review.

@Gertjan OK thanks, I didn't realize that the DNS name is tied to the pfSense user name used when connecting to the OpenVPN server.

Looks like this is starting to happen again.

However it is limited, only some traffic is being routed over the backup connections.

@faustovianna tubo bem ? Aqui não rodou o bloqueio.. consegue me ajudar ?

@Gertjan Surprisingly, it even works without a watchdog and does not go down. 😊
Thanks for help 😉

@EDaleH said in FreeRadius: Something reduces the value in octet file (used):

@jarlel said in FreeRadius: Something reduces the value in octet file (used):

Once or twice every day/night something is randomly reducing the value

I thought I would clarify one point even though implementing the reply above should have corrected it. I realized the explanation as to why I believe you see "reduced values" in the used-octets file may not have been clarified.

Thank for the detailed explanation :-) We are and have been running "interim" for accounting updates. It seems that enabling "Idle timeout" solved it, then it will force an update that updates the octet-file and closes the session file.

Maybe we also should change it to "Stop/Start (FreeRADIUS)" as you suggest above?

@ethanthekiwi said in SCSI error on VM:

For me this issue was caused by thin provisioning on the virtual hard drive. I followed VMware's instructions to "inflate" the disk to thick provisioning and I stopped getting these errors.

Reply

Yeap same solution (https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-storage-8-0/storage-provisioning-and-space-reclamation-in-vsphere/virtual-disk-thin-provisioning-in-vsphere/inflate-thin-virtual-disks.html) worked for myself as well. :)

So - I added an Intel Pro 1000 - 4 port 1G NIC - and all is well.
Realtek disabled in the bios.
Life is good.
Lesson learned.
All functions normal...

Thanks to all who helped.

@patient0 said in What is wrong with my routing?:

fgrep 62.155.245.31 /cf/conf/config.xml

shows no (=empty) output

but a 'cat /cf/conf/config.xml' reveals that the version of the config file (line 3) is "23.6".

So it seems updating pfsense did in fact fix the DHCP issue. I guess something had become corrupted. I haven't had any device fail to connect since updating. I'll still get the ICX7250 ready and swap over to that when I get a chance, seems a good idea to get rid of the cheap unmanaged switch I've been using. It also has a robust POE budget which is pretty cool.

Just an update for my posted problem.
It turns out that it caused by unstable SDN of Proxmox.

People in Proxmox forum suggest me to use the more robust "Network Bridge".
Now, the connection between the VMs seem to be more stable.
In other words, pfSense has no problem at all.

Thanks to those who've read and replied to my post.

@AnthonyW
Hi Anthony, as I face the same issue with my users frequently getting disconnected due to inactivity timeout. I found your KB here, however I can't see https://forum.pfsense.org/index.php?topic=138984.0
could you please explain how to resolve or guide me the correct forum to find the resolution.