Thank you @stephenw10 for the assistance.

I disabled pimd and still saw the same output. I cannot disable avahi since I need it. I disabled udp broadcast package now for debugging and to check again but I need udp package to be running normally.

Oh, right, yes apply the patch as it says in the instructions in the SA.

Users on pfSense Plus version 23.09.1 and pfSense CE version 2.7.2 may apply the fix from the recommended patches list in the System Patches package.

Screenshot from 2024-04-26 17-13-14.png

@4o4rh

You mean these :

8a6cb976-dabe-4b43-9f40-d88c21a92d53-image.png

I'm using 24.03, and I see them.

Probably because :

6732fc99-50c6-4b11-ac0e-f0ffdf8eb769-image.png

@stephenw10 Thank you. I'll do a force fsck and see if it resolves the issue. Otherwise, will replace the drive.

@DamienS that’s without a firewall. Usually I expect about halfway between the numbers listed:

L3 Forwarding

IPERF3 Traffic: 927 Mbps
IMIX Traffic: 472 Mbps

Firewall (10k ACLs)

IPERF3 Traffic: 607 Mbps
IMIX Traffic: 191 Mbps

The 1100 is one switch with VLANs to separate the ports.

@stephenw10 I managed to pull the config. For some reason it was empty? Perhaps when I tried to reload last known configuration? Luckily I had plenty of backups, so thanks for your help.

@chudak there was another thread, already a bug put in for it

https://redmine.pfsense.org/issues/15439

Ok fix from @jimp incoming. Working for me here. Should be up shortly....

@stephenw10 No, not a slow disk... It's a SATA III SSD... It was a budget build, but more than adequate for what I'm doing.

https://www.newegg.com/kingston-a400-120gb/p/N82E16820242399?Item=N82E16820242399

This does seem to have stopped the issue, so I'm going to wipe/reinstall NTOPNG, and leave it disabled. I can enable it if I want to do some troubleshooting, but in a home environment, it doesn't justify the wear and tear on the SSD to run all the time.

If I can do anything to help troubleshoot why it would kill the browsing altogether, let me know. I appreciate the insight into figuring this out. 👍

@stephenw10 Thank you for the quick response and confirmation.

@stephenw10
recreating the wireguard configuration solved it.
Smells like a protonVPN issue but cant prove it with data..just feelings, haha.

@stephenw10 said in How to limit bandwidth for social media:

Yes it updates them. You can check the pfBlocker logs:

===[ IPv4 Process ]================================================= [ Spamhaus_drop_v4 ] static hold. [ Google_v4 ] Downloading update . Downloading ASN: 15169... completed . completed .. [ Facebook_v4 ] Downloading update [ 04/15/24 00:00:37 ] . Downloading ASN: 32934... completed . completed .. [ Netflix_v4 ] Downloading update [ 04/15/24 00:00:39 ] . Downloading ASN: 2906... completed . completed .. [ Test_Range_custom_v4 ] exists. [ 04/15/24 00:00:40 ] [ o365_alias_v4 ] exists.

Awesome. Thank you very much sir !!!!

@johnpoz I ended up virtualizing pfsense ce and a vlan on upstream pfsense as WAN. Thanks for your suggestion and help.

Hmm, like how long exactly? We had to bump the verification timeout value to accommodate this issue though it's still only 300s (5mins).

But, yes, it clearly shouldn't do that.

All, I had to give up and open a TAC-lite support case to get some clues as to how to do this. Short story: reconfigure your WAN interface to be a local interface, Static IP, 192.16.x.1/24. Then add a fw rule to allow this network to get to 192.168.1.1. Then plug into the WAN port and configure the LAN ports. Then undo your WAN configuration; change it back to DHCP/DHCP6 like it was. Attached are my detailed step-by-step notes on how I did it and what I ended up with.
note-to-netgate.txt

Since 23.09 the upgrade system has (finally) switched to requiring the use actively select the new repo branch in order to upgrade. That prevents accidentally pulling packages from the new branch before upgrading for example. The dashboard check update check can now check all available repo branches so it show an upgrade there.
Once you have selected the new branch you can then upgrade from the console in the normal way. There is no way (currently) to switch the repo branch from the CLI.

There is an issue with some pkgs in the new upgrade system if you're running ZFS. The new system creates a new BE and runs most of the upgrade process in to the new BE before rebooting which allows much shorter downtime. However some packages have to run their install scripts after the boot and currently they try to do that before the network has finished configuring. That results in connection failures if they try to update signatures like that: https://redmine.pfsense.org/issues/15396

The new version of pfSense-upgrade reports the status check more accurately. At that point, immediately after upgrading, pkg may still be running in the background completing package installs etc. Until that finishes the update check cannot run and correctly reports the check data as invalid. As soon as the other pkg processes complete it will check and show the update status. In previous versions it would show
the system as up to date there even if it was actually unable to check.

So it sounds like everything you saw is expected.

Steve

no difference when using winscribe vpn.......strange but I guess its still ultimately using a hyper-v vm network card/vswitch etc.

Yup, PPPoE support is not in there yet but it's coming.

One of the big advantages of the Net Installer is that it can always present the latest version so you usually don't need to get a new image.

@keyser
good to know, I kept them in the past because there are only use 32K...

@detox it is being worked on and is, in-fact, the major focus of the next release.