Recent posts

#1

General Discussion / Re: BUG on the Business versio...

Last post by olivergrey999 - Today at 12:46:47 PM

Dear OPNSense Community,

I'm trying to use one of our Business OPNSense in transparent bridge mode in one of our DMZ. The Bridge will work until I reboot the system. The appliance is an official Deciso OPNSense DEC3842.
The topology is not so complex but more complex than what we find on internet and forums in general. It's a 3-tier environnement and OPNSense isn't used for NATing. I've tried to integrate the OPNSense to scan the traffic (IPS/IDS, CrowdSec and the firewall) between the 1st and 2nd HOP of our Networks.
Every time I restart the appliance, I have to save the bridge interface again to restore to connections behind the OPNSense. If I don't do that, I can't access the various applications, remote sessions and https interfaces. It works for about 2 or 3 days then the connection is lost again. I press the "save" button and it works again.
The online applications are working without that because they're proxied by the OPNSense, but our intern connection between the network not. What is really strange and that's why I believe that's a problem from the OPNSense, I can access the UI of the OPNSense and nothing behind (the last time), sometimes I can access some of the UIs / RDP.

I've found a second problem and I think it's an effect of this bridge's problem. If I don't save the parameter from suricata again (IPS/IDS) the logs are filled with thousands of those lines: [101142] <Error> -- bridge0: error reading netmap data via polling: No buffer space available
Some times it's written also with bridge0^. I've found something about on internet but it doesn't match my case.
I just need to save the suricata configuration and it's gone and works as it should.

The topology looks something like this: 1st Hop Router (with NAT) -> OPNSense as transparent bridge + proxies connected to some Web Apps -> 2nd Hop Router (with NAT) -> application servers etc...

It seems that OPNSense is interfering with something in the communication between the routers. I've suspected something with ARP, but the last test with some static ARP entries (neighbors) has failed. Before the OPNSense we had a Sophos XG (in bridge mode too) and it has worked flawlessly. But with the EOL it was the time to change.

The only solution for me was to save the bridge and the IPS/IDS configuration again(interface bridge+lan).

Could you please help me?
I'll go into detail, when some information is needed. But it could be a really long topic, so I made this summary.

All the best

Regards

Joel T.

The recurring need to save the bridge configuration after a reboot makes me suspect an interface initialization or configuration-application issue rather than ARP alone. I'd start by checking whether the bridge members are consistently attached to the bridge after boot and whether the assigned interface configuration is being applied in the expected order. Also check the system logs around the time connectivity disappears, particularly interface link state changes and driver or netmap errors.

The Suricata message is worth investigating separately. No buffer space available can indicate netmap buffer exhaustion or a problem with how the network interfaces are being handled under load. Since saving the IDS configuration temporarily clears it, I'd look at the Suricata/netmap initialization and interface assignments rather than assuming it's simply a firewall rule issue.

A few things I'd want to know:

Which OPNsense version and kernel are running on the DEC3842?

Are both physical bridge interfaces using the same driver?

Is Suricata configured to use the bridge interface directly or its individual physical members?

Does connectivity return immediately after saving the bridge, without restarting any services?

I'd also consider testing with Suricata temporarily disabled to see whether the bridge still loses connectivity after a reboot. That would help establish whether these two symptoms share the same underlying cause. Given that the Sophos worked in the same topology, I'd pay particular attention to differences in bridge implementation and NIC/netmap handling.

#2

High availability / Re: Aliases to support "No XML...

Last post by surjit567 - Today at 12:45:01 PM

This would be a useful addition, especially for high-availability setups where the primary and disaster recovery sites need to use the same alias names but maintain different IP addresses or networks. Disabling alias synchronization globally is not a practical solution when most aliases still need to be replicated. A per-alias "No XMLRPC Sync" option would provide much more flexibility while preserving synchronization for the rest of the configuration. Hopefully the feature request gets considered by the developers.

#3

26.7, 26.10 Series / Re: Upgrade to 26.7.8 broke Ga...

Last post by bugacha - Today at 12:39:41 PM

26.7.8_2 works fine here

#4

26.7, 26.10 Series / Re: WAN_DHCP6 learns OPNsense ...

Last post by Monviech (Cedrik) - Today at 12:37:56 PM

Its most of the time a vlan trunk misconfiguration. If untagged and tagged frames are mixed, some weird stuff can happen, like leaking router advertisements between vlans.

https://docs.opnsense.org/manual/how-tos/vlan_and_lagg.html

Read this.

#5

General Discussion / Has anyone heard of / tried OP...

Last post by dev - Today at 12:36:05 PM

Hi everyone,I've come across a project called OPNexus (https://opnexus.dev and https://github.com/OPNexus-dev/OPNexus).
It presents itself as a self-hosted central management console for multiple OPNsense firewalls. But for free.

It is source-available (PolyForm Shield license), runs via Docker Compose, and claims to work purely through the OPNsense API.
I couldn't find any discussion about it in the OPNsense forum or elsewhere, so I wanted to ask:Has anyone here heard of OPNexus before?
Has anyone already tested or is currently using it?
Any experiences, impressions, or concerns (positive or negative)?

Thanks in advance for any feedback!

#6

26.7, 26.10 Series / Re: WAN_DHCP6 learns OPNsense ...

Last post by Patrick M. Hausen - Today at 12:20:28 PM

Use a packet trace and look for router advertisements or DHCPv6 on the WAN interface.

#7

26.1, 26.4 Legacy Series / Re: OPNSense forwarding packet...

