Messages

Any chance a fix would be upstreamed in FreeBSD 15.1/OPNsense 26.7 ?

Thanks for looking into this, but I am afraid the patch did not work, I am still encountering kernel panic

Code Select Expand

root@OPNsense:~ # uname -ar
FreeBSD OPNsense.local.lan 14.3-RELEASE-p9 FreeBSD 14.3-RELEASE-p9 in6_selecthlim-n272036-8c8ffb05214b SMP amd64


Code Select Expand

[296]
[296]
[296] Fatal trap 12: page fault while in kernel mode
[296] cpuid = 5; apic id = 0a
[296] fault virtual address = 0x0
[296] fault code = supervisor read data, page not present
[296] instruction pointer = 0x20:0xffffffff80e15bc9
[296] stack pointer         = 0x28:0xfffffe0145bf28b0
[296] frame pointer         = 0x28:0xfffffe0145bf2aa0
[296] code segment = base 0x0, limit 0xfffff, type 0x1b
[296] = DPL 0, pres 1, long 1, def32 0, gran 1
[296] processor eflags = interrupt enabled, resume, IOPL = 0
[296] current process = 46103 (tailscaled)
[296] rdi: fffff80233b26b00 rsi: fffffe0145bf2788 rdx: 0000000000000000
[296] rcx: fffff801e1139c00  r8: 00000000ffffffbd  r9: fffffe0145bf29a0
[296] rax: 0000000000000000 rbx: 0000000000000000 rbp: fffffe0145bf2aa0
[296] r10: fffff80433b539c0 r11: fffff80691d6b000 r12: fffff802820ec370
[296] r13: fffff803909cfbb8 r14: 0000000000000000 r15: fffff801d5026800
[296] trap number = 12
[296] panic: page fault
[296] cpuid = 5
[296] time = 1774462917
[296] KDB: stack backtrace:
[296] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0145bf2600
[296] vpanic() at vpanic+0x161/frame 0xfffffe0145bf2730
[296] panic() at panic+0x43/frame 0xfffffe0145bf2790
[296] trap_pfault() at trap_pfault+0x3da/frame 0xfffffe0145bf27e0
[296] calltrap() at calltrap+0x8/frame 0xfffffe0145bf27e0
[296] --- trap 0xc, rip = 0xffffffff80e15bc9, rsp = 0xfffffe0145bf28b0, rbp = 0xfffffe0145bf2aa0 ---
[296] ip6_output() at ip6_output+0xdf9/frame 0xfffffe0145bf2aa0
[296] tcp_default_output() at tcp_default_output+0x1e74/frame 0xfffffe0145bf2c70
[296] tcp_usr_disconnect() at tcp_usr_disconnect+0x77/frame 0xfffffe0145bf2cb0
[296] soclose() at soclose+0x75/frame 0xfffffe0145bf2d10
[296] _fdrop() at _fdrop+0x11/frame 0xfffffe0145bf2d30
[296] closef() at closef+0x24a/frame 0xfffffe0145bf2dc0
[296] closefp_impl() at closefp_impl+0x58/frame 0xfffffe0145bf2e00
[296] amd64_syscall() at amd64_syscall+0x117/frame 0xfffffe0145bf2f30
[296] fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0145bf2f30
[296] --- syscall (6, FreeBSD ELF64, close), rip = 0x49c1bf, rsp = 0x86c2718b0, rbp = 0x86c2718b0 ---
[296] KDB: enter: panic
panic.txt0600001215161023705  7131 ustarrootwheelpage faultversion.txt06000010015161023705  7602 ustarrootwheelFreeBSD 14.3-RELEASE-p9 in6_selecthlim-n272036-8c8ffb05214b SMP


I can test this if an OPNsense patch is made available.

Looks like the issue reported here https://forum.opnsense.org/index.php?topic=49131.msg249523#msg249523 is back in 26.1.4 . I have a working IPv6 setup with /64 prefix delegation from ISP (PPPoe), but any attempt to change "Prefix delegation size" with "Send prefix hint" crashes the firewall. I am able to consistently reproduce this, every time I attempt to change these values, router crashes and reboots.

Code Select Expand

Versions
OPNsense 26.1.4-amd64
FreeBSD 14.3-RELEASE-p9
OpenSSL 3.0.19

Code Select Expand

