Ein Road-Warrior-VPN verbindet einzelne Endgeräte, aber wenn zwei Büros, ein Rechenzentrum und eine Filiale oder mehrere Cloud-Instanzen dauerhaft als ein gemeinsames Netz agieren sollen, brauchst du ein Site-to-Site-VPN. OPNsense bietet dafür drei ernsthafte Optionen: WireGuard, IPsec (IKEv2 mit VTI) und OpenVPN. Welches Protokoll für dein Szenario die beste Wahl ist, wie du saubere Routing- und Firewall-Regeln zwischen den Netzen aufbaust, überlappende Subnetze auflöst und asymmetrisches Routing oder MTU-Blackholes diagnostizierst – das zeigt dieser Leitfaden konkret und ohne Umwege.

Voraussetzungen

Zwei oder mehr OPNsense-Instanzen (Hardware-Appliance, VM oder Cloud) mit OPNsense ≥ 23.7 (empfohlen: aktuelles Release 25.7)
Statische WAN-IP auf mindestens einem Standort (dynamische IP auf der Gegenseite ist mit PersistentKeepalive möglich)
Dediziertes Transfer-/Tunnel-Subnetz pro Verbindung (z. B. 10.2.2.0/30 für WireGuard oder 10.111.1.0/30 für IPsec VTI)
Einzigartiger privater Adressraum je Standort – kein Subnetz-Overlap (bei Overlap siehe Abschnitt „Überlappende Subnetze")
Für Hub-and-Spoke mit dynamischem Routing: Bird2-Plugin (os-frr oder os-bird) auf OPNsense installiert
Grundkenntnisse OPNsense-Firewall (Regeln, NAT, Routing) – ggf. zuerst OPNsense Firewall Erstkonfiguration lesen

Schritt 1: Protokoll wählen – WireGuard, IPsec oder OpenVPN?

Bevor du auch nur einen Peer konfigurierst, solltest du die richtige Technologie wählen. Die folgende Tabelle fasst die entscheidenden Kriterien zusammen:

Kriterium	WireGuard	IPsec IKEv2 VTI	OpenVPN
Konfigurationsaufwand	Sehr gering	Mittel	Mittel–Hoch
Durchsatz (Highend, iPerf3 -P4)	~5,0 Gbit/s	~4,3 Gbit/s	~1,1 Gbit/s
Durchsatz (Einstieg VP2410)	~900 Mbit/s	~889 Mbit/s	~475 Mbit/s
Interoperabilität (Fremdgeräte)	Eingeschränkt	Sehr gut	Gut (eigene CA nötig)
Dynamisches Routing (OSPF/BGP)	Mit Bird2/FRR	Nativ per VTI	Möglich
NAT-Traversal	Nativ (UDP)	UDP 4500 (NAT-T)	TCP/UDP flexibel
Compliance / Audit	Eingeschränkt	BSI TR-02102 konform	Eingeschränkt
OPNsense 25.7 Status	Plugin os-wireguard	swanctl (IKEv2 only)	Integriert

Faustregel: OPNsense ↔ OPNsense oder Linux-Gegenstelle → WireGuard. Cisco, FortiGate, Azure VPN Gateway, AWS Site-to-Site VPN oder BSI-Compliance → IPsec IKEv2 VTI. OpenVPN nur als Rückfalloption oder für Road Warriors.

Hinweis zu OPNsense 25.7: Das Legacy-IPsec-Interface (racoon-basiert) wurde vollständig entfernt. Es steht ausschließlich das swanctl/IKEv2-Interface zur Verfügung. Wer noch policy-basierte Phase-2-Konfigurationen aus älteren Versionen nutzt, muss migrieren.

Schritt 2: WireGuard Site-to-Site einrichten

Im folgenden Beispiel verbindest du Site A (LAN: 172.16.0.0/24) mit Site B (LAN: 192.168.0.0/24) über das Transfer-Netz 10.2.2.0/30.

2.1 Plugin installieren und lokale Instanz anlegen

Installiere das Plugin unter System > Firmware > Plugins: os-wireguard. Nach der Installation erscheint unter VPN > WireGuard das Konfigurationsmenü. Lege auf beiden OPNsense-Instanzen je eine Local-Instanz an:

Site A – Local: Listen Port 51820, Tunnel Address 10.2.2.1/30, privaten Schlüssel generieren lassen (öffentlichen Schlüssel notieren)
Site B – Local: Listen Port 51820, Tunnel Address 10.2.2.2/30, privaten Schlüssel generieren lassen (öffentlichen Schlüssel notieren)

Setze die MTU explizit auf 1420 (bei PPPoE-Uplink: 1412), um MTU-Blackholes von vornherein zu vermeiden.

2.2 Peers konfigurieren

Unter VPN > WireGuard > Peers trägst du die Gegenstelle ein. Die AllowedIPs bestimmen, welcher Traffic durch den Tunnel läuft – sie fungieren gleichzeitig als kryptografische Routingfilter:

# Site A konfiguriert Peer „Site B":
Public Key:   <öffentlicher Schlüssel von Site B>
Endpoint:     <WAN-IP Site B>:51820
AllowedIPs:   10.2.2.2/32, 192.168.0.0/24
# (Tunnel-Endpunkt-IP + gesamtes Remote-LAN)

# Site B konfiguriert Peer „Site A":
Public Key:   <öffentlicher Schlüssel von Site A>
Endpoint:     <WAN-IP Site A>:51820
AllowedIPs:   10.2.2.1/32, 172.16.0.0/24

Steht einer der Standorte hinter NAT (z. B. dynamische WAN-IP), setze PersistentKeepalive = 25 auf dem dortigen Peer. Ohne diesen Wert läuft die UDP-Session nach ~30 Sekunden Inaktivität ab – der Handshake wirkt noch aktiv, aber Traffic kommt nicht mehr durch.

2.3 Firewall-Regeln anlegen

OPNsense legt WireGuard-Regeln unter Firewall > Rules > WireGuard ab – nicht unter WAN oder LAN. Minimum-Regeln:

WAN Inbound: UDP, Port 51820, Source any → WAN-IP der OPNsense – damit der Peer die Verbindung aufbauen kann
WireGuard Inbound: Protocol any, Source 192.168.0.0/24 (Remote-LAN), Destination 172.16.0.0/24 (Local-LAN) – pass

2.4 No-NAT-Outbound-Regel – zwingend erforderlich

Ohne diese Regel masqueriert OPNsense den VPN-Traffic mit der WAN-IP. Die Gegenstelle antwortet dann an die WAN-IP statt ins Tunnel-Subnetz – der Tunnel funktioniert nur einseitig oder gar nicht. Lege unter Firewall > NAT > Outbound > Manual folgende Regel an:

Interface:    WAN
Source:       172.16.0.0/24
Destination:  192.168.0.0/24
Translation:  NO NAT (kein Haken bei „Translation / target")

Auf Site B dieselbe Regel spiegelverkehrt anlegen.

2.5 Statische Routen

Unter System > Routes > Configuration trägst du auf Site A eine Route für das Remote-LAN ein:

Network:   192.168.0.0/24
Gateway:   10.2.2.2   (Tunnel-Endpunkt Site B)

Auf Site B analog für 172.16.0.0/24 via 10.2.2.1.

2.6 Tunnel verifizieren

wg show wg0
# Zeigt: letzter Handshake, gesendete/empfangene Bytes, Endpoint
# In OPNsense GUI: VPN > WireGuard > Diagnostics

Steigen die Transfer-Werte beim Ping auf die Remote-LAN-IP, ist der Tunnel aktiv. Für einen Durchsatztest durch den Tunnel:

iperf3 -c <Remote-LAN-IP> -P 4 -t 60
# -P 4 = 4 parallele Streams, um Multi-Core-Durchsatz zu nutzen

Schritt 3: IPsec IKEv2 VTI (Route-based) einrichten

IPsec im VTI-Modus (Route-based) ist flexibler als der klassische Policy-based-Tunnel: Du kannst mehrere statische Routen oder sogar OSPF über denselben Tunnel legen. Der entscheidende Unterschied liegt in Phase 2.

3.1 Phase 1 konfigurieren

Unter VPN > IPsec > Tunnel Settings eine neue Phase-1-Verbindung anlegen:

IKE Version:          IKEv2
Remote Gateway:       <WAN-IP Site B>
Authentication:       Mutual PSK oder X.509
Encryption Algorithm: AES-256
Hash Algorithm:       SHA-512
DH Key Group:         14 (2048 Bit)
Lifetime:             28800 s

Für höhere Performance alternativ AES-128-GCM (AEAD, kein separater Hash nötig) mit DH Group 19 (256-Bit-ECDH). Beide Varianten erfüllen BSI TR-02102-3.

3.2 Phase 2 als Route-based (VTI) konfigurieren

Hier liegt der entscheidende Unterschied zum Policy-based-Tunnel:

Mode:              Route-based (VTI)
Local Network:     0.0.0.0/0   (Routing übernimmt die Routingtabelle)
Remote Network:    0.0.0.0/0
Tunnel Address:    10.111.1.1/30  (Site A) / 10.111.1.2/30  (Site B)
Install Policy:    DEAKTIVIERT    ← kritisch!
Encryption:        AES-256 / SHA-512 / DH Group 14
Lifetime:          3600 s

„Install Policy" muss deaktiviert sein, damit kein automatischer Policy-Filter den Traffic blockiert. Das Routing übernehmen ausschließlich statische Routen (oder ein Routing-Daemon).

3.3 Firewall-Ports und -Regeln

IPsec benötigt auf dem WAN-Interface folgende Freigaben:

UDP 500 (ISAKMP / IKE-Aushandlung)
UDP 4500 (NAT-T)
IP-Protokoll 50 (ESP – Encrypted Security Payload)

Unter Firewall > Rules > IPsec eine Inbound-Pass-Regel für den gewünschten Traffic anlegen. Die automatische pass out on enc0-Regel genügt nicht – ohne explizite Inbound-Regel auf dem IPsec-Interface wird der gesamte eingehende Tunnel-Traffic blockiert.

3.4 IPsec-Status prüfen

# GUI: VPN > IPsec > Status Overview
# Shell:
swanctl --list-sas
swanctl --list-conns
ipsec statusall

Beide Security Associations (IKE_SA und CHILD_SA) müssen als ESTABLISHED erscheinen.

Schritt 4: MTU und MSS korrekt setzen

MTU-Probleme sind der häufigste Grund, warum ein Tunnel zwar „up" ist, aber große Transfers (HTTP POST, Datei-Upload, Datenbankabfragen) lautlos abbrechen, während DNS, ICMP und SSH-Login problemlos funktionieren. Ursache: ICMP-Meldungen vom Typ „Fragmentation needed" (Typ 3 Code 4) werden von einer Firewall geblockt, sodass Path-MTU-Discovery versagt. Wer sich für die Hintergründe von Subnetting und Paketgrenzen interessiert, findet in Subnetting und CIDR verständlich erklärt eine gute Grundlage.

4.1 Optimale MTU ermitteln

# PMTU-Test mit DF-Bit (do not fragment), Payload schrittweise erhöhen:
ping -M do -s 1372 -c 3 <Remote-Tunnel-IP>
# WireGuard-MTU = größtes funktionierendes Payload + 28 (IPv4-Header + UDP)
# Faustregel: 1420 Byte bei Ethernet-Uplink, 1412 Byte bei PPPoE

4.2 MSS-Clamping aktivieren

Setze die maximale TCP-Segmentgröße auf mindestens 40 Byte unter der WireGuard-MTU (also ≤ 1380 bei MTU 1420). In OPNsense unter Firewall > Settings > Normalization eine Regel für das WireGuard-Interface anlegen:

# Alternativ direkt auf der Shell (wirkt sofort, aber nicht persistent):
iptables -t mangle -A FORWARD -o wg0 -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

Schritt 5: Hub-and-Spoke-Topologie und überlappende Subnetze

5.1 Hub-and-Spoke mit WireGuard

Bei drei oder mehr Standorten hast du zwei Topologien zur Auswahl: Hub-and-Spoke (alle Spokes verbinden sich nur mit dem Hub) oder Full-Mesh (jeder Standort hat direkte Peers zu allen anderen). Hub-and-Spoke ist einfacher zu warten, macht den Hub aber zum Single-Point-of-Failure.

Kritisch: AllowedIPs im Hub müssen alle Spoke-Subnetze explizit enthalten. WireGuard verteilt kein Routing automatisch:

# Hub: Peer-Konfiguration für Spoke 1
AllowedIPs: 10.2.2.2/32, 192.168.1.0/24

# Hub: Peer-Konfiguration für Spoke 2
AllowedIPs: 10.2.2.3/32, 192.168.2.0/24

# Spoke-zu-Spoke-Traffic läuft immer über den Hub (kein direkter Peer).
# Für direkten Spoke-zu-Spoke-Traffic: Full-Mesh oder OSPF via Bird2/FRR.

Damit der Hub den Traffic zwischen den Spokes auch weiterleitet, muss auf dem Hub eine Forwarding-Firewall-Regel für das WireGuard-Interface eingerichtet sein. Fehlt diese, kommt der Traffic am Hub an und wird verworfen – ein typischer, schwer zu findender Fehler.

5.2 Überlappende Subnetze auflösen

Haben beide Standorte dasselbe LAN-Subnetz (z. B. beide 192.168.1.0/24), ist direkte Kommunikation ohne NAT nicht möglich. WireGuard lehnt zwei Peers mit identischen AllowedIPs-Subnetzen ab. Die sauberste Lösung ist eine Neuplanung der Adressräume (dringend empfohlen). Als Übergangslösung: 1:1-NAT auf ein Proxy-Subnetz.

Site A mappt 192.168.1.0/24 → Proxy 10.99.1.0/24
Site B mappt 192.168.1.0/24 → Proxy 10.99.2.0/24

Hosts auf Site A sprechen 10.99.2.x an (= Hosts auf Site B, gemappt)
Firewall übersetzt: 10.99.2.x → 192.168.1.x auf Site B

OPNsense: Firewall > NAT > 1:1

Troubleshooting / Typische Fehler

MTU-Blackhole: Kleine Pakete funktionieren, große TCP-Transfers brechen ab. Ursache: WireGuard-MTU nicht gesetzt oder ICMP „Fragmentation needed" wird gefiltert. Lösung: MTU explizit auf 1420 (PPPoE: 1412) setzen, MSS-Clamping aktivieren.
IPsec „up", kein Traffic: Fehlende Inbound-Firewall-Regel auf dem IPsec-Interface (Firewall > Rules > IPsec). Die pass out on enc0-Regel reicht nicht aus.
NAT überschreibt VPN-Traffic: Ohne No-NAT-Outbound-Regel masqueriert OPNsense den Tunnel-Traffic mit der WAN-IP. Verbindung funktioniert nur einseitig oder gar nicht.
WireGuard hinter NAT ohne PersistentKeepalive: UDP-Session läuft nach ~30 s Inaktivität ab. wg show zeigt noch einen Handshake, aber kein Traffic fließt. Lösung: PersistentKeepalive = 25 auf dem Peer hinter NAT setzen.
Asymmetrisches Routing: OPNsense (FreeBSD) verwirft Pakete, bei denen Antwort-Route und Ankunfts-Interface nicht übereinstimmen. Diagnose:

# Route prüfen:
ip route get 192.168.0.1
# Erwartet: dev wg0 src 10.2.2.1
# Falls falsches Interface: statische Route unter System > Routing prüfen

# rp_filter auf loose setzen (persistent in OPNsense):
# System > Settings > Tunables
# net.inet.ip.check_interface = 0

MOBIKE + CARP/HA: Bei Hochverfügbarkeit mit CARP destabilisiert MOBIKE den IPsec-Tunnel beim VIP-Failover. Lösung: MOBIKE in der IKEv2-Konfiguration deaktivieren.
Policy-based statt Route-based (IPsec): Policy-based erlaubt nur statisch definierte Subnetz-Paare; dynamisches Routing ist nicht möglich. „Install Policy" muss beim VTI-Modus deaktiviert sein.
Firewall-Regeln auf falschem Interface: WireGuard-Regeln gehören unter die WireGuard-Gruppe, IPsec-Regeln unter das IPsec-Interface – nicht unter WAN oder LAN.
Hub-and-Spoke: Spoke-zu-Spoke-Traffic vergessen: Ohne Forwarding-Regel auf dem Hub wird der Traffic verworfen. AllowedIPs aller Spokes müssen im jeweiligen Peer-Eintrag des Hubs gepflegt sein.

Häufige Fragen

Wann WireGuard, wann IPsec für Site-to-Site?

WireGuard für OPNsense-zu-OPNsense oder Linux-Gegenstellen: einfachste Einrichtung, geringster Overhead, ~5 Gbit/s auf Highend-Hardware. IPsec IKEv2 VTI für Interoperabilität mit Cisco, FortiGate, Azure/AWS VPN Gateway, Juniper oder wenn Compliance bestimmte Cipher-Suites (BSI TR-02102-3) vorschreibt. OpenVPN nur als Rückfalloption oder für Road Warriors.

Wie verbinde ich drei oder mehr Standorte?

Zwei Topologien: Hub-and-Spoke – alle Spokes haben nur einen Peer (den Hub), der Hub routet weiter; einfach zu warten, Hub ist Single-Point-of-Failure. Full-Mesh – jeder Standort hat direkte Peers zu allen anderen; direkter Traffic, aber quadratisch wachsende Peer-Anzahl. Für dynamisches Routing (OSPF) über WireGuard empfiehlt sich Bird2 mit dem Plugin os-frr oder os-bird auf OPNsense.

Tunnel zeigt „connected", aber kein Ping zum Remote-LAN – was prüfen?

Checkliste: (1) Inbound-Firewall-Regel auf dem VPN-Interface vorhanden? (2) No-NAT-Outbound-Regel angelegt? (3) Hat die Gegenseite eine Route zum lokalen Subnetz via Tunnel? (4) wg show: Steigen die Transfer-Werte beim Ping? (5) MTU-Problem testen: ping -M do -s 1400 <Remote-IP> – schlägt das fehl, liegt ein MTU-Blackhole vor.

Wie löse ich überlappende Subnetze (beide Standorte 192.168.1.0/24)?

Langfristig: Adressräume neu planen (dringend empfohlen). Kurzfristig: 1:1-NAT – jede Seite mappt ihr internes Netz auf ein eindeutiges Proxy-Subnetz (z. B. Site A → 10.99.1.0/24, Site B → 10.99.2.0/24). Hosts sprechen die Proxy-IPs an; die Firewall übersetzt. In OPNsense: Firewall > NAT > 1:1.

Wie konfiguriere ich Failover zwischen zwei WAN-Leitungen bei WireGuard?

OPNsense Gateway-Groups nutzen (Tier 1 / Tier 2 oder Load-Balance). WireGuard selbst ist stateless – bei IP-Wechsel handshakt der Peer neu, sofern PersistentKeepalive aktiv ist. Alternativ zwei separate WireGuard-Tunnel anlegen (je WAN-IP) und per Gateway-Group umschalten. Für vollautomatisches Failover: CARP + OSPF kombinieren.

Welche Verschlüsselung ist bei IPsec IKEv2 aktuell empfohlen?

OPNsense-Dokumentation empfiehlt AES-256 + SHA-512 + DH Group 14 (2048 Bit) als sicheren Kompromiss. Für höhere Performance: AES-128-GCM (AEAD, kein separater Hash nötig) + DH Group 19 (256-Bit-ECDH). Beide Varianten erfüllen BSI TR-02102-3, die mindestens AES-128, SHA-256 und DH ≥ 2048 Bit vorschreibt.

Fazit

Für die dauerhafte Kopplung zweier OPNsense-Standorte ist WireGuard die erste Wahl: minimale Konfiguration, maximaler Durchsatz, nativ in OPNsense integriert. Sobald Fremdgeräte, Compliance-Anforderungen oder komplexe Multi-Site-Topologien mit dynamischem Routing ins Spiel kommen, führt kein Weg an IPsec IKEv2 VTI vorbei. OpenVPN scheidet für permanente Standortverbindungen aus – der Overhead ist zu hoch. In beiden Fällen gilt: No-NAT-Outbound-Regel, korrekte MTU/MSS, saubere Inbound-Firewall-Regeln auf dem VPN-Interface und – bei Hub-and-Spoke – explizite Forwarding-Regeln am Hub sind keine Optionen, sondern Pflicht. Wer diese Grundregeln einhält, erhält ein stabiles, hochperformantes Site-to-Site-VPN.

Weiterführende Anleitungen und Quellen

Offizielle Quellen: OPNsense Docs: WireGuard Site-to-Site Setup | OPNsense Docs: IPsec VTI Route-based Setup | OPNsense Docs: VPN-Protokollvergleich | Protectli: VPN Performance Results OPNsense 25.7