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

i have same problem but i am usuing pfsense 2.3.2 so can i apply same solution for 2.2.2 ?
thanks

Glad that fixed it for you. In the next release (or indeed the current snapshot) the fix was further changed to gain the benefit of Phil Davis' work allowing each user to have their own personalized settings.

Look (and comment) here: https://forum.pfsense.org/index.php?topic=117274.0

No. Exposing any data to a user that is not logged in would be an unacceptable security risk.

Didn't watch that whole video but link points to specific spot in the video talking about SAN.. It only showed IPs not any dns, so its actually good practice to set your common name as a san as well if using them.  It is possible from my understanding that some browsers depending how their makers interpret the rfc that is SAN is used to not use the common name.

So if going to create a SAN, you should do san with your IPs you will be using along with your common name, etc..

For example here is my cert on pfsense.  See it has 2 fqdn dns entries and 2 IPs so I can hit pfsense via one of its other interfaces if I wanted too, that was more of a test example for another thread more than actual need.  And it also has a common name set as just the pfsense.local.lan.

If you do want to hit your pfsense via some other fqdn you will have to adjust pfsense to allow that or you will get a rebinding error, etc.  That would be in System / Advanced / Admin / Alternate Hostnames

san.jpg
san.jpg_thumb