Messages

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.

Das ist eine Frage an die Kenner und Könner!

Macht das Sinn?

und zusätzlich die Firewall Optimization (Firewall->Settings->Advanced) auf conservative gestellt.

Um nicht generell die Einstellung der Firewall zu verändern (wahrscheinlich ist der Nachteil nicht so groß), ist es nicht eine Möglichkeit bei einer entsprechenden Firewallregel nach Aktivierung der erweiterten Einstellung nur für diese Regel die UDP states anzupassen?

VLAN Schnittstelle VoIP
Firewall Regeln (new)

Version: IPv4
Protokoll: TCP/UDP
Quelle: VoIP Server IP
Port: VoIP Ports (Alias: 5060;5061; RTP Ports zum Beispiel PBX Asterisk 10000-20000)
Ziel: FQDN Telekom (Alias; in meinem Fall Telekom)

Erweiterte Einstellungen:

[0]

@W0nderW0lf

Muss das Subnetz nicht z.B. 192.168.1.0/24, 192.168.99.0/24 lauten?

Vielen Dank!