OPNsense - IPsec Site-to-Site policy-based

Aus maxTechCorner

Auf einen Blick

Gilt fürOPNsense 26.1 und 26.7 (VPN → IPsec → Connections), IKEv2, Gegenstelle OPNsense oder Fremdhersteller
BereichIT-Security
Dauerca. 30 Minuten pro Standortpaar
RechteAdministrator (OPNsense-WebUI) auf beiden Firewalls
StandOktober 2026 (OPNsense 26.7.5)

Ein IPsec Site-to-Site-VPN im policy-based Modus verbindet zwei Standorte, indem für festgelegte Netzpaare – z. B. LAN Zentrale ↔ LAN Filiale – Sicherheitsrichtlinien (Policies) im Kernel installiert werden. Jedes Paket, das zu einer Policy passt, wird automatisch verschlüsselt und durch den Tunnel geschickt; Routen, Gateways oder zusätzliche Schnittstellen sind nicht nötig. Dieser Artikel zeigt die Einrichtung auf OPNsense mit der aktuellen Connections-Oberfläche (Stand 2026).

Die Alternative mit virtueller Tunnelschnittstelle und normalem Routing beschreibt der Artikel OPNsense - IPsec Site-to-Site route-based.

Policy-based oder route-based? IPsec-Modi im Vergleich

Kriterium Policy-based Route-based (VTI)
Funktionsweise Kernel-Policies für feste Netzpaare fangen den Verkehr ab („Traps“) Virtuelle Schnittstelle ipsecX, danach gilt normales Routing
Einrichtung Schnell, keine Gateways oder Routen Zusätzlich VTI, Gateway und Routen
Neue Netze hinzufügen Neue Policy (Child) auf beiden Seiten Nur eine Route bzw. dynamisches Routing
Dynamisches Routing (BGP/OSPF) Nicht möglich Möglich (Plugin os-frr)
Tunnel-Monitoring, Failover Eingeschränkt Gateway-Monitoring, Gateway-Gruppen, BGP
Gegenstellen mit DNS-Namen Möglich Nicht möglich (nur feste IPs)
Kompatibilität Sehr hoch, Standard bei vielen Herstellern Gegenstelle muss route-based/0.0.0.0/0-Selektoren unterstützen
Typischer Einsatz Einfache Kopplung weniger Netze, Partner-VPNs Viele Netze, mehrere Standorte, Redundanz, Cloud (Azure, AWS)
IPsec policy-based auf der OPNsense: Connection und Children mit aktivierten Policies – für jedes Netzpaar eine Kernel-Policy, die den Verkehr direkt in den Tunnel leitet; keine Gateways und keine Routen nötig.

Was sich bei IPsec in OPNsense geändert hat (Stand 2026)

  • Seit OPNsense 23.1 werden IPsec-Verbindungen unter VPN → IPsec → Connections im strongSwan-Format swanctl.conf konfiguriert. Die Begriffe folgen strongSwan: Aus Phase 1 wird die Connection, aus Phase 2 das Child.
  • Mit OPNsense 26.1 ist die alte Oberfläche Tunnel Settings [legacy] aus dem Kern verschwunden. Sie steht nur noch über das Community-Plugin os-strongswan-legacy zur Verfügung – ausschließlich als Übergangslösung für bestehende Tunnel.
  • Neue Tunnel sollten immer über Connections angelegt werden. Für die Umstellung bestehender Tunnel gibt es in der OPNsense-Dokumentation eine Migrationsanleitung sowie das Community-Werkzeug opnsense-ipsec-converter.
  • Seit OPNsense 26.7 werden Firewall-Regeln einheitlich unter Firewall → Rules mit Auswahl der Schnittstelle gepflegt; die alten Regelseiten gibt es nur noch im Plugin os-firewall-legacy. Die Menüpfade in diesem Artikel beziehen sich auf 26.7.
  • Wichtig: Connections legen – anders als die alte Oberfläche – keine WAN-Regeln automatisch an.

Beispiel-Szenario

Eigenschaft Standort A (Zentrale) Standort B (Filiale)
Öffentliche WAN-IP 203.0.113.1 198.51.100.1
Lokales Netz (LAN) 192.168.10.0/24 192.168.20.0/24
IKE-Identität 203.0.113.1 198.51.100.1

Die Netze beider Standorte dürfen sich nicht überschneiden. Alle Schritte werden auf beiden Firewalls spiegelbildlich durchgeführt.

Schritt 1: WAN-Regeln für IPsec anlegen

Unter Firewall → Rules mit Interface WAN drei Regeln anlegen, jeweils mit Quelle = WAN-IP der Gegenstelle und Ziel = WAN address:

Protokoll Port Zweck
UDP 500 IKE (Schlüsselaustausch)
UDP 4500 NAT-Traversal (IKE und ESP gekapselt in UDP)
ESP – Verschlüsselte Nutzdaten ohne NAT

