@jimp Thanks for your reply. I did search for 'traffic' in both of them and this is the group privileges menu actually. I have reinstalled the package and rebooted after that didn't work. I have just reinstalled again, just to make sure. But that also didn't work. The traffic graph privilege is already assigned to this group, so that's probably why it doesn't show up. There's no privileges on the account not inherited from said group. See here an example of one of the individual accounts under this group. [image: 1693215469371-5c606339-1d6b-45f2-9c36-167c8c7200bb-image.png]

@JonathanLee @jimp thx for your inputs, it was indeed the same trackerid on all the rules. i just copied and paste it on itself and deleted the old ones, now its working as expected. thx you guys

The problem is actually a bit worse than initially reported. The problem does not only happen after edit/save, but also after restarting the service. Steps to reproduce configure correctly (manually add newlines) Save Now the openvpn server runs correctly, with the extra-certs option Go to openvpn status page (/status_openvpn.php#) Click "restart" on the openvpn service Result The service does not restart, openvpn.log shows Aug 23 17:11:05 fw openvpn[84943]: SIGTERM[hard,] received, process exiting Aug 23 17:11:06 fw openvpn[1001]: ERROR: Endtag </extra-certs> missing Aug 23 17:11:06 fw openvpn[1001]: Exiting due to fatal error To fix again, go the the openvpn config page, manually add the newlines (2x), save -> service runs.

This has been fixed in commit 9270d777907048d2bfc31f4e57a01e915ff71a88

While we are at it, another problem I noticed: Rejects are not shown as such in the widget or log, they are all blocks. [image: 1692684427411-capture3.png] [image: 1692684435468-capture1.png] [image: 1692684440549-capture2.png]

@MonitorGuy Fixed by changing the number of lines to view in GUI from 5000 to 1000

@Gertjan Just a FYI, it was a MTU issue. Everything was set to 9000 except for the vSwitch in esx where the pfsense was running.

@Eugene_Tar said in webConfigurator authentication error: 2.5.1 Oh boy. That one is ancient. Coming from that one I would (free advise !) re install, and while doing so, use the new, way better, ZFS file system. @Eugene_Tar said in webConfigurator authentication error: /cf/conf/config.xm Make a backup copy of this file. Then, from the console menu Reset webConfigurator password or even better : option 4. Now the password is known and default. It still doesn't work ? You're good for a complete re install. This will solve the issue for sure with just one silly side effect : we'll never known what went wrong.

@rcoleman-netgate thanks

@q54e3w The only difference from the guide and my setup is the pi-hole. Which is one reason why I am having issues. Like I explained I had it set up and worked great before my venture to the nguvu setup.....

@KB8DOA you can give it a commit ID. Or just update pfSense as noted. https://docs.netgate.com/pfsense/en/latest/development/system-patches.html#patch-settings

that worked worked

@viragomann , Thanks for your prompt reply. I will give it a try.

@conbonbur : Like the solution of johnpoz, which needed the console or SSH access, you could also use option 15 : 0) Logout (SSH only) 9) pfTop 1) Assign Interfaces 10) Filter Logs 2) Set interface(s) IP address 11) Restart webConfigurator 3) Reset webConfigurator password 12) PHP shell + Netgate pfSense Plus tools 4) Reset to factory defaults 13) Update from console 5) Reboot system 14) Disable Secure Shell (sshd) 6) Halt system 15) Restore recent configuration 7) Ping host 16) Restart PHP-FPM 8) Shell Use a config that was made just before de deletion. Just for my own curiosity : deleted in the GUI, you were not using it ? Something else ? @viragomann said in "webConfigurator default" certificate: Yes, you can restore it from a config backup.

@Gertjan said in Why is my GUI suddenly (only) available at port 4443??????????: The fact that pointing a 192.168.55.1 at port 4443 shows the pfSense GUI means that there is a 'firewall' that is doing something. Like redirecting incoming TCP traffic on port 4333 to TCP 443. Yeah, seems plausible.