Last post by iorx - Today at 11:09:52 AM

Same problem here, but on a CARP pair, and in our case it ended in a kernel panic.

Setup: 26.7.7, two VMs on Hyper-V (2019, SET, hn), CARP + pfsync, NetFlow on LAN/GUEST/WAN.

Since the day the HA pair went live, unknown unicast (a printer MAC that had aged out of the switches) has been bounced between the two nodes with decreasing TTL until it expired. That meant short floods several times an hour, with hn0: RXBUF ack failed during them. Yesterday the master panicked:

Code Select Expand

Fatal trap 12: page fault while in kernel mode
m_copydata+0xfa
hn_encap+0x4c7
hn_xmit+0xedI turned off NetFlow on both nodes and changed nothing else. No floods and no hn errors since.

This is FreeBSD Bug 295415 (netgraph skips the M_PROMISC check, and CARP keeps the NIC promiscuous). The same loop was reported in opnsense/src #279, which was closed as "Timeout." It would be good to reopen that, or at least warn in the GUI when NetFlow is enabled on CARP interfaces. Until then: no NetFlow on CARP interfaces.

#8

26.7, 26.10 Series / Re: WAN_DHCP6 learns OPNsense ...

Last post by noclue68 - Today at 10:58:41 AM

That was my first suspicion.

However, WAN and LAN are on separate NICs and separate Proxmox bridges. I also factory-reset the managed switch and reproduced the issue on a fresh OPNsense installation.

NDP correctly discovers the FRITZ!Box:

fe80::b6fc:7dff:fe50:16a5
MAC b4:fc:7d:50:16:a5

but WAN_DHCP6 still installs

fe80::be24:11ff:fe89:923c

which belongs to the OPNsense LAN interface.

Could a layer-2 loop still explain this behaviour?

[Hardware (all 4 units the same board)]

#9

26.7, 26.10 Series / 26.1 -> 26.7 upgrade: box free...

Last post by mrmanuel - Today at 10:13:05 AM

Hi all,

I run four OPNsense firewalls on identical hardware. During the major upgrade 26.1.11 -> 26.7, three of them froze at the very end of the upgrade. They stayed offline for hours until someone pulled the power plug. After a cold boot each one came up fine on 26.7 and has worked normally since. So the upgrade itself completed; only the final automatic reboot failed.

Hardware (all 4 units the same board)

• Unbranded mini-PC board, SMBIOS shows "Default string" everywhere
• AMI BIOS 5.27, dated 03/27/2025, newest available version
• Intel B660 chipset
• CPU: 3x Intel Core i3-14100 (8 GB RAM), 1x Intel Core i7-14700 (32 GB RAM)
• NICs: Intel I226-V (igc) + Intel 10G SFP+ (ix)
• UEFI boot, ZFS root
• os-cpu-microcode-intel is NOT installed on any of them (I know about the "masks" hang thread; it doesn't apply here)

What happened

• Unit A (i7): upgraded 2026-10-06 (26.1.11 -> 26.7.7), froze. Back after a power cycle.
• Unit B (i3): upgraded 2026-10-06 (26.1.11 -> 26.7.7), froze. Back after a power cycle.
• Unit C (i3): upgraded 2026-10-29 (26.1.11 -> 26.7.7), no problem; rebooted on its own and came back.
• Unit D (i3): upgraded 2026-11-03 (26.1.11 -> 26.7.7), froze. Back after a power cycle.

Every normal reboot, including minor updates (e.g. 26.7.7 -> 26.7.8_2), works fine on all four units. The problem only shows up on the major upgrade.

Where it stops
The first reboot into the new kernel works. The box then boots the post-upgrade stage (hostname "localhost"), which upgrades the packages and runs the config migrations successfully. On the unit that worked, the log ends with "rebooted by root", and it is back within about 50 seconds. On the units that froze, nothing more is logged. The last lines on unit A, B and D were:

Code Select Expand

2026-11-03T19:00:11 localhost kernel: Configuring system logging...done.
2026-11-03T19:00:11 localhost kernel: ==> Running trigger: glib-schemas.ucl
2026-11-03T19:00:11 localhost kernel: Compiling glib schemas
2026-11-03T19:00:11 localhost kernel: No schema files found: doing nothing.
2026-11-03T19:00:11 localhost kernel: ==> Running trigger: gio-modules.ucl
2026-11-03T19:00:11 localhost kernel: Generating GIO modules cache
(nothing until the power cycle, even after I waited for 6 hours)

So the freeze happens within seconds of the end of the post-upgrade stage, either just before or during the automatic reboot. These units are remote, so I don't have console output yet. Next time I will connect a monitor.

Questions

• Has anyone seen this on similar boards (CWWK/Topton-style, B660 + I226-V + SFP+)?
• Does the post-upgrade stage reboot differently from a normal "reboot", e.g. while some drivers or services are only partly initialised?
• Are there tunables worth trying (e.g. hw.efi.poweroff, USB shutdown settings), or debug options that would capture more output before the next major upgrade?

Possibly related thread: https://forum.opnsense.org/index.php?topic=52391.0

Thanks!

#10

German - Deutsch / Re: WireGuard-Tunnel ohne Inte...

Last post by Patrick M. Hausen - Today at 09:40:03 AM

Wenn ein Interface nicht existiert, können keine Firewall-Regeln dafür angelegt werden. Wenn es danach "hoch" kommt, sind die Regeln nicht da.

Hast du das WG-Interface mal in Interfaces > Assignments explizit angelegt und auch Prevent interface removal aktiviert?