I'm pretty sure that RRD still handles the logging side of the monitoring graphs… it's just that it doesn't handle the graphing side of it anymore. I think an external service would be the best way to go, and might provide more flexibility in the data it gives. vnstat is a package that many used under earlier versions of pfSense. It's still under construction for 2.3, but many are awaiting its return. Lots of users who have ISPs with data limits use it to keep track of their usage. The vnstat service that does the monitoring can be installed via pkg in the shell... you just won't have a pretty GUI to show graphs.

@Phereal: Hi, solved this issue by killing the PHP-FPM process by selecting point "16) Restart PHP-FPM" in the ssh menu. Afterwards navigate directly to the address -> https://<ip_address:port>/system_update_settings.php and disable the automatic dashboard auto-update check. Save settings and return to the dashboard. Now again kill the PHP-FPM process via ssh and reload the page. Afterwards remove the "traffic-graph" widget from the dashboard. Reboot the system to verify your changes. Now everything should working fine again. Seems like an PHP-module causing trouble. EDIT: other posts mention problems with some widgets [IP-SEC], if your problems remain, the solution might be to remove all your widgets and then perform a restart. Afterwards it might be possible to add the widgets again.</ip_address:port> Had the same issues and followed the solution proposed by Phereal and it worked. Just wanted to say that if at some point you feel your pfsense is stuck just use 16 on console (obviously not when you will be saving your settings). Thx,

The real issue is getting your untagged traffic off VLAN1. Or at least only using VLAN1 for trusted traffic. Some switches treat VLAN1 as special. Some can only be managed on VLAN1. And if you are going to do that, you might as well just tag it. Tagged and untagged traffic on trunk ports can be problematic as well. Many people try to "tag" VLAN1. That's an oxymoron. It's messy so why do it?

Argh, I just found out that I myself put the immutable flag on for this config file. After turning this off, everything behaves again as expected…..

I can confirm that this works. Just updated to 2.3, and had the same problem, so this is apparently a long-running issue.

@shak2300: I will let you know my result when i get off from work So what were the results if I may ask? ;)

Thanks so much! Somehow the package escaped my quick inspection of available packages. [image: notices.png] [image: notices.png_thumb]

Same problem, and I never fix it, every time I change globals.inc it make some permission errors. Can anyone help us to grant right permisions again ?

@vbentley: Do you have a public or private IP address on your WAN interface now? It is usual to have to configure the ADSL router to change from routing to bridging before PPPoE will work. I now have a public IP on the WAN interface, apparently these devices are configured in 'DHCP Passthrough' mode so it acts as a modem and then passes the connection specific configuration (IP, GW, DNS etc) through to the 'cable' router via DHCP.

Thanks for looking.  No major changes to the network, the load or the firewall config recently.  We don't have a HA pair.  We upgraded to 2.3-RELEASE on the 17th of last month. We do have a cold backup which I swapped over to but we had another crash afterwards,  I uploaded the crash report at about 08:24AM central time.  To be extra safe I did not transfer the config from the running firewall to the backup so it is still running the config from the 17th of last month when we upgraded both firewalls. The new crash looks pretty different from the last one I uploaded I am unsure if it still points towards the bce card/driver.

If we didn't enable the DHCP server by default, we'd be overrun with "I plug in and it doesn't do anything". Many comparable "enterprise" solutions enable DHCP server out of the box with the default config for the same reason. Not going to change, and not "home network or small business", it's more common than not.

Hello, no i do the same way and check connections with additional Linux-Servers and NRPE too. It`s a 2nd-way-Solution but works.

Thanks Chris! I will test it with the next snap.

That sounds like something upstream of your system is blocking all pings on that WAN.