Messages

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.

Thank you for your reply.

The reason is the strict requirements of the Telematics Infrastructure (TI) in the medical sector, which dictate the configuration.

As far as my research indicates, the problem is the changing WAN IP address. The OPNsense kernel remains in state with the old IP address, which is why it doesn't detect the change and doesn't initiate a new connection, while the remote end with the new IP address can't establish a connection, and phase 2 fails.

In two weeks, the switch to fiber optics will take place, which will also provide a static IP address. I hope that the problem will then be resolved, assuming it really is the changing IP address.

Hello everyone,

I am seeing a recurring issue with a production TI gateway IPsec tunnel on OPNsense 26.1 and would like to understand whether this is a known behavior and what the cleanest way to solve it would be.

Environment:
- OPNsense 26.1
- Site-to-site IPsec tunnel to a TI gateway
- WAN with dynamic public IP
- Phase 2 traffic selector: 0.0.0.0/0 === 0.0.0.0/0
- DPD enabled
- I have already tested different combinations of start_action / close_action / trap

Observed behavior:
- Phase 1 / IKE SA stays up
- DPD continues to run and the peer responds
- At the same time, Phase 2 / CHILD_SA or the related policy disappears
- The log then repeatedly shows messages like:
  "querying policy 0.0.0.0/0 === 0.0.0.0/0 in/out failed, not found"
- No reliable automatic rebuild of the CHILD_SA happens afterwards
- Functionally, the tunnel is dead even though IKE is still alive

Important points:
- I do not see a PPPoE / WAN reconnect in the relevant time window
- From the remote side, the tunnel may still be shown as UP
- A manual or explicitly triggered reconnect restores functionality

My current interpretation:
This does not look like a full tunnel outage:
- IKE / DPD still alive
- CHILD_SA / policy missing
- no automatic rebuild

Questions:
1. Is this a known strongSwan / OPNsense behavior with this kind of tunnel, especially with 0.0.0.0/0 selectors?
2. Is there a native and clean way in OPNsense 26.1 to detect and recover from exactly this state?
3. Would you approach this via built-in OPNsense mechanisms such as IPsec API / sessions / service control / Monit, or does this point more to TI peer-side behavior?
4. Has anyone managed to make this kind of tunnel fully stable without an external watchdog?

Example from the log:
- DPD continues successfully
- at the same time:
  "querying policy 0.0.0.0/0 === 0.0.0.0/0 out failed, not found"
  "querying policy 0.0.0.0/0 === 0.0.0.0/0 in failed, not found"



Thanks a lot.