[969470]
[969470]
[969470] Fatal trap 12: page fault while in kernel mode
[969470] cpuid = 4; apic id = 08
[969470] fault virtual address = 0x10
[969470] fault code = supervisor read data, page not present
[969470] instruction pointer = 0x20:0xffffffff80e0d175
[969470] stack pointer         = 0x28:0xfffffe0149887a80
[969470] frame pointer         = 0x28:0xfffffe0149887ab0
[969470] code segment = base 0x0, limit 0xfffff, type 0x1b
[969470] = DPL 0, pres 1, long 1, def32 0, gran 1
[969470] processor eflags = interrupt enabled, resume, IOPL = 0
[969470] current process = 10545 (tailscaled)
[969470] rdi: fffff8000244f000 rsi: 000000000000001c rdx: fffff806f7d2f078
[969470] rcx: fffff8000244f000  r8: 00000000ffffffbd  r9: 0000000000000000
[969470] rax: 0000000000000000 rbx: 0000000000000000 rbp: fffffe0149887ab0
[969470] r10: fffffe0149887a30 r11: 0000000000000008 r12: fffff80398e23298
[969470] r13: 0000000000000000 r14: fffffe0149887a8c r15: 0000000000010200
[969470] trap number = 12
[969470] panic: page fault
[969470] cpuid = 4
[969470] time = 1773944620
[969470] KDB: stack backtrace:
[969470] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe01498877d0
[969470] vpanic() at vpanic+0x161/frame 0xfffffe0149887900
[969470] panic() at panic+0x43/frame 0xfffffe0149887960
[969470] trap_pfault() at trap_pfault+0x3da/frame 0xfffffe01498879b0
[969470] calltrap() at calltrap+0x8/frame 0xfffffe01498879b0
[969470] --- trap 0xc, rip = 0xffffffff80e0d175, rsp = 0xfffffe0149887a80, rbp = 0xfffffe0149887ab0 ---
[969470] in6_selecthlim() at in6_selecthlim+0x95/frame 0xfffffe0149887ab0
[969470] tcp_default_output() at tcp_default_output+0x1ca4/frame 0xfffffe0149887c70
[969470] tcp_usr_disconnect() at tcp_usr_disconnect+0x77/frame 0xfffffe0149887cb0
[969470] soclose() at soclose+0x75/frame 0xfffffe0149887d10
[969470] _fdrop() at _fdrop+0x11/frame 0xfffffe0149887d30
[969470] closef() at closef+0x24a/frame 0xfffffe0149887dc0
[969470] closefp_impl() at closefp_impl+0x58/frame 0xfffffe0149887e00
[969470] amd64_syscall() at amd64_syscall+0x117/frame 0xfffffe0149887f30
[969470] fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0149887f30
[969470] --- syscall (6, FreeBSD ELF64, close), rip = 0x49c1bf, rsp = 0x86d1814f8, rbp = 0x86d1814f8 ---
[969470] KDB: enter: panic
panic.txt0600001215157037454  7144 ustarrootwheelpage faultversion.txt0600007515157037454  7550 ustarrootwheelFreeBSD 14.3-RELEASE-p9 stable/26.1-n272033-b4ddb3e0f150 SMP


Created a feature request on plugin repo https://github.com/opnsense/plugins/issues/5042

Now that Tailscale team have implemented a standard mechanism to blacklist interfaces/network that tailscale should use, what would be the best way to configure this on OPNsense?  https://github.com/tailscale/tailscale/pull/17762

I guess the best way would have been if implemented on the Plugin GUI, but till this is possible.

No more crashes anymore...

Nice...

Updated to 25.7.5, would test out IPv6 changes.

Yes, using PPPoE

What do you think is the root cause?

This Akamai WAF blocking your connection to the website, probably due to your VPN (on a VPS/Cloud?) or some other rule triggering it.

I have a working IPv6 setup with /64 prefix delegation from ISP, but any attempt to change "Prefix delegation size" with "Send prefix hint" crashes the firewall. I am able to consistently reproduce this, every time I attempt to change these values, routes crashes and reboots.

Code Select Expand

Versions
OPNsense 25.7.4-amd64
FreeBSD 14.3-RELEASE-p2
OpenSSL 3.0.17

Code Select Expand

