Messages

To reiterate: My focus is on understanding the situation. There have already been several discussions on the forum regarding the use of OPNsense as a bridge.
And as I have learned, there are circumstances that make bridging necessary—though it remains only the second-best option.
Even though FreeBSD's bridge mode can work well, I do not understand why one would want to use it.
If you are building a network and planning network segmentation for valid reasons, the setup looks like this:

ISP – OPNsense Router – VLAN Trunk – Switch Segmentation – Clients in different network segments.

You could certainly make it more complex by separating the routing and firewall functions, but what advantage would that offer in the context of the described setup and requirements?

Even if my post doesn't help you solve the specific problem, I wanted to write because I'm trying to understand your approach. You never stop learning, and I might get some ideas to rethink my own network design.

As I understand it, you are trying to get the most out of your existing 1G and 2.5G components. However, the current issue following the upgrade is a direct result of software bridging on the OPNsense.
In my opinion, using OPNsense purely as a bridge or Layer 2 switch fails to leverage its capabilities and doesn't align with its intended design.

Using the firewall as an L2 switch to connect these two worlds within the same VLANs creates a highly complex stack involving LACP, VLAN tagging, BSD bridges, and firewall rules.

Even if the problem is resolved, the solution remains fragile, places unnecessary load on the firewall CPU, and introduces extra latency.

To meet your bandwidth requirements, how about considering these solutions instead?

1.  A central 2.5G/10G switch handles all L2 switching in hardware. This offloads the OPNsense, allowing it to connect to the network via a clean trunk.
or
2.  Separating the 2.5G devices into their own subnets at Layer 3. This allows you to use OPNsense exactly as it was designed to be used.

Communication (mDNS, SSDP) between the networks can be ensured using a multicast relay, for example (https://forum.opnsense.org/index.php?topic=52705.0).

Regarding the specific topic at hand: The transition to the new rule framework has been a subject of discussion in this forum since January 2026. The migration assistant is a no-brainer; thanks to it—and the available backup and restore options—the transition poses absolutely no risk.

In general, users of the OPNsense Community Edition should be aware that they are, to some extent, testers for new features that eventually make their way into the paid version of OPNsense.
In return, however, they receive a fantastic firewall for free—one that need not shy away from comparison with expensive commercial competitors.
This forum is active and monitored by highly experienced users who are always ready to help—often even when a topic has been discussed repeatedly and the answer could have been found via a simple search.

It is up to the individual whether to adopt changes early during version updates or to wait for reliable, rapid bug fixes.
However, if you use the Community Edition, I believe you also bear some responsibility for regularly reading forum posts; otherwise, you might find yourself facing a problem eight months down the line that has already been thoroughly discussed and addressed. This applies equally to experienced forum members and OPNsense newcomers.

Have you tried searching the forum?
Does the following post solve your problem?

https://forum.opnsense.org/index.php?msg=270533

If I understand correctly, you want to use OPNsense purely as a Layer 2 bridge and disable all services.
You want to avoid unpacking or readdressing IP packets (no NAT) and consulting routing tables in order to minimize latency.
That's a valid idea!

However, doing so means you aren't utilizing 90% of OPNsense's capabilities.
OPNsense is a stateful L3/L4 router with firewalling features.
I get the feeling that specialized solutions would be far better and offer higher performance for your use case than trying to force OPNsense to do something it wasn't designed for.

> community/25.1/25.1.3:o interfaces: remove defunct "other" VIP type

To our knowledge it wasn't even creating a VIP, just being selectable in some legacy pages as a single pseudo-alias and we simply did not want to bring this cruft into MVC to ease future maintenance burden.


Cheers,
Franco

"mode=other" was a hack in the source code. The OPNsense team removed the mode because it was architecturally unsound and caused confusion in standard setups—even though it had worked for 10 years.

I hope you find the best solution for your needs, but it is possible that OPNsense—in its current and future versions—is no longer the right fit.

It will support VPP, and thats something that BSDs dont have.

At what network size and data throughput does this become relevant?

Hello.
I'm not sure if I'm in the right place here or if I'm hijacking the forum thread. If so, please accept my apologies.
My installation is getting on in years, too—four years old.
The update to 26.7 went smoothly, as usual.

Many thanks to the team!

However, before I could bring myself to proceed, I closely followed the discussion regarding the bootloader update and the "microcode problem." There were several discussions about it. This raises the question for me: who actually needs a bootloader update? And how do I determine whether I need this bootloader update?
Many thanks,
Bernd

[1. Correct Destination NAT Configuration]

You accidentally inverted the Source instead of the Destination, and your Floating Rule is currently filtering outbound traffic (which is still blocking Unbound from reaching the internet).

Here is how both rules need to be configured:

1. Correct Destination NAT Configuration

Interface: Select all your local Interfaces/VLANs (do NOT select WAN or WireGuard).

Protocol: TCP/UDP

Source: any (Leave this completely default, do not invert!).

Port: *

Destination / Invert: Check the [X] (Invert) box.

Destination: Select This Firewall (self).

Port: 53 (domain)

Redirect Target IP: 127.0.0.1

Redirect Target Port: 53 (domain)

Filter Rule Association: Set this to Pass

Your current rule applies to traffic where the Source is not the firewall. We want it to apply to any client whose Destination is not the firewall.


2. Correct Floating Rule Configuration

If you still want to use the Floating Rule as a fallback block for port 53, it must only block incoming traffic from clients, never outbound traffic from Unbound.

Action: Block or Reject

Quick: Checked [X] (Apply immediately)

Interface: Select your local Interfaces/VLANs (do NOT select WAN, WireGuard, or Loopback).

Direction: Change this to IN (Currently, it is set to OUT, which blocks Unbound from hitting WAN!).

Protocol: IPv4 TCP/UDP

Source: any (Do not invert!).

Port: *

Destination / Invert: Check the [X] (Invert) box.

Destination: Select This Firewall (self).

Port: 53 (DOMAIN)



By setting Source: ! This Firewall, your rule was trying to match packets where the sender wasn't the firewall. We need to match packets where the intended target (Destination) isn't the firewall.

Your Floating Rule had the <- arrow (Outbound). This meant whenever Unbound itself tried to send a DNS request out to the internet via WAN, the firewall blocked it. Changing the direction to IN ensures it only blocks clients trying to push unauthorized DNS traffic into your local interfaces.

My idea about the problem:
When you restart Unbound or a client makes a new request, your destination NAT intercepts it, forwards it to 127.0.0.1 and a state is created. The client receives his answer.

However, Unbound itself needs to communicate with the outside world (upstream DNS or root server) via port 53. Depending on how your floating rule is configured, Unbound will block its own outbound requests. As soon as Unbound needs to update an entry or fetch a new request from the Internet, it will be blocked by the floating rule; it enters an error state, logs a "SERVFAIL", and DNS resolution fails until you restart the service (which clears the status records).

Maybe it's worth trying to adjust the floating rule so that all requests that are not made to the firewall are blocked: using the "Invert" function in the destination:
• Destination: [X] Invert
• Target: This Firewall (self)

Then how does "I use an Apple Mac" come into play here? You are running public services on Mac OS?

No, these are not public services, but rather a server hosted on the internal network. If I wanted to make this server accessible exclusively via IPv6, wouldn't it require a fixed address? Currently, I have implemented this on a trial basis using a ULA. The prefix consists of a virtual IP, followed by a suffix that the Mac generated for itself via stateless autoconfiguration. I have shared this address with the network clients that require access to the server.
Have I misunderstood something?

The main dissonance here is that the authority of the IPv6 addresses belong to the client, generally the client should decide whatever happens with their addresses. In IPv4, NAT took care of centralizing the identity to the router in most networks that used RFC1918 addresses, for "a comparable" experience in IPv6 you need ULAs and all of the mess they are.

It is almost philosophical in the sense of freedom. Clients—or network participants—regain their autonomy, liberated from the dictates of the network administrator. However, the administrator remains responsible for the network's structure and security—and this responsibility necessitates control.
Since IPv6 permits the use of multiple addresses simultaneously, this strikes me as no contradiction; consequently, ULAs are neither a hack nor a chaotic mess.

Apologies for the lack of precision in my phrasing.
The discussion centered on server reachability; a server requires a unique address in order to be located. Therefore, my clarifying question does not pertain to clients, but rather to servers!

All my servers use SLAAC. The addresses are stable unless I change the MAC address of the server for some reason. I can then point Caddy (or NginX in your case) at these addresses.

Just to confirm my understanding:
This holds true
1. if either a static prefix from the ISP exists, combined with an autoconf-secured suffix (I use an Apple Mac) or the client's EUI-64-adress;
or
2. if a Dynamic IPv6 Host Alias is used, specifying the autoconf-secured suffix (I use an Apple Mac) or the client's EUI-64-adress within the alias.

I don't want to be misunderstood—I am far from being a networking expert. Rather, I am grappling with the very same issues regarding the implementation of fixed IPv6 assignments, network segmentation, and access control. In that sense, I used this thread as an opportunity to better understand—through discussion—how our specific problem might be solved without forcing the IPv6 structure into a straitjacket that runs counter to its fundamental design principles. Couldn't we simply assign a ULA to Nginx instead of relying on a static assignment via DHCPv6? In the IPv6 world, devices are capable of having—and indeed typically do have—more than one address: a GUA assigned via Router Advertisement to enable communication with the outside world, and a ULA for internal purposes, ensuring the device can be reliably located within the local network.

I do not believe KEA is the problem; rather, it is DHCPv6. Centralized address allocation runs counter to the design of IPv6, which is predicated on autonomous address assignment.
However, this presents a challenge for the network administrator who wishes to manage and structure their network in distinct zones.
One has two options: either continue using IPv4 for the internal network—retaining the familiar segmentation based on IP addresses—and restrict IPv6 usage solely to external traffic; or, structure the network not by IP addresses, but by interfaces (VLANs), groups, or segments. Given the immense number of potential addresses enabled by IPv6, one could theoretically assign each individual device its own interface with a unique address (via Prefix Delegation down to the host level).
Those who truly leverage IPv6 manage traffic at the boundaries of their network segments (via firewalls), rather than through the micromanagement of static leases.