I reviewed my changes from yesterday and confirmed only those changes i stated were done. Considering the bulk of the reboots happened while i was asleep and as far as i know i don't sleep walk (maybe i do) it wasn't anything I've done overnight to cause those reboots.

As of now the fix is ready but will be released with 24.08?
The workaround is to disable pflow?

Yes, in the original bug report it only affected IPFIX which is why I initially thought it could not be that. But Kristof believes the root cause is the same here, the fix is the same.

It is odd though that you were not hitting it before though. Something must have changed. Hard to imagine a port forward would have done it.

The only thing that "recently" changed was a NAT Port Forward rule and DHCP settings on 9/5 @ 09:32am EDT

I see there is a patch created.

Something must have changed though for it to suddenly start hitting it.

The restart events are below
9/5 - 3:20pm EDT
9/5 - 3:40pm EDT
9/5 - 11:50pm EDT
9/6 - 03:30am EDT
9/6 - 05:40am EDT
9/6 - 07:00am EDT

This looks like a bug in flow to me, we are looking into it.

How often is it panicking? Can you test disabling pflow?

The Auto Configuration Backup / Restore has no backups for the device. Is this normal?

This started yesterday during the work day so for sure no changes. Later that night i updated a pfblocker DNSBL feed but its not related to pfblocker.

Anything else i can check? Any other clues in the crash dumps?

What else has changed?

Backtrace:

db:1:pfs> bt
Tracing pid 12 tid 100043 td 0xfffff80001688740
kdb_enter() at kdb_enter+0x33/frame 0xfffffe00850ca270
panic() at panic+0x43/frame 0xfffffe00850ca2d0
trap_fatal() at trap_fatal+0x40f/frame 0xfffffe00850ca330
trap_pfault() at trap_pfault+0x4f/frame 0xfffffe00850ca390
calltrap() at calltrap+0x8/frame 0xfffffe00850ca390
--- trap 0xc, rip = 0xffffffff846626a7, rsp = 0xfffffe00850ca460, rbp = 0xfffffe00850ca490 ---
export_pflow() at export_pflow+0x77/frame 0xfffffe00850ca490
pf_detach_state() at pf_detach_state+0x45b/frame 0xfffffe00850ca4d0
pf_state_insert() at pf_state_insert+0x854/frame 0xfffffe00850ca570
pf_test_rule() at pf_test_rule+0x28f8/frame 0xfffffe00850ca9c0
pf_test() at pf_test+0x1382/frame 0xfffffe00850cab90
pf_check_out() at pf_check_out+0x22/frame 0xfffffe00850cabb0
pfil_mbuf_out() at pfil_mbuf_out+0x38/frame 0xfffffe00850cabe0
ip_output() at ip_output+0xb60/frame 0xfffffe00850cace0
ip_forward() at ip_forward+0x3c2/frame 0xfffffe00850cad90
ip_input() at ip_input+0x705/frame 0xfffffe00850cadf0
swi_net() at swi_net+0x138/frame 0xfffffe00850cae60
ithread_loop() at ithread_loop+0x257/frame 0xfffffe00850caef0
fork_exit() at fork_exit+0x7f/frame 0xfffffe00850caf30
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00850caf30
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---

Looks like an issue in pflow, do you have that enabled?

The only other thing I see is:
<6>pid 67263 (pftop), jid 0, uid 0: exited on signal 6 (core dumped)
That could just be a symptom of the panic though.

SSD is still in a good state

=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED