I was finally able to reproduce this, turns out that for whatever reason the interfaces.php page wouldn't give me the error but if I went away to something else like DHCP settings then it failed.

I opened https://redmine.pfsense.org/issues/8822 for this and just pushed a fix that corrected it for me.

What version are you running? If it was referencing PHP 7 then it must be a snapshot, or else maybe you somehow pointed 2.4.3 at the development repo and managed to mangle the packages.

Best thing to do from your position is reinstall.

Hi,

Correct - there is no straight forward possibility to do so, probably because way back they discovered that changing the logo didn't change anything related to firewall operations and behavior.

On the other hand, for the last decade now every web browser has an "inspector" option that shows you the entire path of every image on a web site. And guess what, the pfSense GUI isn't any different. Knowing that, ans some PHP/CSS/html knowledge, and your imagination is the your only limit.

Normally, you are advised to fork-of the project, and rebuild the thing own your own.
Of course, totally not supported.

Btw : the question the been asked a lot, and already answered as many times.

You need to have a group name that matches the group assigned in LDAP manually added to your pfSense router.
So if your user is a member of "Router Admins" you need to create that same group locally on pfSense and assign it global admin privileges, since pfSense can't read those specific permissions from the LDAP schema.

Are you using OpenLDAP, or Active Directory?

That is a very large amount of rules. It is entirely possible something in the switch to 2.4.4 helped -- the PHP differences are major, especially moving to PHP 7.2 may be related.

You could undoubtedly drastically reduce the number of NAT rules with aliases though. I'm having trouble imagining any scenario that could possibly justify even a fraction of that amount.

A VPN would be best, but you can do something like this as a backup:

Setup Dynamic DNS on both so you have a hostname that tracks whatever your current WAN IP address is Setup an alias called RemoteManagement or something along those lines, and put in the dynamic DNS hostname from the other end. The firewall will periodically check and update the alias. Setup a remote access firewall rule using this RemoteManagement alias as the source.

Reinstall the package. Go to System > Packages and if it's on the Installed Packages tab, click the icon to reinstall. If it doesn't show there, go to the Available Packages tab, find it there and install it again.

Thanks! That worked.
Rick

I was looking at this again today and now I have another question. If I look at the memory at any given point along the graph, adding up all the numbers doesn't equal 100. How can that be?

Tried to look for an open ports using nmap and it gave me zero results :(

That looks like a great job for a raspberry pi or similar device (BBB, espressobin, etc)

Thanks for the detailed info - JimP you are always a wealth of info...

Not in any hurry was just curious.

Where are you getting your cert from? Your going to have to give us more details if you want anyone to be able to figure out what your doing wrong.

For what possible reason would you want to use a wildcard cert for the webgui? How many possible fqdn/IPs could you point to the web gui?

The web gui should be accessed by limited number of users. Create as cert with your own ca, have the users that will access it trust your ca. Put in whatever SANs you want to access it by. Done - set the cert to be good for 10 years. Never have to deal with this issue again.

Okay I'm just being stupid. Apparently servers do not send the root certificate. The root certificate comes from the Certificate Store in Windows (which I have added the root certificate via group policy). However Firefox does not trust the Windows Certificate Store and maintains it's own. I needed to add the CA certificate manually into Firefox. Now it works.