@stephenw10 it's a pretty quick test so I'm not sure it's a good capture

CPU 0: 11.8% user, 0.0% nice, 28.6% system, 0.0% interrupt, 59.6% idle
CPU 1: 3.9% user, 0.0% nice, 6.3% system, 10.2% interrupt, 79.6% idle
CPU 2: 12.2% user, 0.0% nice, 7.8% system, 7.1% interrupt, 72.9% idle
CPU 3: 5.9% user, 0.0% nice, 6.3% system, 11.0% interrupt, 76.9% idle
CPU 4: 10.6% user, 0.0% nice, 7.8% system, 8.2% interrupt, 73.3% idle
CPU 5: 4.7% user, 0.0% nice, 8.6% system, 12.9% interrupt, 73.7% idle
CPU 6: 5.1% user, 0.0% nice, 6.7% system, 17.3% interrupt, 71.0% idle
CPU 7: 4.3% user, 0.0% nice, 7.1% system, 11.0% interrupt, 77.6% idle

but it certainly looks clean

@stephenw10 Thanks.

The long SMART test was clean, so, once my son is back at school next week, I'll try a reinstall, bootstrapping it with my latest config.xml - https://docs.netgate.com/pfsense/en/latest/backup/restore-during-install.html.

When I take it down I'll check the seating of the mSATA before reloading the software. If it fails again, I'll look at replacing the disk.

@michmoor its getting a bit long in the tooth.. Sometime round end of 2017, early 2018..

edit: found this old post, pictures must of gotten lost in one of the previous forum updates, but here is post when I got it

https://forum.netgate.com/post/740935

So would been right around 12/13/2017 ;)

@stephenw10 yup that would be another way @CreationGuy but his rule above his lan allow should trigger and not log that igmp traffic.. and no other rules should be evaluated.. So it shouldn't still see the igmp traffic on his lan allow and block it because of the IP options setting.

@viragomann
THANK YOU!

I will study every word of your message and continue my inspection.

I'll come back here with the rest, and if I finally come up with a solution that works I'll put it here completely for others too.

@michmoor Currently looking for a decent B+M key SSD to replace it with. I have a remote pfSense instance running on Protectli hardware. About to replace that with a Samsung Evo 870 when I'm on-site. The current WD one it has isn't in the smartdb. The wear indicator is '101' which is clearly wrong.

Yes, when 2.8 is released you can upgrade to it from 2.8-beta.

@SteveITS I wanted to give a like, but it says I am not a 5 yet. Not sure how this forum’s ranking works, but know that you get a thumbs up! Thanks again

@stephenw10 Done - https://redmine.pfsense.org/issues/16144 - but failed with the text formatting of console output. I've put it down as a Configuration Backend issue but I was not sure which category to use. Feel free to change it.

You have a mismatch between the OS (pfSense) and the installed nut package. Be sure to have the right version selected in updates, then remove and re-install the nut package.

@johnpoz Thank you for your answer.

First of all I saw that documentation page. It says "A safe assumption is approximately 1K of memory per entry to be conservative." so I assumed that I could use that number.

I love pfsense (I have four Netgate devices), but there are some issues with it, and this is one of them. It would have been nice to have this information in the GUI, or perhaps auto-adjusted limits.

Adding 200 000 more to the limit fixed my problem.

@louis2 so out of curiosity what do you think this gets you?

Is this a storage network that your routing? Are you seeing under performance on your 10ge interface with standard 1500 mtu and your trying to increase the performance? From what to what, from where to where? Are you using iSCSI over this connection? etc..

You know jumbo were a thing back in the day when the cpu had to process, so larger mtu meant less processing - but today, really it more of a hassle than anything.

If you had some SAN or something, and your NAS front end needed to get to its actual store over the 10ge link - and you were moving large chunks of data..

I would love to see your testing of 1500 vs jumbo in your transferring of data - where jumbo made such a significant difference that it makes sense to mess around with it..

@SteveITS

that answered it. many thanks!

FreeBSD pfSense 15.0-CURRENT FreeBSD 15.0-CURRENT #0 plus-RELENG_25_03-n256497-da24eca0fcd2: Mon Apr 14 19:32:49 UTC 2025 root@freebsd:/var/jenkins/workspace/pfSense-Plus-snapshots-25_03-main/obj/amd64/ILoDLiJx/var/jenkins/workspace/pfSense-Plus-snapshots-25_03-main/sources/FreeBSD-src-plus-RELENG_25_03/amd64.amd64/sys/pfSense amd64

Thought I should add some info of my setup:

I have 4 WAN interfaces, all dual-stack IPv4 and IPv6 and all with a delegated /48 subnet. I use the IPv6 prefix of the first WAN for all LAN interfaces, I use NPT to translate those to the other 3 WAN prefixes if used. I use a failover group, with each WAN interfaces in a different tier.

The ISP link causing this issue is not the first interface, so i am not using that /48 prefix at the LAN. This troublesome ISP link is the only one where IPv6 is native on the WAN interface and they send NS from a GUA. The other IPv6 interfaces are either L2TP tunnels, or the ISP uses a link-local address for it's Network Solicitation/Advertisements.

It appears others have a much simpler setup to myself and still see the issue.

If I shutdown my pfsense VM, and start up a simple OpenWrt VM, everything is stable and the IPv6 interface just works for this ISP, NA's are sent correctly to the GUA. All I do is swap one VM to another VM of a different OS, no other network changes are made.

