Why shouldn't they, what did you try to prevent it? Hint: use the "Block Ads" feature of modern browsers.

Post this issue to a new thread in either General pfSense Questions or Packages: Traffic Monitoring.

Thank you for the inputs guys really appreciate it, for the meantime, I just disable the public access and push to use OpenVPN instead.

@Grimson Thanks, that did it, I had forwarding mode on pfsense but not actually configured.

None of these warrant individual threads. I merged them all. None of these are specific to pfSense. They are between your hardware and FreeBSD. Take this to FreeBSD.

Move VPN server A out of the LAN onto a different interface. Avoids asymmetric routing problems. Have pfSense connect directly to VPN server B would also do that. Remove VPN server A entirely and use pfSense for that. Steve

@stephenw10 yep, change to mbr and it is responding per the instructions. vesa error gone, with 1280 after initial boot pass

One thing you could do is set up a filter on your email app to toss those messages in the trash.

@stephenw10 Well I was thinking of it but now I realize I can't. My MB does not have a x4 port and I cannot use the x16 for anything other than video (older MB). So I need to find a good x1 NIC and from what I can tell those only come with 1 port.

I figured it out, I forgot some settings elsewhere

@Grimson the rest of the server is pretty much idle, I stopped and closed everything for the tests. Basically it was just this pfSense VM running on a 20 cores CPU +16GB Ram on Supermicro X10SRL-F (Intel 612 chipset). Don't you think it should get the full gigabit? The VM has the NIC on passthrough and on RAID1 SSD

Mostly likely it lost power and hence whatever was in the RAM disks at that time. Yes the data is written to permanent storage when it is shutdown gracefully. Steve

It's not the broadcast address because the broadcast address on the interface is .63 There is NO WAY for an interface to know .255 is a broadcast address if it is on subnet .0/26 If there are devices on a network that were designed by morons that insist on using /24, then you either remove the devices from the network or you use /24. Period. You don't block the traffic or try to work around it in other silly ways.

If you want to keep using the resolver, Unbound, you can switch that to forwarding mode instead. That allows you to use DNDBL for example. Or in 2.4.4+ you can set a failover gateway group as the default gateway (cannot be a load-balancing group) and keep using Unbound in resolving mode. Steve

Hmm, that sure looks like something hardware offload related. Was that with both switches still in between? If it was it could be failing negotiate between those switches correctly. I'd have to guess that 100Mb switch is doing something odd. Can you test without it? Steve