There's a known but elusive bug that sometimes disables the UI entirely, perhaps it's that simple. https://redmine.pfsense.org/issues/6406

Enable SSH on the unit and SSH in and choose "Restart PHP-FPM" and see if your UI comes back.

Happens on the latest 2.3.2 also. In fact, just happened to me.

I suspect it's this elusive bug: https://redmine.pfsense.org/issues/6406

I tried restarting the webconfigurator but it did nothing, never tried the other option as the box is not yet live, just rebooted.

Apparently it's more likely to happen if you leave the web page up for a period of time.

Thankfully it doesn't affect SSH, and it doesn't affect functionality, so it's an annoyance rather than a bona fide forest fire emergency.

Should be simple enough to make the table sortable. I will look into it later this week.

Usually that sort of error happens because the browser is attempting the wrong protocol on the port. For example, you might have used https://x.x.x.x:yyyy when the web server was actually set to HTTP.

You're better off starting a new thread, a lot has changed since this thread (lighttpd switched out for nginx, for one).

From a security standpoint, allowing it to run in an iframe is an awful idea, which is why we have protection against it.

Create an account and submit a feature request here:

https://redmine.pfsense.org/

@charlie0440:

Is it possible to have an email sent using the smtp settings (system > advanced) when pfsense boots?

'booting' is one thing, pfSense should be able to connect to a mail server, which could be some where on the Internet.
This means that interfaces should be up and functional.

This is what I tried :
Insert

just before the ending "?>" in this file : /etc/rc.bootup

I received a mail saying "pfSense booted." when I rebooted pfSense..

@johnpoz:

I think the .crt is just confusing you - you can open that .crt file in notepad its just the base 64 encoded file..

Thanks for the reply. Not sure how I missed that.

Nifty!

Changing the periodic backup settings is just a cron job change.  So reboot is not required for that to be applied.

Changing the size gives the message, "The changes have been applied successfully." even though it has not actually been changed, and there is no instruction that a reboot is needed to complete the change.

AWESOME! That did the job, I have looked at that screen about 100 times and never noticed that option, thanks heaps for that :)

That way was chosen because it fit the current user privilege mechanism. If it was done some other way it would have vastly increased the complexity of the code for very minimal benefit. Selecting everything is never necessary, just pick the "all pages" privilege and a maybe ssh and whatever else someone needs. We have never recommended selecting them all and it's never been necessary. You also never, ever need to edit the group permissions for the admin group, it has all access by default. We don't lock it down because there may be some unforeseen need, but that is also a bad practice.

We can only go so far to prevent foot-shooting.

As for regaining access, the config can be edited by hand at the console using viconfig, or you could use scp to fetch a backup copy of the config and then edit out the privilege, scp it back and restore it from the console.

Looking at rrd_fetch_json.php, I notice that "step" is taken from the rrd data file itself. So it could be something with the data or at least the data collection process.

There is now a package that can be installed to add this functionality. Go to System > Packages and install the Status_Traffic_Totals package. This will add a Traffic Totals item to the Status menu that can enable and view the traffic totals as maintained by vnstat.

Guys, i really sorry for my english  :'(

@jimp:

Is the CN of the new server cert ldapserver.example.com ?

Read all the requirements here:
https://doc.pfsense.org/index.php/LDAP_Troubleshooting#Connection-Related_Issues_.28SSL.29

Hostname Required

When connecting to LDAP with SSL, the hostname given for the server is also used to verify the server certificate. The server certificate's common name must be its hostname, and that hostname must resolve to the LDAP server's IP address, e.g. CN=ldap.example.com, and ldap.example.com is 192.168.1.5.

Let me ask a little thing - does it mean that CommonName of the RootCertificate of CA must match FQDN of machine on which CA is deployed?

I decide to try LDAPS authentication after upgrade to v2.3 and i'm confused now.
I have "WIN2008R2 with DNS+AD+CA"=$computer hereinafter ===> authentication from PFSENSE over LDAPS works!…... then does not works..... then works again, i cannot understand why it happens.

CommonName of mine CA's root certificate in not match FQDN of computer,
BUT i had success LDAP container tree request over TLS and authenticate test in diagnostics have passed success (i captured it by wireshark on computer), then goes some time and it does not work (exactly same issue like ovprit - same error in wireshark's capture and same openssl s_client -connect output) Difference is:
when i type openssl s_client -showcerts -connect dc.local.domain:636
there is answer:

CONNECTED(000000004)
–-
Certificate chain
0 s:/CN=dc.local.domain
  i:/DC=domain/DC=local/CN=local-DC-CA  #stupid mistake, agreedisagree
–---BEGIN CERTIFICATE-----

-----END CERTIFICATE-----
Server certificate
subject=/CN=dc.local.domain
issuer=/DC=domain/DC=local/CN=local-DC-CA

To make it works i do stupid actions like: i've done two autentication server in pfsense - local.domain (old) and test (new).

Authentication servers=> test (settings like ovprit,besides server address) => select a container => "Could not connect to the LDAP server. Please check the LDAP configuration" on bottom of the page.

=>changing Transport to "TCP - standart" => select container (tree is appear, i see captured raw ldap requests in wireshark on computer:389) => save.

=>Authentication Servers => local.domain (settings like ovprit) => change Transport to TCP - standart => save.

=>Authentication Servers => test (settings like ovprit but Transport is TCP) => change Transport to SSL - encrypted => Select a container (tree is appears and i can see good tls session in wireshark on computer:636) => save.
Now i can success test authenticate in diagnostics and can to see TLS session in wireshark.

But then after some time has gone, it's breakes down and voila! i have issue like ovprit.

Update#1
I don't know why does it worked before. What i've done:
1. Imported ROOT CA public certificate without private key
2. Choosed it in Authentication servers => edit server =>Peer Certificate Authority
3. Profit? :S Authentication Server save and test passed success.

"Obviously I know there is a problem. "

But unable to understand the error that your CA is invalid?  This is the frustration part for me, multiple posts telling you how to fix it already and still not getting it.  Not that there was an error in the cert, the errors specifically states that the CA is invalid.

First reply, first line of my post
"By importing the CA of your cert into the store and accessing pfsense by a correct fqdn that is the common name on the cert or by the IP address you put in the cert as a SAN.."

This is when the thread should of been over ;)  Even gave pretty pictures and everything..

If you want to debate or discuss why pfsense issues a selfsigned cert without a valid fqdn (cn) that would be good discussion.  But multiple posts stating you need to trust the CA and use a valid CN or SAN to access the site with did not seem to be clicking..  There was no sarcasm in my posts, I honestly have no idea why it was not clicking with you when the answer was given to you in reply 1..

You access the web gui very early in the process of setting up pfsense.  Guess they could ask for a fqdn before the webgui portion and offer up link to download the CA before you even hit the webgui.  Put in a feature request on redmine.  But its pretty common practice on anything that has a web interface and allows for https to use a self signed, that is going to give you errors.  Since your the one setting up the device seems logical you would accept these errors until you have time to correctly setup the https to not give you errors, etc.

Hmm, no, that one still is showing through. Harder for that one to be useful to anyone though as it's specific to requests coming from the firewall itself.

I pushed a fix so it's obscured as well.