@stephenw10 I've now been able to test 2.8.0-BETA (build date Mon Apr 28 1:42:00 CEST 2025) For now, this seems to have fixed the issue. [image: j6CZACB.png] The dotted line is the installation of 2.8.0. 1 - Data from the original post. 2- Data after uninstalling plugins 3 - 2.8.0 Beta The different form of spikes comes from the pfBlocker update. There is a new cron job at 3pm fetching some data.

Well if anything changed there it's probably something low level that the OS updates could have addressed.

@stephenw10 thanks, I think I figured it out. I assigned a new interface, kept the default name of OPT3. I had to enable it though, when disabling I lost WAN immediately. I left the IP type as none and hard-coded the speed to 2500base-T. I guess I need to just wait another day or two and see what happens.

It should ask you to reassign the NICs before it reboots in the GUI. But of you have laggs and VLANs I would just edit them in the config before restoring it.

@stephenw10 internet -- isp device - 10.100.102.0/24 -- .111 pfsense --- 192.168.1.0/24 That's what I think he means to say.

@Stef_R Can't help as I do not do VLAN and have avoided their deployment. I have so far found no good use for them. Ted

I think I have now received enough cautionary feedback to convince me that it was an ill-conceived proposition. I will abandon the “shared” IP plan and follow better, if not good, practice. I like the alias suggestion and that will overcome my reservations about “redundancy” in rules. Thanks to all for your heads up.

I finally solved this problem - so thought I'd update this topic just in case it helps someone else ! The unstable WAN MTU problem persisted through a number of pfSense upgrades, and was still an issue on version 2.7.2-RELEASE. The thing that fixed it was to install the Realtek drivers using - pkg install -y realtek-re-kmod which installed - realtek-re-kmod-198.00_3 Kernel driver for Realtek PCIe Ethernet Controllers and then setting the WAN MTU to 1508 (including +8 bytes for PPP overhead). After a day of experimenting, the system seems stable, and the WAN interface MTU is 1500

It could just be the modem crapping out, yes. Can you try a different port at the pfSense end? Can you test putting a switch in between the pfSense WAN and the modem? That would prove which end is dropping the link.

@naiw the instructions from Vultr sound like targeted at Linux systems (ip a, /etc/sysconfig/ -> RedHat). You may ask them for FreeBSD instructions or better for pfSense.. But I don't think automatic config will work with pfSense at all. They assign the second IP to your instance and you have to manually create an alias, as @stephenw10 mentioned. More infos (although old, 2016): On this forum: Two totally separate IP's on WAN - how to configure on VULTR. The result was the same, create an alias.

Thank you both for the responses. This makes sense. I had not thought that ping might be disabled on the gateway. I took @JKnott suggestion to find the first upstream server using tracert. All is well again!

Any alerts/errors shown in the gui when you logged back in? Anything in the system logs?

You don't need a leading dot for that.

@patient0 Hi, Thanks for the your information. Now we tested with intel NIC. Its working now.

Yup the 8200 does not have eMMC.

Mmm, almost certainly a link negotiation issue then. On igc NICs the options there are limited because it can only link using auto-negotiation. You can set the available speeds it negotiates at which is what the speed setting in the gui does.

You may need to reboot twice to seen that set since it only gets; applied at boot. However, yes, there is a bug on some systems where the default values are always used. It only happens on some filesystems where a race condition occurs. It's fixed in 25.03-Beta. When using RAM Disks I usually start out at double the default values. 1G + 2G is very large. If you have hungry packages though you may need large drives, but not that big!

Yes, you can set it as a gateway. You don't have to route anything to it if there's no subnet behind that peer to route to,.