@stephenw10 Thank you for writing and sharing this I appreciate it.

Oh so you still see this even without pfSense involved at all? It must be a problem in the route then. Like something at your ISP routing packets via multiple routes perhaps. What happens if you route traffic over a VPN to somewhere else so you bypass anything the ISP is doing?

Yes you won't see anything in the pkg_log, that only covers the pkg install, but I'd expect to see something logged in the main log. For example when I restart it I see in the main log: Aug 16 02:15:46 php-fpm 77985 /status_services.php: The command '/usr/local/etc/rc.d/wireguardd stop' returned exit code '1', the output was '' Aug 16 02:15:47 kernel wg0: changing name to 'tun_wg0' Aug 16 02:15:47 kernel tun_wg0: link state changed to UP Aug 16 02:15:47 php_wg 19350 /usr/local/pkg/wireguard/includes/wg_service.inc: Gateway, none 'available' for inet6, use the first one configured. 'GIF0_TUNNELV6' If any of those things failed with an error I'd expect to see that there too.

@raidflex said in updating to acme 1.0 breaks system beyond repair: need to restore from backup: maybe uninstall Crowdsec when applying other updates first. It seems like it doesn't help at least from what I see on my system... it changes something.. so it must be definitely reported to their github. I have never experienced that before and crowsec was installed.. maybe with 2.8.0 something have changed

@keyser Clarify "it makes sense if the GEOIP DB has that size" are you referencing the asn data as I have shown or the maxmind data? the asn data takes all of 15 seconds to download and process. Not really any "magic" going on there, you can see the mmdb is only a download referenced and the asn.csv.gz is basically just unzipped. I can't comment on the maxmind data specifically because I don't use for my geo location. But I can see what the code should be doing. seeing your actual log file will help determine where your specific spike may be coming from, but if I had to guess from looking at the code and my timing with respect to the asn parts of it I would guess this is most likely to be an issue with the maxmind parts - timing should be in the log. can you change when it runs ? no, not directly, there is no way to do this without changing the code to target a specific time when it creates the cron job in the first place. No you can't change the timing of the cron job and have it stick, it will eventually just go random again. On the other hand, yes, because I changed the code here so it always creates the same "not so random" time.. runnning at same time every day since this code change first became available in the pfblockerNG update for 24.11 that came out months ago, well before 25.07 curious you originally said "noticed this after upgrading to 25.07 and pfb 3.2.7" were you running the "new" format of asn data before? (would have only been possible if you upgraded from 24.11 with the latest version of pfb installed) you would have entered and ASN key at some point to make it work. did you do that under the prior version and just now with 25.07) it's likely not significant, but then again .... That likely won't help your spike, other than moving it to a different time. I moved it here to a static ("not so random") time for other reasons, nothing to do with system load at the time.. Log files would be helpful. (just the snippet that applies to this time, from extras, error and pfblockerng logs there may be nothing in error or pfblockerng related to the time it is running. .

@mikethiessen Confirmed the behavior you're seeing. I've got a working fix I am testing now, hopefully will push an update tomorrow or Sundat with a more robust check method that properly handles this.

Hmm, interesting question! I don't think I've ever seen an ISP that supported/required that. I assume it works as expected if you set the MTU manually?

@lisandromassera said in VTI IPsec with 3rd party routers that use policy routing: On my side, I rely on SNAT/DNAT, so I need to use a routed/VTI tunnel. Could you explain this statement, please?

Check for open states when it stops passing the traffic. If packets arrive at the LAN port there should be at least a state for it there unless the firewall is blocking it for some reason. If there are states but it never leaves the WAN then it's either: trying to use some other route, has no route at all, is being collected by IPSec, or is blocked outbound for some reason.

The upgrade log shows that UEFI boot entry 0002 was marked as active: Updating boot code... /usr/local/sbin/../libexec/install-boot.sh -b auto -f zfs -s gpt -u da0 gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 2 da0 partcode written to da0p2 bootcode written to da0 ESP /dev/da0p1 mounted on /tmp/stand-test.3IL7PZ 264752KB space remaining on ESP: renaming old bootx64.efi file /efi/boot/bootx64.efi /efi/boot/bootx64-old.efi 264752KB space remaining on ESP: renaming old loader.efi file /etc/freebsd/loader.efi /etc/freebsd/loader-old.efi Copying loader.efi to /EFI/freebsd on ESP Creating UEFI boot entry for FreeBSD Marking UEFI boot entry 0002 active Copying bootx64.efi to /efi/boot on ESP Unmounting and cleaning up temporary mount point Finished updating ESP But that screenshot shows it's trying and failing to boot 0004. So the first thing I would try is setting 0002 as the active boot value.

Yes I have seen that on the igc driver. It really only supports auto-select. For some reason when the driver sets anything it can cause link issues. Also worth noting is that if you have set autoselect and then go back to default it may not reset that since 'default' sets nothing. You may need to reboot to get the NIC and driver back to the actual default state.

Same issue here from 24.11 to 25.11. Clearing /cf/conf/backup was the solution. Thanks for sharing !

@JeGr Hi ERstmal danke für den tollen Hinweis - habe jetzt die Maschinen die in einer VM laufen geupdatet und ja - läuft ... Danke auch für den Hinweis mit der neuen Funktion ! In dem Zusammenhang habe ich noch eine Frage die nicht ganz dem Topic entspricht: Auf der Seite des VPN die wir hier besprechen würde dann auf ein anderes GW geschaltet werden und die Verbindung zur Seite B kommt zustande. Soweit so gut. Wir haben die Situation dass wir an den "seite B" PFsenses auch oft mehrer Wan´s haben. (die meisten mit Fixer IP. Wie kann ich denn erreichen dass Seite A regulär eine Verbindung zum WAN1 auf SeiteB aufbaut und wenn WAN1 auf Seite B offline ist dann Wan2 auf Seite nimmt ? Gibt es dafür irgendeinen Mechanismus ? Grüße

OK we replicated this and are digging...

If it was something upstream the port wouldn't change when you change the pfSense gui port. It pretty much has to be a floating rule or interface group passing that traffic. If you look at the states at the CLI using: pfctl -vss you can see the rule that opened the state. Then check the rules with pfctl -vsr to see what that rule is.

@Gertjan o/ Hey, sorry for the lack of replies, I was on a vacation. Upgrading to 25.07 seems to have fixed the issue. After upgrade, I can see the dynamically assigned DHCP leases under the "Leases" menu: [image: 1755260165183-590d93cd-a189-42d8-be3c-953b70eb0395-image.png] I guess this is solved now.

I thought that issue is resolved, but I just started to get same error: ``` [15-Aug-2025 07:21:41 US/Eastern] PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 20480 bytes) in /usr/local/bin/kea2unbound on line 528 [15-Aug-2025 07:21:50 US/Eastern] PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 20480 bytes) in /usr/local/bin/kea2unbound on line 528e_text Note: pfSense is set to Python mode in DNS/pfBlocker.