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.

Thanks!

This morning the web GUI wouldn't load. I'm running 2.3.2. Tried it in IE & Chrome on 2 computers in different subnets with same result. Tried using IP address & FQDN, same result. I got a warning about an invalid https certificate, which I shouldn't & don't usually get, and when I told the browser to proceed anyway it just sat trying to load. There were no messages on the console since when I successfully logged in yesterday.

Console options 16, then 11 fixed it.

It's a bug but the CSRF magic default timeout is less than hours (2 hrs vs our 4) so at least in the default case it's actually more secure, not less. I'll push a fix shortly.

@JeGr:

Nevermind, found the fix in the General forums:

https://forum.pfsense.org/index.php?topic=117007.msg654696#msg654696

Excellent.  Finally!  Someone who knows how to use search.  :)

@dennypage:

@NOYB:

Yes because pfSense isn't enforcing the standard and accepted an invalid hostname containing underscores from a DHCP client, I had to troubleshoot and accessibility problem with an application that correctly enforces the standard.

Btw, what was the application? Is it Java based?

You already know what the application was.  You mentioned it and posted a link to the "non-bug" in your previous post.

https://connect.microsoft.com/IE/feedback/details/853796/internet-explorer-wont-save-cookies-on-domains-with-underscores-in-them

So consider it verified that IE is still enforcing the RFC.  Like so many others should be.

In my case it was an HP printer that was issuing invalid hostname containing underscores.  IE would open the printer's built-in web page but the page would not work correctly because IE wasn't saving the cookies.  Had to workaround it by accessing with IP address instead, until I figured out what the issue was.  Would have been much more obvious if pfSense had refused to register the invalid hostname provide by the client.  Fortunately the latest printer firmware doesn't allow or use underscore in the hostname.  In my opinion neither should pfSense accept underscore in hostnames.  They are not valid.  Just because people mistakenly/incorrectly/ill-advisedly use underscores in hostnames does not make them valid.  i.e. per spec.

If people want to operate outside of spec then they should be ready and willing to bare the burden when the spec is enforced.

too

Denny I just went from 2.2.1 to 2.3.2-release

dpinger also stopped for me and no gateways info in the dashboard

Putting in 60000 on each WAN solved it so thanks (they were 3000)

Hey there, I'm not sure if this is related to your issues but I was having trouble with php-fpm crashes a few weeks back while running on 2.3.2, I also read that people on 2.3.1 were having similar problems.  Unfortunately I don't have the logs from back then anymore to compare with your error messages.

If you're still having trouble try removing the IPSec and/or OpenVPN widget from the web console home page.

I don't know which widget was causing the problem for me but I haven't had any issues for almost 3 weeks now, previously was having an incident weekly.

Firefox and Chrome can both sync autocomplete data :-)

Really though, making it store those on the firewall would be impractical (especially as the command list grows over time). It could be done, but I'm not sure the benefits outweigh the extra disk writes, storage use, code to store/load the commands, potential security issues, etc.

Still doesn't make much sense to me. Ideally they should all be different anyhow and tracked separately (and random, secure, etc). Password managers are tailor made for that role. Perhaps that's why I'm not seeing the benefit – doing what you suggest for the reason you suggest would enable poor security practices.

Fixed in```
2.3.3-DEVELOPMENT (i386)
built on Wed Sep 07 19:32:12 CDT 2016
FreeBSD 10.3-RELEASE-p7

ls -al /cf/conf/backup/*.xml | wc -l

32