OPNsense - IPsec Site-to-Site route-based

Aus maxTechCorner

Auf einen Blick

Gilt fürOPNsense 26.1 und 26.7 (VPN → IPsec → Connections + Virtual Tunnel Interfaces), IKEv2, optional Plugin os-frr
BereichIT-Security
Dauerca. 45 Minuten pro Standortpaar
RechteAdministrator (OPNsense-WebUI) auf beiden Firewalls
StandOktober 2026 (OPNsense 26.7.5)

Ein IPsec Site-to-Site-VPN im route-based Modus – auch VTI (Virtual Tunnel Interface) genannt – verbindet zwei Standorte über eine virtuelle Tunnelschnittstelle. Der IPsec-Tunnel verhält sich dann wie eine normale Netzwerkverbindung: Welche Netze hindurch gehen, entscheiden Routen – statisch oder dynamisch per BGP/OSPF – statt fest konfigurierter Policies. Das macht route-based IPsec zur ersten Wahl für Umgebungen mit vielen Netzen, mehreren Standorten, Redundanz und Cloud-Anbindungen. Dieser Artikel zeigt die Einrichtung auf OPNsense mit der aktuellen Connections-Oberfläche (Stand 2026).

Die Grundlagen der Connections-Oberfläche und den einfacheren policy-based Modus beschreibt der Artikel OPNsense - IPsec Site-to-Site policy-based.

Warum route-based IPsec?

Beim policy-based Modus muss jedes Netzpaar als eigene Policy auf beiden Seiten gepflegt werden. Route-based IPsec trennt den Tunnel (Verschlüsselung) vom Routing (Wegewahl):

  • Neue Netze ohne Tunnel-Änderung: Es genügt eine zusätzliche Route.
  • Dynamisches Routing: BGP oder OSPF über den Tunnel mit dem Plugin os-frr – Netze werden automatisch bekannt gegeben.
  • Monitoring und Failover: Der Tunnel ist ein Gateway mit Gateway-Monitoring; mit zwei Tunneln über zwei Internetleitungen sind Gateway-Gruppen bzw. BGP-Failover möglich.
  • Firewall-eigener Verkehr: Dienste der Firewall selbst (DNS, NTP, Syslog, Monitoring) erreichen die Gegenseite ohne Umwege.
  • Cloud-kompatibel: Microsoft Azure, AWS und viele Hersteller (Fortinet, Palo Alto, Cisco) setzen bei Site-to-Site-VPNs auf route-based IPsec.
Kriterium Policy-based Route-based (VTI)
Was gelangt in den Tunnel? Was zu einer Policy passt Was per Route zum Tunnel-Gateway zeigt
Zusätzliche Konfiguration Keine VTI, Gateway, Routen
Dynamisches Routing Nein Ja (os-frr: BGP, OSPF)
Gegenstelle per DNS-Name Ja Nein, nur feste IP-Adressen
IPsec route-based auf der OPNsense: Der Tunnel ist die Schnittstelle ipsec10 mit Transfernetz 10.255.0.0/30; ein Child mit 0.0.0.0/0 und deaktivierten Policies, Gateways und Routen (oder BGP) entscheiden, welcher Verkehr hindurch geht.

Beispiel-Szenario

Eigenschaft Standort A (Zentrale) Standort B (Filiale)
Öffentliche WAN-IP (fest) 203.0.113.1 198.51.100.1
Lokales Netz (LAN) 192.168.10.0/24 192.168.20.0/24
Tunnel-Adresse (Transfernetz 10.255.0.0/30) 10.255.0.1 10.255.0.2
Reqid / Schnittstelle 10 → ipsec10


HinweisVTI-Tunnel benötigen feste IP-Adressen auf beiden Seiten. DNS-Namen als Endpunkt sind wegen Einschränkungen von if_ipsec(4) unter FreeBSD nicht möglich. Hat ein Standort keine feste IP, ist der policy-based Modus oder ein Overlay wie NetBird die bessere Wahl.

Schritt 1: WAN-Regeln für IPsec

Wie beim policy-based Modus legen Connections keine WAN-Regeln automatisch an. Unter Firewall → Rules mit Interface WAN auf beiden Seiten erlauben – jeweils mit Quelle = WAN-IP der Gegenstelle, Ziel = WAN address:

  • UDP 500 (IKE), UDP 4500 (NAT-Traversal), Protokoll ESP.

Schritt 2: Virtual Tunnel Interface anlegen

VPN → IPsec → Virtual Tunnel Interfaces öffnen und mit + auf beiden Seiten eine VTI anlegen:

Feld Standort A Standort B
Reqid 10 (frei wählbar, aber eindeutig über alle VTIs der Firewall)
Local address 203.0.113.1 198.51.100.1
Remote address 198.51.100.1 203.0.113.1
Tunnel local address 10.255.0.1 10.255.0.2
Tunnel remote address 10.255.0.2 10.255.0.1
Description VTI Filiale VTI Zentrale