Die Quelle auf die Gegenstelle zu beschränken, verhindert, dass der IKE-Dienst aus dem ganzen Internet erreichbar ist.

Schritt 2: Pre-Shared Key hinterlegen

Der Schlüssel wird in OPNsense getrennt von der Verbindung gespeichert:

  1. VPN → IPsec → Pre-Shared Keys öffnen und mit + einen Eintrag anlegen.
  2. Local Identifier: eigene Identität (Standort A: 203.0.113.1).
  3. Remote Identifier: Identität der Gegenstelle (Standort A: 198.51.100.1). Das Feld ist optional, sollte aber immer gesetzt werden – sonst gilt der Schlüssel für alle Verbindungen mit derselben lokalen Identität.
  4. Pre-Shared Key: langen Zufallswert eintragen, z. B. erzeugt mit openssl rand -base64 32, Type = PSK.


HinweisStatt Pre-Shared Keys lassen sich auch Schlüsselpaare (VPN → IPsec → Key Pairs) oder Zertifikate verwenden. Bei Verbindungen zu Dritten sind Zertifikate bzw. Schlüsselpaare die sicherere Wahl, weil kein gemeinsames Geheimnis ausgetauscht werden muss.

Schritt 3: Connection anlegen (früher Phase 1)

  1. VPN → IPsec → Connections öffnen, unten Enable IPsec aktivieren und mit + eine neue Verbindung anlegen.
  2. Oben rechts den advanced mode einschalten.
  3. Folgende Werte setzen:
Feld Standort A Standort B Hinweis
Proposals aes256gcm16-sha384-ecp384 Auf beiden Seiten identisch; default entfernen
Version IKEv2 IKEv1 nur für Altgeräte
Unique Replace Doppelte Verbindungen werden ersetzt
Local addresses 203.0.113.1 198.51.100.1 Leer = beliebige lokale Adresse
Remote addresses 198.51.100.1 203.0.113.1 Bei policy-based auch DNS-Name möglich
DPD delay (s) 30 Dead Peer Detection ist standardmäßig aus
Description Filiale Zentrale
  1. Save klicken – danach erscheinen die Bereiche für Authentifizierung und Children.

Lokale und entfernte Authentifizierung

Bereich Feld Standort A Standort B
Local Authentication Authentication / Id Pre-Shared Key / 203.0.113.1 Pre-Shared Key / 198.51.100.1
Remote Authentication Authentication / Id Pre-Shared Key / 198.51.100.1 Pre-Shared Key / 203.0.113.1

Die IDs müssen exakt zu den Einträgen unter Pre-Shared Keys passen. Manche Fremdgeräte erlauben keine frei wählbare ID und melden sich mit ihrer IP-Adresse – das muss bei der Remote-ID berücksichtigt werden.

Schritt 4: Child anlegen (früher Phase 2)

Im Bereich Children mit + ein Child hinzufügen:

Feld Standort A Standort B
Mode Tunnel
Policies aktiviert (das macht den Tunnel policy-based)
Start action Trap (Tunnel startet beim ersten passenden Paket) oder Start (sofort)
DPD action Restart
ESP proposals aes256gcm16-ecp384 (mit DH-Gruppe = Perfect Forward Secrecy)
Local 192.168.10.0/24 192.168.20.0/24
Remote 192.168.20.0/24 192.168.10.0/24

Save, dann die Connection erneut mit Save speichern und auf der Übersichtsseite Apply klicken.

Mehrere Netze verbinden

  • Mehrere Netze in einem Child (kommagetrennt): strongSwan behandelt alle lokalen und entfernten Netze als eine Policy – jedes lokale Netz darf mit jedem entfernten sprechen.
  • Ein Child pro Netzpaar: entspricht der früheren Option Tunnel Isolation und ist bei Fremdherstellern (z. B. ältere Cisco-, Sophos- oder Fortinet-Konfigurationen), die jedes Netzpaar einzeln aushandeln, oft die kompatiblere Variante.

Schritt 5: Firewall-Regeln für den Tunnelverkehr

OPNsense blockiert auch Verkehr aus dem Tunnel, solange er nicht erlaubt ist. Unter Firewall → Rules mit Interface IPsec eine Regel anlegen, z. B. auf Standort A:

  • Action: Pass, Quelle: 192.168.20.0/24, Ziel: 192.168.10.0/24, Protokoll und Ports nach Bedarf.

Für Verkehr von der Zentrale in die Filiale genügt in der Regel die bestehende LAN-Regel; die Rückantworten erlaubt die Stateful Firewall automatisch.