[44893]
[44893]
[44893] Fatal trap 12: page fault while in kernel mode
[44893] cpuid = 0; apic id = 00
[44893] fault virtual address = 0x10
[44893] fault code = supervisor read data, page not present
[44893] instruction pointer = 0x20:0xffffffff80e054e6
[44893] stack pointer         = 0x28:0xfffffe0145ffca70
[44893] frame pointer         = 0x28:0xfffffe0145ffcb90
[44893] code segment = base 0x0, limit 0xfffff, type 0x1b
[44893] = DPL 0, pres 1, long 1, def32 0, gran 1
[44893] processor eflags = interrupt enabled, resume, IOPL = 0
[44893] current process = 87956 (tailscaled)
[44893] rdi: fffff8000baba000 rsi: 000000000000001c rdx: 0000000000000010
[44893] rcx: 00000000ffffffff  r8: 00000000000000fd  r9: 000000006529fcfd
[44893] rax: 0000000000000000 rbx: fffff8000baba000 rbp: fffffe0145ffcb90
[44893] r10: fffff8072ff77b18 r11: fffff8013fe18970 r12: fffffe0145ffcb30
[44893] r13: fffff8021286cd80 r14: fffffe0145ffcb30 r15: fffff80612e18a80
[44893] trap number = 12
[44893] panic: page fault
[44893] cpuid = 0
[44893] time = 1759394699
[44893] KDB: stack backtrace:
[44893] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0145ffc7c0
[44893] vpanic() at vpanic+0x161/frame 0xfffffe0145ffc8f0
[44893] panic() at panic+0x43/frame 0xfffffe0145ffc950
[44893] trap_pfault() at trap_pfault+0x3da/frame 0xfffffe0145ffc9a0
[44893] calltrap() at calltrap+0x8/frame 0xfffffe0145ffc9a0
[44893] --- trap 0xc, rip = 0xffffffff80e054e6, rsp = 0xfffffe0145ffca70, rbp = 0xfffffe0145ffcb90 ---
[44893] in6_selectsrc() at in6_selectsrc+0x636/frame 0xfffffe0145ffcb90
[44893] in6_selectsrc_socket() at in6_selectsrc_socket+0x41/frame 0xfffffe0145ffcbd0
[44893] in6_pcbconnect() at in6_pcbconnect+0x1b3/frame 0xfffffe0145ffcc50
[44893] tcp6_connect() at tcp6_connect+0x69/frame 0xfffffe0145ffcc90
[44893] tcp6_usr_connect() at tcp6_usr_connect+0x32e/frame 0xfffffe0145ffcd20
[44893] soconnectat() at soconnectat+0xb1/frame 0xfffffe0145ffcd60
[44893] kern_connectat() at kern_connectat+0xed/frame 0xfffffe0145ffcdc0
[44893] sys_connect() at sys_connect+0x81/frame 0xfffffe0145ffce00
[44893] amd64_syscall() at amd64_syscall+0x117/frame 0xfffffe0145ffcf30
[44893] fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0145ffcf30
[44893] --- syscall (98, FreeBSD ELF64, connect), rip = 0x49c0ff, rsp = 0x87082f3e8, rbp = 0x87082f3e8 ---
[44893] KDB: enter: panic
panic.txt0600001215067435613  7143 ustarrootwheelpage faultversion.txt0600007515067435613  7547 ustarrootwheelFreeBSD 14.3-RELEASE-p2 stable/25.7-n271676-ab2281de1853 SMP
OPNsense (c) 2014-2025 De

OpenVPN, IPSec, Wireguard, Zerotier allow multiple VPN instances or VPN Network membership. It would make sense to keep this UX consistent and allow/Add feature for Tailscale and Openconnect as well.

The same vendor has N100 pc as well, check it https://clientronix.in/product/clientronix-alpha-100/

Netflow creates a protocol entry of every single connection. On a busy gateway what you observe is just expected. It's a heck of a lot of data, so there is no "solution".

You could set up an external network management system and netflow aggregator and send the data there instead of processing it locally. Most products are commercial, though. I am still investigating if there is any open source tool I can use.

I use Elastiflow (renamed to NetObserve). They have a free tier license which is good enough for homelab use.

https://www.elastiflow.com/basic-license

Solved.

Looks like mismatched jumbo frames enabled on the couple of switches might have been causing this issue. Disabled Jumbo frames on all devices across the network, which resolved the issue.