Speichern und anwenden – OPNsense erzeugt die Schnittstelle ipsec10. Die Reqid verknüpft später die Schnittstelle mit der IPsec-Sicherheitszuordnung.

Schritt 3: Pre-Shared Key hinterlegen

Unter VPN → IPsec → Pre-Shared Keys einen Eintrag mit Local Identifier (eigene WAN-IP), Remote Identifier (WAN-IP der Gegenstelle), einem langen Zufallsschlüssel (z. B. openssl rand -base64 32) und Type PSK anlegen – auf Standort B spiegelbildlich.

Schritt 4: Connection anlegen

VPN → IPsec → Connections: Enable IPsec aktivieren, mit + eine Verbindung anlegen und den advanced mode einschalten:

Feld Standort A Standort B
Proposals aes256gcm16-sha384-ecp384 (default entfernen)
Version IKEv2
Unique Replace
Local addresses 203.0.113.1 198.51.100.1
Remote addresses 198.51.100.1 203.0.113.1
DPD delay (s) 30

Save, danach Authentifizierung ergänzen:

  • Local Authentication: Pre-Shared Key, Id = eigene WAN-IP.
  • Remote Authentication: Pre-Shared Key, Id = WAN-IP der Gegenstelle.

Schritt 5: Child für den VTI anlegen

Das Child ist auf beiden Seiten identisch:

Feld Wert
Mode Tunnel
Reqid 10 (muss zur VTI passen)
Policies deaktiviert
Start action Trap
DPD action Restart
ESP proposals aes256gcm16-ecp384
Local 0.0.0.0/0
Remote 0.0.0.0/0


HinweisBei route-based Tunneln unbedingt den Haken bei „Policies“ entfernen. Mit aktivierten Policies und Selektoren 0.0.0.0/0 würde sämtlicher Verkehr in den Tunnel gefangen – die Firewall wäre dann nicht mehr erreichbar.

Child und Connection speichern und auf der Übersichtsseite Apply klicken. Unter VPN → IPsec → Status Overview sollte der Tunnel nun aufgebaut sein.

Schritt 6: Tunnelschnittstelle zuweisen

Die Schnittstelle als eigenes Interface zuzuweisen ist für Gateway und Routen nicht zwingend, aber empfohlen – für eigene Firewall-Regeln pro Tunnel, für Normalisierungsregeln (MSS) und für dynamisches Routing:

  1. Interfaces → Assignments: Gerät ipsec10 hinzufügen, Beschreibung z. B. VTI_FILIALE.
  2. Interfaces → [VTI_FILIALE]: Enable und Prevent interface removal aktivieren. Keine IP-Adresse eintragen – die Tunneladressen kommen aus der VTI-Konfiguration.
  3. Save und Apply changes.

Schritt 7: Gateway anlegen

System → Gateways → Configuration mit +:

Feld Standort A Standort B
Name VTI_FILIALE_GW VTI_ZENTRALE_GW
Interface VTI_FILIALE (bzw. IPSEC10) VTI_ZENTRALE (bzw. IPSEC10)
Address Family IPv4
IP address 10.255.0.2 10.255.0.1

Das Gateway-Monitoring (dpinger) prüft die Gegenstelle laufend per Ping über den Tunnel. Unter System → Gateways → Configuration bzw. im Dashboard-Widget sind Status, Latenz und Paketverlust des Tunnels damit jederzeit sichtbar.

Schritt 8: Statische Routen

System → Routes → Configuration mit +:

  • Standort A: Network Address 192.168.20.0/24, Gateway VTI_FILIALE_GW
  • Standort B: Network Address 192.168.10.0/24, Gateway VTI_ZENTRALE_GW

Weitere Netze der Gegenseite werden einfach als zusätzliche Routen eingetragen – der Tunnel selbst bleibt unverändert.

Schritt 9: Firewall-Regeln für den Tunnelverkehr

Eingehender Verkehr aus dem Tunnel muss erlaubt werden:

  • entweder global unter Firewall → Rules mit Interface IPsec (gilt für alle IPsec-Tunnel),
  • oder – bei zugewiesener Schnittstelle – gezielt unter Firewall → Rules mit Interface VTI_FILIALE.

Beispiel Standort A: Pass, Quelle 192.168.20.0/24, Ziel 192.168.10.0/24. Für Gateway-Monitoring und dynamisches Routing zusätzlich ICMP bzw. BGP (TCP 179) zwischen den Tunneladressen erlauben.

Schritt 10: MTU und MSS anpassen