To me, the only common factor when NA's are not sent (without some tinkering) is when I'm using pfsense and the ISP sends NS from a GUA. This does appear to be typical behavour from Juniper switches, as I also see this issue on a different test bed.

I have also just discovered, during this issue on this version of pfsense, that opening diagnostics->NDP table on pfsense UI causes the UI to lockup and eventually crash. It sends me to a crash report but that just says

Crash report begins. Anonymous machine information: amd64 15.0-CURRENT FreeBSD 15.0-CURRENT #0 plus-RELENG_25_03-n256497-da24eca0fcd2: Mon Apr 14 19:32:49 UTC 2025 root@freebsd:/var/jenkins/workspace/pfSense-Plus-snapshots-25_03-main/obj/amd64/ILoDLiJx/var/jenkins/workspace/pfSense-Plus-snapshots-25_03-main/sources/FreeB Crash report details: No PHP errors found. No FreeBSD crash data found.

I'm unsure if this is related.

@Jarhead said in [Newbie] Setup VLANs - connecting clients to it?:

You have port 4 on the router going to port 1 on the switch, correct?

correct

@Jarhead said in [Newbie] Setup VLANs - connecting clients to it?:

PVID 1 on port 1 is not a problem, that would just carry your untagged traffic on igc3.

check

@Jarhead said in [Newbie] Setup VLANs - connecting clients to it?:

Turn on the DHCP server on all the vlans and then plug in to switchport 5, do you get an address?

I don't understand what just happened. I have switched on DHCP for all VLANs and have received a correct IP on the corresponding ports and was also able to call up the interface and reach the gateway via ping.

I then switched the DHCP servers off again, manually set IP addresses on all ports again for the client to match the port and tested... Still works.

Apart from that, I have not made any other changes.

So yes, it works now - so I seem to have understood the principle correctly after all. Shall we blame the switch? :D

BIG THANKS TO YOU! You rarely experience such patience with a newbie these days!

@pozolero ¿Qué ves en la página "Services / DHCP Server / WAN" debajo la pestaña WAN? ¿Es habilidado el servidor DHCP?

@ngr2001 You can confirm update task from Services / Cron / Settings. I see command /usr/bin/nice -n20 /usr/local/bin/php-cgi -f /usr/local/pkg/suricata/suricata_geoipupdate.php scheduled for every day @ 6:00 AM.

@VioletDragon
How did you configure the WAN IPs?

I cannot think of any reason, why a OpenVPN server should not work on localhost with port 1194 forwarded from the WAN IP.

Still waiting on the logs to see, what's the server complaining.

@siegmarb said in dpinger not reliable - ping request/replies:

Apr 8 07:07:12 dpinger 89446 GW_KD_DH 1.1.1.1: Alarm latency 27627us stddev 14386us loss 21%
Apr 9 11:07:14 dpinger 89446 GW_KD_DH 1.1.1.1: Clear latency 22638us stddev 53358us loss 5%
Apr 15 01:00:42 dpinger 89446 GW_KD_DH 1.1.1.1: Alarm latency 21509us stddev 5210us loss 22%
Apr 15 01:06:52 dpinger 89446 GW_KD_DH 1.1.1.1: Alarm latency 1293341us stddev 881246us loss 95%
Apr 15 01:07:07 dpinger 89446 GW_KD_DH 1.1.1.1: Alarm latency 243671us stddev 600909us loss 70%
Apr 15 01:07:48 dpinger 89446 GW_KD_DH 1.1.1.1: Clear latency 93734us stddev 349188us loss 5%
Apr 15 06:30:21 dpinger 89446 GW_KD_DH 1.1.1.1: Alarm latency 28365us stddev 7087us loss 21%
Apr 15 06:34:35 dpinger 89446 GW_KD_DH 1.1.1.1: Clear latency 28547us stddev 86447us loss 5%
Apr 16 10:44:07 dpinger 89446 GW_KD_DH 1.1.1.1: Alarm latency 28632us stddev 35032us loss 22%

dpinger not reliable - ping request/replies

You can remove the word 'not'. 😊
Test for yourself : Go here : Diagnostics > Packet Capture
and select (Capture Options) your WAN interface,
Set "View Options" to High,
Set PROTOCOL to PING, and ETHERTYPE to IPv4.
Hit the green Start.

From now on, you'll see that "ICMP echo requests" are send. It's the dpinger process that pings ^^
These "ICMP echo requests" are send to an upstream gateway (you'll see the IP in the capture also) and if all goes well, and answer "ICMP echo reply" comes back.
The duration between the moment a packet was send and the answer comes back is known as :

89ddd9ad-0612-4ee8-afa5-c61c05cdd4cb-image.png

You'll se the avarage time it took, and te variation.
The simple fact that packets did come back is n enough to mark the interface as "Online".

So, now you know dpinger is reliable ^^
Less reliable is probably your connection, as you've shown yourself : ICMP packets are (always) send, but not all come back. That said, a couple over several days ... that not that bad.
Or : maybe the gateway to where the packets where send to was very busy and missed a packet, so it didn't reply back.

Be aware that the ICMP packets have less priority as other TCP or UDP packets, so if a ICMP gets discarded, then that's not the end of the world. It can happen.
If your connection is saturated, then its normal that you see that a ICMP packet didn't make it back.