@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.

It's less about Plus vs CE and more about the config format.

Look at the table here: https://docs.netgate.com/pfsense/en/latest/releases/versions.html

Note the "Config Rev" column.

You can restore an older config revision to a system with a newer revision but not vice versa.

See https://docs.netgate.com/pfsense/en/latest/backup/restore-different-version.html for details.

Going from CE to Plus there isn't any concern about config items either.

Going from Plus to CE anything specific to Plus would end up just sitting unused in the configuration, it wouldn't be removed in most cases.

@stephenw10
Thank you, Stephen, appreciate it!

Hmm, yes the fact it's ARPing for the LAN side gateway and the gateway is responding but it's NOT in the pfSense table does seem to point at the NIC not passing traffic. At least inbound.

Yet it appears in a packet capture so the driver is seeing it. 🤔

@nick-loenders
Yes, you can do this. But to be accurate, you have to forward a certain destination IP and port to a target IP and port, not domains, pfSense can't see them.

So you forward
81.82.120.21:443 to 192.168.10.11:21443
81.82.120.22:443 to 192.168.10.11:22443
81.82.121.23:443 to 192.168.10.11:23443

OutBound NAT.

The /1 route being passed by the VPN provider is a more precise route than the default route which is /0. So it would be used in preference.

That's likely why you see the DNS states on the VPN interface. That should work.

I prefer to set the VPN client not to pull routes from the server and then add policy routing for clients/subnets I want to use the VPN.

@stephenw10 said in Exceeded input buffer (on reboot):

It could well have ended up with a newer boot loader when starting from 2.7.2. That could explain the difference.

Possibly as I think most times I saw it I had restored from 2.6.x clean install restore and then upgraded. It is certainly an odd error as searching for it exactly yields few results. If it reoccurs I will come back here with a video or screenshot.

@stephenw10 said in Large packet sizes fail to send to internet:

You can use the new Net Installer to install Plus directly if the NDI is eligible.

I had missed that post when it came out. That certainly resolves my concerns once it makes it out of beta. In the meantime it looks like things are stable again and we found the oddities that were causing issues. Thank you for your assistance.

@SteveITS

I'll have to chalk it up to me being super tired yesterday. I honestly did not see that anywhere -- but I've registered now and submitted my comment.

@stephenw10 hahah - that could be staged, but it wouldn't be unthinkable that was a legit conversation... I take it that was some video off his doorbell camera or something.

Pretty funny either way. But more funny if actually legit conversation.