Messages

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!

Hallo Forum!

Zunächst möchte mich wieder einmal für die grandiose Arbeit der Entwickler bedanken! Der Umstieg auf OPNsense 26.1.1 gelang problemlos, wie auch die Umstellung auf die neuen Regeln.
Auch beim Forum möchte ich mich für die vielen interessanten und lehrreichen Beiträge bedanken.

Ich nutze Crowdsec, q-feeds und suricata (netmap, Überwachung auf den LAN Schnittstellen) und bin mir nicht sicher, ob all diese Tools sich sinnvoll ergänzen oder, ob es im Bestreben eine höhere Sicherheit in meinem Netzwerk zu gewährleisten z.B. durch Überschneidungen zu nachteiligen Effekten führen kann. Vielleicht macht es ein Tool überflüssig.
Jetzt mit OPNsense Version 26.1.1 gibt es noch die Möglichkeit suricata auf ,,divert-to" umzustellen. Macht das Sinn, wenn netmap stabil läuft auch in Hinblick auf die Zukunft?
Wo sollte eine entsprechende Regel sinnvollerweise platziert werden, welche Schnittstelle, vor q-feeds oder danach?

Somehow I had a hunch that this "one interface only" switch in the new rules scheme would cause problems., because it mixes up the priorities.

I created a group with only wan or whatever (that worked). I assigned this group a sequence that took precedence over all other groups, so that it was applied before all other group rules.

What do you mean by that second question? I do not quite understand.

What I meant was that if I allow everything except my "restricted group net", I don't need to specify separate IPv4 and IPv6 interfaces in an alias. My problem is that I don't have a static IPv6 address from Telekom, even though it admittedly changes very rarely.

These are the rules for the "Restricted" group:

Thank you for sharing.
May I ask what the aliases for the local network IPv4 and IPv6 actually look like?

You cannot view this attachment.

In your opinion, you could also use the interface group restricted itself, something like this
source: restricted net
destination: restricted net ?

So wie ich das verstanden habe hast du vorher im LAN einen "echten" Konnektor gehabt und nun auf einen HK (Highspeedkonnektor) per VPN gewechselt.

Nach Auslaufen der Zertifikatsgültigkeit der Einbox- Konnektoren, was von Konnektor zu Konnektor unterschiedlich ist, erfolgt eine Neuanbindung an die TI derzeit nur noch per TI Gateway per VPN.

Dann drängt sich mir als erstes auf, hast du die "alten" routen auf den jeweiligen Geräten Mac´s gelöscht ?
und dann die neuen gesetzt?

Die Routen sind spätestestens zum Zeitpunkt der Umstellung auf den Clients zu löschen und entsprechende Routen in der Firewall zu setzen.
Auch wenn Du nicht Tomedo nutzt, stellt Zollsoft eine Liste zur Verfügung:
https://support.tomedo.de/handbuch/tomedo/telematikinfrastruktur-ti/ports-und-routen-fuer-die-ti/

sind die Ports entsprechend angelegt worden? siehe PDF

Auch wenn ich den Link nicht öffne, nehme ich an, dass dort eine Aufstellung zu finden ist, welche ausgehenden Ports freigegeben sein sollen. Da es sich bei der OPNsense um eine statefull Firewall handelt, müssen keine ausgehenden Ports definiert werden. Antwortpakete von aussen werden zugelassen, wenn sie zu dem gesetzten "state" passen.
Die jedoch zu definierende NAT Regel ist eine outbond Regel zur Maskierung auf eine dem TI-Konnektor bekannte IP (lokale Tunnel IP, die in der Konfiguration vorgegeben ist).

P.s. IPsec Ports müssen auf der WAN Schnittstelle natürlich erlaubt sein als Grundvoraussetzung damit IPsec überhaupt funktionieren kann.

Muss ich das OS dann zurück setzen?

Nein, nutze selber 25.7.10.

Hast du bei der Child Konfigurationen den Punkt Richtlinien deaktiviert? (siehe screenshot)