Schritt 6: Tunnel prüfen

  • VPN → IPsec → Status Overview zeigt, ob Connection (IKE_SA) und Child (CHILD_SA) aufgebaut sind.
  • Security Association Database und Security Policy Database zeigen die ausgehandelten SAs und installierten Policies.
  • VPN → IPsec → Log File zeigt die Aushandlung im Detail.
  • Test: von einem Client im LAN A einen Client im LAN B anpingen.


HinweisEin Ping von der Firewall selbst (z. B. unter Interfaces → Diagnostics → Ping) läuft standardmäßig mit der WAN-Adresse als Absender und passt damit zu keiner Policy – er scheitert, obwohl der Tunnel funktioniert. Als Quelladresse die LAN-Schnittstelle wählen. Sollen Dienste der Firewall (DNS, NTP, Syslog) die Gegenseite erreichen, ist der route-based Modus deutlich einfacher.

Typische Probleme und Lösungen

Symptom Ursache und Lösung
Kein Verbindungsaufbau, im Log keine Antwort der Gegenstelle WAN-Regeln (UDP 500/4500, ESP) fehlen auf einer Seite oder ein vorgeschalteter Router blockiert/verändert IPsec.
NO_PROPOSAL_CHOSEN Proposals bzw. ESP proposals stimmen nicht überein – beide Seiten exakt gleich konfigurieren.
AUTHENTICATION_FAILED Pre-Shared Key oder Local/Remote-ID passen nicht; ID-Typ der Gegenstelle prüfen.
TS_UNACCEPTABLE Traffic Selectors (Local/Remote im Child) sind auf beiden Seiten nicht spiegelbildlich.
Tunnel steht, aber kein Verkehr Regel unter Firewall → Rules (Interface IPsec) fehlt, Ziel-Host hat abweichendes Gateway oder lokale Firewall (z. B. Windows) blockiert.
Firewall selbst nicht mehr erreichbar Eine Policy überdeckt eigene Netze. Eigene Segmente unter VPN → IPsec → Advanced Settings → Passthrough networks ausnehmen.
Gleiche Netze an beiden Standorten Netzüberschneidung per NAT auflösen, siehe OPNsense - NAT before IPSEC.
Tunnel bricht nach Stunden ab DPD aktivieren (DPD delay > 0) und Lebensdauern (Rekey) auf beiden Seiten abgleichen.

Empfehlungen für sichere IPsec-Verbindungen

  • Nur IKEv2 verwenden, IKEv1 und Aggressive Mode vermeiden.
  • Moderne Kryptografie: AES-GCM, SHA-2 und Diffie-Hellman-Gruppen ab ECP256/MODP3072 bzw. Curve25519. Alte Gruppen wie MODP1024 (DH2) gelten als unsicher und werden in den Connections nicht mehr angeboten. Ist eine Altgegenstelle darauf angewiesen, gehört sie modernisiert – nicht der Tunnel geschwächt. Für ESP immer eine DH-Gruppe angeben, damit Perfect Forward Secrecy greift.
  • Lange, zufällige Pre-Shared Keys oder besser Zertifikate verwenden und Schlüssel im Passwortmanager dokumentieren.
  • Tunnel überwachen – z. B. per Monit wie in Überwachung von IPsec beschrieben – und die IPsec-Logs an ein SIEM weiterleiten.
  • Firmware aktuell halten: OPNsense erscheint zweimal jährlich (Januar, Juli) mit regelmäßigen Minor-Updates.

Fazit

Der policy-based Modus ist der schnellste Weg zu einem stabilen IPsec-Site-to-Site-Tunnel: Netzpaare festlegen, Verbindung und Child anlegen, WAN- und IPsec-Regeln setzen – fertig. Er ist ideal für überschaubare Kopplungen und Partner-VPNs mit Fremdherstellern. Sobald mehrere Netze, Redundanz, Monitoring oder dynamisches Routing gefragt sind, ist der route-based Modus mit VTI die bessere Wahl.

Unterstützung von m.a.x. it

Sie möchten Standorte per IPsec vernetzen, Tunnel von der alten Legacy-Oberfläche auf Connections migrieren oder VPNs zu Partnern und Cloud-Anbietern aufbauen? m.a.x. it unterstützt Sie als OPNsense-Gold-Partner mit OPNsense-Firewall-Services von m.a.x. it und einer Managed Firewall von m.a.x. it.

Siehe auch

Links und Quellen


Über m.a.x. it Die m.a.x. Informationstechnologie AG ist seit über 30 Jahren IT-Partner mittelständischer und großer Unternehmen in München und bietet maßgeschneiderte Lösungen und Services in den Bereichen Cloud, Cybersecurity, Netzwerk, Windows, Linux und Softwareentwicklung. Sie haben eine Frage zu diesem Artikel oder brauchen Unterstützung? Kontakt aufnehmen

Abgerufen von „http://techcorner.max-it.de/index.php?title=OPNsense_-_IPsec_Site-to-Site_policy-based&oldid=3931“