Huh, interesting I missed that.

Yup. Using VLAN1 bad! https://docs.netgate.com/pfsense/en/latest/vlan/security.html#using-the-default-vlan-1 Steve

Yup, that would work. Traffic blocked by Snort shouldn't appear under the default block rule though. Snort has it's own rule it blocks with in Legacy mode. Or in in-line mode it blocks before the firewall rules are parsed anyway. Steve

@stephenw10 I will make sure it's set to that, thank you so much for helping me through this! I guess we can close the issue. I think I'm good now. Appreciate it.

@gertjan Thank you. Much easier to navigate. It never occurred to me to access via SSH other than from the serial port. The firewall is located in an inhospitable location that makes it difficult to use a direct connection. I'm on now using Putty.

@stephenw10 Yes, you are correct. That was impacting the system. I first setup a test system in lab with same 2.6 config and performed a webgui update 2.6 to 2.7.0-DEVELOPMENT. On 2.7.0-DEVELOPMENT the system does not exhibit the issues described in first post. On production machine I followed your instructions and applied patch "Disable pf counter data preservation to temporarily work around latency when reloading large rulesets (Redmine #12827)". Issue appears resolved. Thank you!

Or roll back to a snapshot in Proxmox if you have one.

Ok I managed to solve the issue. The problem was that in the VM Hypervisor (Proxmox) I accidentally enabled „ballooning“ memory (which means it will remove memory on the fly if it detects that the VM is not using it). I disabled it and now it all works like a charm. I guess the GUI (and myself) was confused that the RAM was removed from the VM while running, therefore showing memory usage „of 11GB“ while in reality it only had way less memory at this point.

Basically because it's extremely low priority compared with many other things. It doesn't look that hard to do though. Pull requests accepted. You could use the firewall logs widget on the dashboard instead where it is configurable. Steve

You don't want a static route here because pfSense would have an interface in that subnet not access it via some other gateway on the LAN. You would disable the other interface then add back that subnet as a VIP on the existing interface so both subnets now exist on that interface. Obviously you would need to remove that to be able to re-enable the other interface. Steve

@stephenw10 Thanks for the info! I am hoping you can provide a cloud-based control panel at some point. Am now looking at using the Dynamic DNS function for each PfSense appliance as we have GoDaddy for Registrar and it will not cost me to try it. I'm thinking it will probably construed as 'too clunky', but I'm hoping it will be received as a 'usable' option for my small offices. Thanks again to all who provided input!!

Even after installing and uninstalling again? You can check the pkg log in /conf. Squid has a bunch of parts which makes it more susceptible to issues if part of the script fails for any reason. Failing twice would be unusual though. Steve

@dobby_ Firewall > Traffic Shaper > Limiters LW has a video explaining this also link text

The majority of VPN tunnels? Show as disconnected when they are actually up?

@stephenw10 So if I try to access 192.168.5.6 (an iDrac that sits behind the pfSense box) I get "192.168.5.6 took too long to respond." but I dont see the firewall logging anything like it did before (see below). The 5.6 address is perfectly accessable by a laptop sitting behind the pfSense box, and the laptop can access the external web just fine. [image: 1666135100503-2022-10-18_16h18_17-resized.png]

@globus243 I've had a similar experience, which may or may not be related. Netgate 5100 locks up shortly after either 6 a.m. or 6 p.m. but not always on the same day of the week. Finally traced the problem to pfblockerng-devel updating its block lists. For some reason this results in "insufficient swap space," even though no swap space is shown in use. My wife first noticed this phenomenon because her Amazon Alexa console, which is connected wirelessly, shows "no network." I'm not competent to delve into what's actually happening, so I just reboot the firewall and everything is fine.

Mmm, those look like real upstream issues unless you have something that shows otherwise. Steve