O.K. I tried setting both memory limits to 1024M and rebooting.  Unfortunately I still get the same PHP error Allowed memory size of 134217728 bytes exhausted on the pfBlockerNG Alerts page.  Since PHP is obviously configured for more "Allowed" memory than this, does anyone know where this limit is coming from?
Thanks!

Ah. I made an assumption that I was logged out if the GUI was restarted. Whoops!

Thanks for the help!

Alright! It is officially confirmed that Suricata inline mode was causing this. I recently had to switch back to Legacy mode due to another odd issue which was impacting my day-to-day. I found it impossible to manage false positives that were not showing up highlighted in the alerts log. How to you create an exception to a blocked IP which you can't even see? Maybe I was doing something wrong? In any case, I switched back to legacy mode with all the same categories and rules selected. Now the legitimate site that was blocked before is not blocked and my WAN out graph is working too. Magic! In the meantime, I'm staying away from inline mode until I grow enough courage to give it another try. I'm pretty sure it's likely a netmap issue. At one point, I couldn't even get Suricata to restart because of some netmap error. I know netmap is not a pfSense or Suricata issue in particular. I believe that's a FreeBSD thing and/or netmap being too young.

Hi guys,

The issue has been solved by updating system time manually (was 1 hour ahead of correct time).

Now, all traphic graphs are working fine and they start rendering immediately when opening the dashboard.

Regards,
Philipp

Are you saying that the time is off by 1 hour?

That is just showing you when it last checked.  What does it show for system time exactly?

Pfsense shows right on the button for me, and it just refreshed checking.. Daylight savings runs from Mar 11 to Nov 4 in US, after Nov 4 it will be standard time or PST in your case or CST in my case. Shows correct for CDT and PDT March 19 as stated already by gjaltemba

currenttime.png
currenttime.png_thumb

@jeffc:

One more question: I noticed something about a new Acme API that was rolled out. Is that something I should go do? Does that work on the existing version of pfSense (2.4.2-RELEASE-p1), or would I need to install some sort of update to get that?

When a package update comes out, like 0.2.5 for acme yesterday, you should upgrade.

This newer version includes the possibility to obtain wildcard certs from Let's Encryopt - if you need them. See ACMEv2 is live!

Great, glad it's working now! :)

@Gertjan:

@das_remsem:

….and even internet works... kind of.

Oh. Let me guess … the quad-8 problem ?

Anyway, glad things worked out.

Never heard… this https://forum.pfsense.org/index.php?topic=145038.0

Thanks, closing this as solved.

Open a ticket.  I don't know if anyone outside of Netgate would have experience with that many NATs.

Not all widgets update automatically and this is one that does not. Carp status is not something that typically changes on a frequent basis. Currently you need to reload the page to see the current state.

You could always file a feature request on Redmine if this is something important to have.

Thanks for the reply das_remsem, i tried everything you mentioned and still the same issue. I`ve been working on it a few hours this weekend and connected a monitor and keyboard to the router. i tried re-installing PFSense and it wouldnt take so i used Dban to format the disk. Re-installed and the same problem. I have my work Surfacebook home with me so i fired it up and it worked. I was able to hit the web GUI no problems. I wasnt too sure what else to do so i quickly install LinuxMint in HyperV on my PC and used that to re-configure the router. I tested the WebGui again from my pc and the same problem, i just so happened to click on the SSL error and looked into the certificate and noticed that it was sitting under a BitDefender container like BitDefender Free was dealing with the certificate. I uninstalled BitDefender Free and the Gui is now working in every browser like it initially was. Quite strange but i figured it out and hopefully others who may be having the issue can use this as a resolution should they have BDFree installed.

Regards
Danny

Yes the IP is in scope - but the firewall gui which should never be available on that IP should not be… You turn on pfsense out of the box there is NOTHING open on the wan, ZERO services available - shoot it does not even answer a ping.

Any traffic you allow inbound would be involved in the scan,not services that would never be available on that public IP..

You creating a firewall that allows access to the gui from the wan is what would put it in scope - why would you do that... There is ZERO anything pci compliance that would suggest you would open up a devices admin gui to the public internet..

A pentest against this IP would be in scope... They can pentest all day - but you opening up the web gui to the public should of never happened.  If they can access the webgui via a pentest when you have not allowed it then that would be in scope - and would be a whole shitcan of worms.. But you creating a specific firewall rule that allows access to the gui or any any to the wan IP is just not correct way to do this sort of scan or any sort of pentest or compliance test at all.

Like saying hey we want to test the lock of your door.. Unlock it please - oh yeah that lock doesn't do shit, it opened right up...

A pentest or compliance test is against service that would be open or finding stuff that is open and should not be.

auditor: Hey you have ntp open on port 123
user:  Yeah we need that
auditor: Ok it must meet xyz if your going to have it open.
user: Ok we will do xyz
auditor:  Ok scanning, yup its version X, it doesn't allow that or this - your good
user: thanks.

auditor: Hey you have ntp open on port 123
user: Oh shit really -  we don't need that.  Closed
audiotr: Ok let me check - yup no ntp anymore your good.

based on https://forum.pfsense.org/index.php?topic=144026.0 i changed:

/etc/inc/system.inc

        if ($captive_portal !== false) {                 $nginx_config .= "\tlimit_conn_zone \$binary_remote_addr zone=addr:10m;\n";                 $nginx_config .= "\tkeepalive_timeout 0;\n";         } else {                 $nginx_config .= "\tkeepalive_timeout 75;\n";    <--------- 75s         }

to this:

        if ($captive_portal !== false) {                 $nginx_config .= "\tlimit_conn_zone \$binary_remote_addr zone=addr:10m;\n";                 $nginx_config .= "\tkeepalive_timeout 0;\n";         } else {                 $nginx_config .= "\tkeepalive_timeout 0;\n";  <------------ changed to 0s         }

and it seems to do the trick?

Have a look at this Captive Portal !

@Clouseau:

…..
Is there any work around to fix this?

Yep.
Telling us more / the whole story.

The error says that an instance of the GUI is already running, thus the 'bind' error - but probably not in a good shape.

Check out the logs files after booting. Something must show up that is not "normal".

edit : I can rip out the WAN cable (WAN connection for me is a DHCP client, connected to an up stream ISP router) and this does not break my GUI.
pfSense works just fine (well, sort of) without an enabled WAN connection, because,remember, when pfSense was started the very first time, right after you installed it, there was NO WAN connection setup, and you had to use the GUI to setup LAN first.

DOH!!  Couldn't see the forest for the trees… Thanks. Looked at it so long and it was right in front of me.

Tested, all fixed. Good show Steve.