@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.

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.