@dennypage said in netisr running close to 100% on a single core: @Gustas said in netisr running close to 100% on a single core: Do you have both WAN and LAN enabled as Monitored Interfaces in ntopng by chance? Yes, we do. Can that be the issue? Certainly a contributor. There is a caution in the pfSense ntopng package when selection interfaces to monitor that says "It is generally not recommended to monitor WAN interfaces." At a minimum, it will double your load. You should remove any WAN interfaces from the list of Monitored Interfaces. Also, if you have any form of active discovery enabled inside ntopng itself, be sure to turn that off as well. Sorry, I just checked and monitoring in ntop is configured only for internal interfaces, WAN is not being monitored. Sorry for misleading you.

The VLAN you would need would be on the switch in order to separate the WAN and LAN network segments. Or connect the pfSense WAN to whatever upstream router you have directly so the switch is only the LAN.

You'll need to use the manual firewall rule option with sloppy states and TCP flags set in the advanced rules section like: https://docs.netgate.com/pfsense/en/latest/troubleshooting/asymmetric-routing.html#manual-fix You may need to add that as an floating rule with direction any and source/destination values that match traffic both ways between the old and new subnets to be sure. But it should be pretty clear from the firewall logs what traffic is actually being blocked.

@stephenw10 yeah makes no sense to set that to something. Because if you have no san setup on the cert your doing, then the san should be blank.. If you put a space in for your san you get this error. [image: 1754309398040-blank.jpg]

Yup that ^. If the NICs are are same driver and there aren't fewer then it should just boot normally. But be aware it's possible they may be parsed in a different order so be sure to test. But if it's a Plus install the NDI will have changed so you will no longer have access o the pkg repos until that is registered.

@ipguy Some services dont max out to the OS limit and have their own internal limit, but if it is the case then I dont know how you would raise it, I think a VPN hitting the listen queue limit is highly unlikely unless you running a public VPN server that has gone viral or something. So it seems odd to me you have this problem in the first place. 'netstat -L' shows listen queues, looks like OpenVPN has a limit of 1. My OpenVPN processes are running in client mode though. There is nothing in the manpage to tune it, and I found a very old dev post from people asking for the limit to be raised, it very likely is compiled in to the binary.

@johnpoz said in Strange DNS Issue: Could be a peering problem your isp currently having.. But yeah if you are resolving and can not talk to the owning NS for a domain, your not going to be able to resolve anything from them. I came to the same conclusion as it's now miraculously working! I knew I dotted all my i's and crossed my t's and coming up with nothing on my end lead to me to believe it was something upstream. Thanks to everyone that chimed in!

@patient0 just a quick note, I updated that script to operate correctly on newer versions of pfSense (2.8/25.07). Let me know if you run into any issues.

Just a quick note, I updated my script to operate correctly on newer versions of pfSense (2.8/25.07). Let me know if you encounter any issues.

@ser There is still the IP block option which really BLOCK's it, but is maybe also a little cumbersome. You could look into using the package pfBlockerNG and then select one of two paths: 1: If you can force all clients to only use your pfSense as DNS you could block all DNS lookups that relates to Spotify. That would effectively either require a some good google-foo to find those names, or alternatively setup at test and have your DNS server log all queries when Spotify opens. 2: If Actual blocking is needed rather than just preventing nameresolution, then pfBlockerNG can also be configured to import lists that contains IP addresses. I'm sure there is some site somewhere that maintains Spotify's IP in a list - alternatively you could attempt to fetch the ASN ownership of IP blocks that Spotify owns, ,but that might not cut it (CDN's and such...) Option 1 I ususally the easiest and best working model even though it only prevents nameresolution rather than actual blocking.

@louis2 Hello ! Thank you for your work with pimd ! I have been able to test your pimd binary, it seem to work but I still have the same bug I discribed here When starting PIMD, after a few seconds it works as it should, seeing multicast sources and routing it if needed. But after about 3 minutes, PIMD is "loosing" multicast sources even if pfSense still receive this multicast traffic (packet capures, and network traffic). PIMD does not "receive" multicast source anymore. Restarting PIMD makes it see again multicast sources until it looses it again after about 3 minutes. @louis2 do you have the same problem ? I really do not understand why I have this

@dennypage Thanks for the info. Yeah, it appears somewhat complicated with IPSEC. ARD works over IPSEC but without live status and system information, which is what we had hoped to get working over our old IPSEC tunnels. ARD works fully with OPENVPN for us. Has anybody else had some successes here? Thanks, Alfredo

Indeed, not an easy way I'm aware of. I'd just reinstall clean to be honest. However you may need to wait for the 1.1 installer that has a 'low resource' mode to allow writing to a 4G eMMC.

Unless you need to accept inbound connections there it should only be an outbound NAT rule. Even if you did have inbound connections a port forward is often better. You shouldn't need to manually add any rules though as long as the gateway is added into the new interface. That will trigger the auto outbound rule to be added.

@SteveITS said in 2.8.0 fails to save SMTP Notification password: The test button text does say, "The last SAVED values will be used, not necessarily the values entered here." Ah, but that's not what actually happens. The just-entered new password IS used for the test, but then forgotten by the time you scroll down and "Save".

@stephenw10 Thanks. Just finished the reinstall and have Plus.

Hmm, you should be able to check that. When you add a server there it should be added to /etc/resolv.conf. If it has a gateway set for it you should see a static route added for the server IP via that gateway in the routing table (Diag > Routes).

Yes both nodes would have to have the same WG config.

@ebcdic What software/hardware are you using to publish? If you haven't looked at WeeWX, you might give it a try as it would certainly address the issue. Just a thought.