IPsec-Kapselung kostet je nach Verfahren 50–80 Byte. Damit große TCP-Pakete nicht fragmentiert oder verworfen werden (typisches Symptom: Ping und kleine Webseiten gehen, Dateiübertragungen oder RDP hängen), die MSS begrenzen:

  1. Firewall → Settings → Normalization öffnen und eine Regel hinzufügen.
  2. Interface: die zugewiesene VTI-Schnittstelle, Max mss: z. B. 1360.
  3. Speichern und anwenden – auf beiden Seiten.

Erweiterte Szenarien

Dynamisches Routing mit BGP über den Tunnel

Mit dem Plugin os-frr (System → Firmware → Plugins) kann OPNsense Routen per BGP oder OSPF austauschen. Für BGP über den VTI:

  1. Plugin installieren, unter Routing → General aktivieren.
  2. Unter Routing → BGP eigene AS-Nummer (privat, z. B. 65001 bzw. 65002) und Router-ID setzen.
  3. Als Neighbor die Tunneladresse der Gegenstelle (10.255.0.2) mit deren AS eintragen.
  4. Die eigenen LAN-Netze unter Networks ankündigen bzw. per Route-Map filtern.

Die statischen Routen aus Schritt 8 entfallen dann. Neue Netze werden automatisch verteilt – ideal für Umgebungen mit vielen Standorten oder Cloud-Anbindungen (Azure VPN Gateway und AWS Site-to-Site-VPN unterstützen BGP über IPsec). Filter, Peer Groups und Hochverfügbarkeit beschreibt der Artikel OPNsense - BGP mit FRR; alternativ eignet sich OSPF (Network Type Point-to-point).

Redundanz über zwei Internetleitungen

Für ausfallsichere Standortkopplung zwei VTIs mit unterschiedlichen Reqids (z. B. 10 und 11) und eigenen Transfernetzen über beide WAN-Leitungen aufbauen. Anschließend entweder:

  • eine Gateway-Gruppe (System → Gateways → Group) mit Tier 1/Tier 2 bilden und die Routen darauf zeigen lassen, oder
  • beide Tunnel als BGP-Nachbarn betreiben – BGP schwenkt bei Ausfall automatisch um, mit BFD in unter einer Sekunde.

Typische Probleme und Lösungen

Symptom Ursache und Lösung
Firewall nach Apply nicht mehr erreichbar Policies im Child aktiviert – deaktivieren (ggf. über Konsole/LAN). Bei Bedarf eigene Netze unter Advanced Settings → Passthrough networks ausnehmen.
Tunnel steht, aber kein Verkehr Reqid in VTI und Child unterschiedlich; Route oder Gateway fehlt; Regel unter Firewall → Rules (Interface IPsec bzw. VTI) fehlt.
Gateway wird als „offline“ angezeigt ICMP über den Tunnel nicht erlaubt oder Gegenseite noch nicht konfiguriert; Monitor-IP prüfen.
Große Übertragungen hängen MTU/MSS – Normalisierungsregel mit Max mss setzen.
Fremdgerät baut keinen Tunnel auf Gegenstelle muss route-based bzw. Traffic Selectors 0.0.0.0/0 unterstützen; sonst policy-based verwenden.
Tunnel mit DNS-Namen funktioniert nicht VTIs unterstützen nur feste IP-Adressen.

Empfehlungen

  • IKEv2 mit AES-GCM und modernen Diffie-Hellman-Gruppen (ECP256/384, Curve25519, MODP3072+) verwenden; ESP immer mit DH-Gruppe für Perfect Forward Secrecy.
  • Transfernetze dokumentieren (z. B. ein /30 pro Tunnel aus einem reservierten Bereich wie 10.255.0.0/16).
  • Gateway-Monitoring nutzen und Alarme einrichten; IPsec-Logs zentral auswerten, z. B. in einem Open-Source-SIEM auf Wazuh-Basis.
  • Legacy-Tunnel migrieren: Seit OPNsense 26.1 gibt es die alte Tunnel-Oberfläche nur noch per Plugin os-strongswan-legacy. Bestehende Tunnel planvoll auf Connections umstellen – idealerweise gleich auf route-based.

Fazit

Route-based IPsec mit VTI erfordert ein paar Schritte mehr als der policy-based Modus, zahlt sich aber schnell aus: Netze werden per Route oder BGP gepflegt statt per Policy, der Tunnel lässt sich wie jede andere Verbindung überwachen und redundant auslegen, und auch Cloud-Plattformen lassen sich sauber anbinden. Für moderne Standortvernetzungen mit OPNsense ist route-based heute die empfehlenswerte Standardlösung.

Unterstützung von m.a.x. it

Ob Mehrstandort-Vernetzung mit BGP, redundante Tunnel über zwei Leitungen, Anbindung an Azure oder AWS oder die Migration bestehender Legacy-Tunnel: 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_route-based&oldid=3934“