"Recent posts
#1
General Discussion / Re: Kernel panic loading mlx4e...
Last post by meyergru - Today at 09:46:54 AMIs there any specific reason why you want to pass the adapters thru? That lays the burden of driving the adapters to FreeBSD, which traditionally is not particularly good at handling "exotic" hardware, all along on top of a virtualisation layer.
More often than not, people use Proxmox just because they want Linux to handle the hardware, because OpnSense is known to have problems with it, but in order to do that, you would use virtio, not passthru, see https://forum.opnsense.org/index.php?topic=44159.0
More often than not, people use Proxmox just because they want Linux to handle the hardware, because OpnSense is known to have problems with it, but in order to do that, you would use virtio, not passthru, see https://forum.opnsense.org/index.php?topic=44159.0
#2
General Discussion / How to switch LAN (mgmt interf...
Last post by alto - Today at 09:44:41 AMI currently have my management interface (igb0) connected with copper cat6 to my switch, this is also the parent interface of all my vlans. I want to change this to run over sfp+ though, i.e. to use interface ax0 instead. But what is the procedure to do this so that I don't completely lock myself out of the router if I change the management interface device from igb0 to ax0 and something doesn't work?
#3
26.1, 26,4 Series / Re: How to pin a Host to a Gat...
Last post by viragomann - Today at 09:40:25 AMTo get sure, for this to work, it's required that gateway monitoring is enabled and that the LTE is detected as online. Otherwise OPNsense sends the traffic to the default gateway instead.
So go to System: Gateways: Configuration and check if monitoring is enabled for the LTE (if it is, a monitoring IP is displayed) and if it's status is online.
If it isn't you have to configure the gateway monitoring properly.
So go to System: Gateways: Configuration and check if monitoring is enabled for the LTE (if it is, a monitoring IP is displayed) and if it's status is online.
If it isn't you have to configure the gateway monitoring properly.
#4
General Discussion / Updates Question - Navigating ...
Last post by pSych0bUNny - Today at 03:22:00 AMI'm sure this has been covered before however trying to find the why searching for 'updat' or similar has returns a lot of results.
Curious as to why after I "Check for Updates" from the Firmware > Status, if I navigate to a different section - outside Firmware - in the FW, I must re "Check for Updates" again to reenter the update mode.
Can I trigger this manually?
If I subsequently click the Firmware > Updates tab, it shows there's an update, but does not enter the update mode.
I've tried clicking the release notes from Firmware > Changelog, but that too does not trigger the update mode.
It's not a major, just a funny mechanism - am I missing something?
EDIT: clarified issue
Curious as to why after I "Check for Updates" from the Firmware > Status, if I navigate to a different section - outside Firmware - in the FW, I must re "Check for Updates" again to reenter the update mode.
Can I trigger this manually?
If I subsequently click the Firmware > Updates tab, it shows there's an update, but does not enter the update mode.
I've tried clicking the release notes from Firmware > Changelog, but that too does not trigger the update mode.
It's not a major, just a funny mechanism - am I missing something?
EDIT: clarified issue
#5
General Discussion / Kernel panic loading mlx4en mo...
Last post by Ritzy1506 - Today at 12:03:41 AMHi,
I couldn't find if running OPNsense in Proxmox was a supported configuration or not, so sorry if this isn't allowed.
Software versions:
When I load mlx4_core and mlx4_en in Proxmox, the interface comes up correctly. I've passed it through to the OPNsense VM:
In OPNsense, mlx4.ko is already loaded. When I run kldload mlx4en, I get the following panic:
Does anyone have any ideas? Thanks
I couldn't find if running OPNsense in Proxmox was a supported configuration or not, so sorry if this isn't allowed.
Software versions:
Code Select
proxmox-ve: 9.1.0 (running kernel: 6.17.2-1-pve)
OPNsense 26.1.8_5
When I load mlx4_core and mlx4_en in Proxmox, the interface comes up correctly. I've passed it through to the OPNsense VM:
Code Select
root@proxmox-1:~# lspci -nnk | grep Mellanox -A3
01:00.0 Ethernet controller [0200]: Mellanox Technologies MT27520 Family [ConnectX-3 Pro] [15b3:1007]
Subsystem: Mellanox Technologies ConnectX-3 Pro 10 GbE Dual Port SFP+ Adapter [15b3:0080]
Kernel driver in use: vfio-pci
Kernel modules: mlx4_core
root@proxmox-1:~# lsmod | grep -e mlx -e vfio
vfio_pci 20480 1
vfio_pci_core 86016 1 vfio_pci
irqbypass 16384 2 vfio_pci_core,kvm
vfio_iommu_type1 49152 1
vfio 65536 8 vfio_pci_core,vfio_iommu_type1,vfio_pci
iommufd 126976 1 vfio
root@proxmox-1:~# qm showcmd 101 | tr ' -' '\n-' | grep 01:00.0 -B1
-device
'vfio-pci,host=0000:01:00.0,id=hostpci0,bus=ich9-pcie-port-1,addr=0x0'
In OPNsense, mlx4.ko is already loaded. When I run kldload mlx4en, I get the following panic:
Code Select
[15] mlx4_core0: <mlx4_core> mem 0x82000000-0x820fffff,0xc000000000-0xc0007fffff irq 16 at device 0.0 on pci1
[15] <6>mlx4_core: Mellanox ConnectX core driver v3.7.1 (November 2021)
[15] mlx4_core: Initializing 0000:01:00.0
[21] mlx4_core0: Unable to determine PCI device chain minimum BW
[21] vtcon0: <VirtIO Console Adapter> on virtio_pci1
[21] ichsmb0: <Intel 82801I (ICH9) SMBus controller> port 0x8000-0x803f irq 16 at device 31.3 on pci0
[21] smbus0: <System Management Bus> on ichsmb0
[22] uhid0 on uhub1
[22] uhid0: <QEMU QEMU USB Tablet, class 0/0, rev 2.00/0.00, addr 2> on usbus7
[23] lo0: link state changed to UP
[25] vtnet0: link state changed to UP
[26] arp: 10.17.0.42 moved from 98:b7:85:20:58:c7 to ee:cf:26:d6:53:34 on vtnet0
[103] mlx4_en mlx4_core0: Activating port:1
[103] mlxen0: link state changed to DOWN
[103] mlxen0: Ethernet address: 50:6b:4b:5d:aa:a0
[103] <4>mlx4_en: mlx4_core0: Port 1: Using 2 TX rings
[103] <4>mlx4_en: mlx4_core0: Port 1: Using 4 RX rings
[103] <4>mlx4_en: mlxen0: Using 2 TX rings
[103] <4>mlx4_en: mlxen0: Using 4 RX rings
[103] <4>mlx4_en: mlxen0: Initializing port
[103] mlx4_en mlx4_core0: Activating port:2
[103]
[103]
[103] Fatal trap 12: page fault while in kernel mode
[103] cpuid = 0; apic id = 00
[103] fault virtual address = 0x0
[103] fault code = supervisor read instruction, page not present
[103] instruction pointer = 0x20:0x0
[103] stack pointer = 0x28:0xfffffe0010784c18
[103] frame pointer = 0x28:0xfffffe0010784c40
[103] code segment = base 0x0, limit 0xfffff, type 0x1b
[103] = DPL 0, pres 1, long 1, def32 0, gran 1
[103] processor eflags = interrupt enabled, resume, IOPL = 0
[103] current process = 12 (swi6: task queue)
[103] rdi: fffff80070fc3000 rsi: fffffe0010784c90 rdx: fffffe00a5fd3ac8
[103] rcx: 00000000c0306938 r8: 0000000000000000 r9: 0000000000000000
[103] rax: 0000000000000000 rbx: fffffe0010784c90 rbp: fffffe0010784c40
[103] r10: fffff80070a15000 r11: fffff800015aa000 r12: 0000000000008802
[103] r13: 0000000000000010 r14: fffffe00a5fd3ac8 r15: fffff80070a15000
[103] trap number = 12
[103] panic: page fault
[103] cpuid = 0
[103] time = 1778881147
[103] KDB: stack backtrace:
[103] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0010784960
[103] vpanic() at vpanic+0x161/frame 0xfffffe0010784a90
[103] panic() at panic+0x43/frame 0xfffffe0010784af0
[103] trap_pfault() at trap_pfault+0x3da/frame 0xfffffe0010784b40
[103] calltrap() at calltrap+0x8/frame 0xfffffe0010784b40
[103] --- trap 0xc, rip = 0, rsp = 0xfffffe0010784c18, rbp = 0xfffffe0010784c40 ---
[103] ??() at 0/frame 0xfffffe0010784c40
[103] dump_iface() at dump_iface+0x145/frame 0xfffffe0010784cf0
[103] rtnl_handle_ifevent() at rtnl_handle_ifevent+0xa9/frame 0xfffffe0010784d70
[103] do_link_state_change() at do_link_state_change+0x44/frame 0xfffffe0010784dc0
[103] taskqueue_run_locked() at taskqueue_run_locked+0x182/frame 0xfffffe0010784e40
[103] taskqueue_run() at taskqueue_run+0x68/frame 0xfffffe0010784e60
[103] ithread_loop() at ithread_loop+0x239/frame 0xfffffe0010784ef0
[103] fork_exit() at fork_exit+0x81/frame 0xfffffe0010784f30
[103] fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0010784f30
[103] --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
[103] KDB: enter: panic
Does anyone have any ideas? Thanks
#6
26.1, 26,4 Series / Re: How to pin a Host to a Gat...
Last post by zartoz - May 15, 2026, 11:08:18 PMJust tried resetting State Table, had no effect. As soon as I switch the Active Gateway interface, it flips over all states so I don't think it is sticking to established sticky states. It seems like there may be no way to have a Host redirected to an alternate interface when Gateways are grouped.
#7
General Discussion / Re: Update not working after c...
Last post by UiD - May 15, 2026, 11:07:55 PMQuote from: nero355 on May 15, 2026, 03:50:32 PMIt's an Homelab ;)Quote from: UiD on May 14, 2026, 04:22:03 PMdisable => Allow DNS server list to be overridden by DHCP/PPP on WANWhy not use that simply and allow the updates to go via your ISP's DNS Servers ?!
Today I restore an old configuration from "CRASH" (from scratch :P)
I reinstall all and it's OK now.
I tried to reproduce the problem without success.
#8
26.1, 26,4 Series / Re: DS-Lite (PPPoE|DHCPv6-PD) ...
Last post by meyergru - May 15, 2026, 10:47:10 PMWhen you request real IPv4 from M-Net, you can use PPPoE plus DHCPv6, but you also have to request a prefix only as M-Net does not give you a IA_NA. IDK if the same is the case with the AFTR setup.
#9
26.1, 26,4 Series / DS-Lite (PPPoE|DHCPv6-PD) sile...
Last post by tobinger - May 15, 2026, 10:39:53 PMHi all (esp. @franco),
After migrating a working DS-Lite setup (M-net München, PPPoEv4 + DHCPv6-PD + GIF to AFTR `2001:a60:0:1::ffff`) from pfSense 2.8.1 to OPNsense 26.1.2_5 on identical hardware and WAN link, I hit a silent failure: PPPoE comes up fine, link-local IPv6 is reachable on `pppoe0`, dpinger reports the WAN IPv6 gateway as Online — but `/var/etc/dhcp6c.conf` stays at 0 bytes, no `IA_PD` request ever leaves, no global IPv6 ever appears on LAN (no track6 prefix), and the gif tunnel never gets a tunnel source.
This is distinct from the race fixed in commit `315153a07` ([thread 35876]) — that one addresses gif-reload after `newwanipv6` and assumes `dhcp6c` was started. Here `dhcp6c` is never started in the first place.
I traced the three code paths that could initialize `dhcp6c` on the PPPoE interface — `interface_configure()` in `interfaces.inc`, `ppp-ipv6.php`, and `rc.newwanipv6` — and all three skip it when `<ipaddr>pppoe</ipaddr>` + `<ipaddrv6>dhcp6</ipaddrv6>` are configured on the same WAN. The guard `interface_ppps_bound()` evaluates the v6 branch as `!ipv4_mode && ipv6_mode` = `false` for this combination, so the PPP layer says "DHCPv6 is not mine" while `interface_configure()` says "PPP owns v6, skip" — and `dhcp6c.conf` ends up empty.
Full reproducer, root-cause walkthrough with `file:line` references, and a small workaround script (`/usr/local/etc/rc.syshook.d/start/99-dslite-gif-rebuild`, ~20 lines of `sh`) that reliably gets us boot-to-Internet in ~10–60 s on M-net — https://gist.github.com/tobinger/89b3f4d7cdddf98571e20876792eb081.
Happy to test patches on this DS-Lite link. Also happy to file as a GitHub issue if you'd prefer that as the formal venue.
— Tobi
After migrating a working DS-Lite setup (M-net München, PPPoEv4 + DHCPv6-PD + GIF to AFTR `2001:a60:0:1::ffff`) from pfSense 2.8.1 to OPNsense 26.1.2_5 on identical hardware and WAN link, I hit a silent failure: PPPoE comes up fine, link-local IPv6 is reachable on `pppoe0`, dpinger reports the WAN IPv6 gateway as Online — but `/var/etc/dhcp6c.conf` stays at 0 bytes, no `IA_PD` request ever leaves, no global IPv6 ever appears on LAN (no track6 prefix), and the gif tunnel never gets a tunnel source.
This is distinct from the race fixed in commit `315153a07` ([thread 35876]) — that one addresses gif-reload after `newwanipv6` and assumes `dhcp6c` was started. Here `dhcp6c` is never started in the first place.
I traced the three code paths that could initialize `dhcp6c` on the PPPoE interface — `interface_configure()` in `interfaces.inc`, `ppp-ipv6.php`, and `rc.newwanipv6` — and all three skip it when `<ipaddr>pppoe</ipaddr>` + `<ipaddrv6>dhcp6</ipaddrv6>` are configured on the same WAN. The guard `interface_ppps_bound()` evaluates the v6 branch as `!ipv4_mode && ipv6_mode` = `false` for this combination, so the PPP layer says "DHCPv6 is not mine" while `interface_configure()` says "PPP owns v6, skip" — and `dhcp6c.conf` ends up empty.
Full reproducer, root-cause walkthrough with `file:line` references, and a small workaround script (`/usr/local/etc/rc.syshook.d/start/99-dslite-gif-rebuild`, ~20 lines of `sh`) that reliably gets us boot-to-Internet in ~10–60 s on M-net — https://gist.github.com/tobinger/89b3f4d7cdddf98571e20876792eb081.
Happy to test patches on this DS-Lite link. Also happy to file as a GitHub issue if you'd prefer that as the formal venue.
— Tobi
#10
26.1, 26,4 Series / OPNcentral NAT sync crash afte...
Last post by ews - May 15, 2026, 10:28:18 PMHello,
after upgrading OPNsense Business to 26.4 we are seeing OPNcentral sync failures on some firewalls during NAT synchronization.
Error:
TypeError: Cannot access offset of type string on string in /usr/local/opnsense/mvc/app/controllers/Deciso/OPNcentral/Api/Sync/BaseSection.php:162
Stack trace:
Deciso\OPNcentral\Api\Sync\BaseSection->array_iterator()
Deciso\OPNcentral\Api\Sync\Nat->extend()
Deciso\OPNcentral\Api\SyncController->reconfigureAction()
Observations:
only happens after upgrade to 26.4
issue seems related to NAT / Destination NAT migration
affected systems use multiple Destination NAT redirect rules
disabling NAT sync avoids the issue
not all firewalls are affected
It looks like one NAT-related config structure is returned as string instead of array and crashes array_iterator().
Has anybody seen similar behavior after migrating to 26.4?
Regards
Christian
after upgrading OPNsense Business to 26.4 we are seeing OPNcentral sync failures on some firewalls during NAT synchronization.
Error:
TypeError: Cannot access offset of type string on string in /usr/local/opnsense/mvc/app/controllers/Deciso/OPNcentral/Api/Sync/BaseSection.php:162
Stack trace:
Deciso\OPNcentral\Api\Sync\BaseSection->array_iterator()
Deciso\OPNcentral\Api\Sync\Nat->extend()
Deciso\OPNcentral\Api\SyncController->reconfigureAction()
Observations:
only happens after upgrade to 26.4
issue seems related to NAT / Destination NAT migration
affected systems use multiple Destination NAT redirect rules
disabling NAT sync avoids the issue
not all firewalls are affected
It looks like one NAT-related config structure is returned as string instead of array and crashes array_iterator().
Has anybody seen similar behavior after migrating to 26.4?
Regards
Christian
