Messages

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.

gelöscht

nuke the dynamic lease

Good morning!

What's the best way to do this?

a. Should the lease time be set to a short interval (e.g., 60 seconds)?

b. Should the corresponding entry be deleted from Kea's database via terminal?

Vielen Dank für die Antworten.

Ich würde das Übel an der Wurzel anpacken und 1 nehmen - aber das schrieb ich ja schon. Denn: andere SIP-Geräte machen das selbst richtig.

Aus der Dokumentation meiner Telefonanlage:
"Standardmäßig senden STARFACE-autoprovisionierte Telefone alle 60 Sekunden ein Keep-Alive-Paket, um den Eintrag in der NAT-Tabelle des Routers auf Kundenseite zu erneuern
Eine davon abweichende Konfiguration des Keep-Alive-Intervalls erfolgt direkt auf dem Telefon (Endgerät) und nicht über die STARFACE-Weboberfläche. Die genaue Anleitung zur Änderung des Intervalls hängt vom jeweiligen Telefonmodell ab und ist in der entsprechenden Geräte-Dokumentation zu finden."

-> So müsste ich für alle 15 Telefone die Änderung durchführen.

Nummer 2 ist eine Notlösung mit offensichtlichen Drawbacks.

Sehe ich auch so und wollte dies daher mit 3. vermeiden.

Nummer 3 hat den Nachteil, dass Du nächstes Mal dran denken musst, dass da noch "versteckte" Optionen nötig sind.

Die entsprechende Firewallregel mit den "versteckten Optionen" wird sich voraussichtlich nur selten ändern. Die IP Adresszuweisung für die Telefonanlage und die entsprechenden VoIP Ports müssen nur im Alias verändert werden, so dass auch eine Änderung in der entsprechenden Outbondregel mit static port stattfindet.

4. eingehen Port Forward, was bei mir nur 5060 und 7077-7097 sind. Eingeschränkt auf AS 3320 (DTAG) und 16188 (meins).

Port Forwarding bedarf es bei meinem Setup zum Betrieb von SIP nicht und würde ich daher gerne vermeiden.