Skipping the untrusted certs there is expected in any install. CE is not supported in Azure.

Yes upgrading CE in Azure is not supported. And that includes to Plus. The only supported deployment in Azure is from the tested Netgate image.

Yes, in the dynamic repo system ugrades are supported from the previous two versions. So you can skip one version. For 25.07 that's 24.03 and 24.11 so you would have needed to upgrade to one of those first from 23.09.

Technically is was but as long as we can still build for it without too much difficulty we will try. There are some packages that no linger build for arm32 and are not available there. At some point the work required to make it build will become impractical and it will no longer upgradable.

Yup mpd5/netgraph ignores those errors. It should be fixed by this: https://github.com/pfsense/FreeBSD-src/commit/7a623f854217be1dc7a04ce0b3f47303ea2ce7a9 That's in main so it should land in 25.11/2.9.0.

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

Hmm, interesting. Let me see.....

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.

Where should I block it? In the firewall rules? Thanks a lot! :) spotify premium seruapk

@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, new bug at the last minute forced a rebuild. Should be real soon now though.....

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!

@rfranzke Its waaaay too difficult to blame faulty installation for random crashes. If something like that happens (say, a faulty drive) then crashes are immediate and repeatable. The bsd bug that Steven has found is a better candidate. Obviously its rare, if it wasn't there would be plenty of reports here about it. Now you are able to catch full crash dumps. A debug kernel is the next thing. This is deep waters and you know it. Give it some time.

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

@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