Site-to-Site-VPN auf OPNsense: WireGuard vs. IPsec für dauerhafte Standortkopplung

Zwei Standorte sollen dauerhaft wie ein gemeinsames Netz arbeiten: Die Filiale greift auf den Dateiserver in der Zentrale zu, das Lager auf die Warenwirtschaft. Auf OPNsense stehen dafür zwei gepflegte Wege bereit: WireGuard als schlanker Tunnel mit Schlüsselpaaren und IPsec IKEv2 über die Oberfläche VPN > IPsec > Connections. Diese Anleitung richtet beide Varianten zwischen zwei OPNsense-Firewalls ein, erklärt, wann welche Variante passt, und zeigt, wie Sie den Tunnel auf der Kommandozeile von OPNsense (FreeBSD) prüfen.

Voraussetzungen

• Zwei OPNsense-Firewalls auf x86-64 (amd64). Stand dieser Anleitung ist OPNsense 26.7 (aktuell 26.7.5 vom 30.09.2026, Basis FreeBSD 15.1). Für den vollen Funktionsumfang nennt die OPNsense-Dokumentation als sinnvolle Ausstattung eine Dual-Core-CPU ab 1 GHz, 4 GB RAM und 40 GB SSD.
• Öffentliche IPv4-Adresse an mindestens einem Standort. Hat die Gegenseite eine wechselnde Adresse oder sitzt sie hinter NAT, baut sie den Tunnel als Initiator auf.
• Adressplan ohne Überschneidung: Im Beispiel LAN Standort A 172.16.0.0/24, LAN Standort B 192.168.0.0/24, WireGuard-Transfernetz 10.2.2.0/24, IPsec-Tunneladressen 192.168.123.1 und 192.168.123.2. Die WAN-Adressen 203.0.113.1 (A) und 203.0.113.2 (B) stammen aus dem Dokumentationsbereich und sind durch Ihre echten Adressen zu ersetzen.
• Administratorzugang zur Weboberfläche beider Firewalls und SSH- oder Konsolenzugang für die Diagnose.
• Ein aktuelles Konfigurationsbackup beider Seiten (System > Configuration > Backups).

Grundlagen zur Ersteinrichtung finden Sie in pfSense / OPNsense als Firewall: Erstkonfiguration, zum Adressplan in Subnetting und CIDR verständlich erklärt.

Schritt 1: Protokoll und Adressplan festlegen

Die Wahl hängt weniger an der Geschwindigkeit als an der Gegenstelle und am Betrieb. Beide Verfahren verschlüsseln zeitgemäß, unterscheiden sich aber im Aufbau.

Kriterium	WireGuard	IPsec IKEv2 (Connections)
Gegenstelle	OPNsense, Linux, andere WireGuard-Geräte	nahezu alle Firewalls und Cloud-VPN-Gateways
Authentisierung	Schlüsselpaar je Instanz, optional Pre-Shared Key	Pre-Shared Key, Schlüsselpaar oder Zertifikat
Routing	über „Allowed IPs“, Routen setzt OPNsense selbst	richtlinienbasiert oder routenbasiert per VTI
Freizugebende Ports	ein UDP-Port, Standard 51820	UDP 500, UDP 4500 und Protokoll ESP
Parameter, die zusammenpassen müssen	Schlüssel, Allowed IPs, Endpoint	Identitäten, Proposals, Traffic-Selektoren

Für die Kopplung zweier eigener OPNsense-Systeme empfiehlt sich WireGuard, weil weniger Parameter übereinstimmen müssen. IPsec ist der Standard, wenn der Partner eine Firewall eines anderen Herstellers betreibt oder ein Cloud-Anbieter nur IPsec anbietet. Entscheidend für beide Wege: Kein LAN darf sich mit dem LAN der Gegenseite oder dem Transfernetz überschneiden, sonst findet die Firewall keine eindeutige Route. Legen Sie die Netze deshalb schriftlich fest, bevor Sie etwas konfigurieren.

Verifizieren: Prüfen Sie auf beiden Firewalls unter Interfaces > Overview die LAN-Netze. Beide Netze und das Transfernetz sind verschieden und überlappen nicht, etwa 172.16.0.0/24, 192.168.0.0/24 und 10.2.2.0/24.

Schritt 2: WireGuard-Instanzen anlegen

Öffnen Sie auf Standort A VPN > WireGuard, Reiter Instances, und legen Sie mit „+“ eine Instanz an. Schalten Sie den erweiterten Modus („advanced mode“) ein.

Feld	Standort A	Standort B
Name	wg-standort-a	wg-standort-b
Public/Private Key	über „Generate new keypair“	über „Generate new keypair“
Listen Port	51820	51820
MTU	1420 (bei PPPoE 1412)	1420 (bei PPPoE 1412)
Tunnel Address	10.2.2.1/24	10.2.2.2/24

Speichern Sie mit Save und Apply. Notieren Sie den öffentlichen Schlüssel jeder Instanz, Sie brauchen ihn im nächsten Schritt auf der jeweils anderen Seite. Der private Schlüssel verlässt die Firewall nie.

Verifizieren: Beide Instanzen erscheinen im Reiter Instances mit ausgefülltem Public Key. Auf der Konsole der Firewall zeigt wg show eine Schnittstelle (zum Beispiel wg0) mit „listening port: 51820“, sobald WireGuard in Schritt 4 aktiviert ist.

Schritt 3: Peers eintragen und zuordnen

Im Reiter Peers legen Sie auf jeder Seite die Gegenstelle an. Die Allowed IPs sind zugleich Zugriffsliste und Routingtabelle: Nur Pakete aus diesen Netzen nimmt der Tunnel an, und für genau diese Netze setzt OPNsense Routen auf die WireGuard-Schnittstelle.

Feld	auf Standort A (Peer B)	auf Standort B (Peer A)
Name	peer-standort-b	peer-standort-a
Public Key	Public Key von wg-standort-b	Public Key von wg-standort-a
Allowed IPs	10.2.2.2/32, 192.168.0.0/24	10.2.2.1/32, 172.16.0.0/24
Endpoint Address	203.0.113.2	203.0.113.1
Endpoint Port	51820	51820

Öffnen Sie danach die eigene Instanz erneut und wählen Sie im Feld Peers die eben angelegte Gegenstelle aus. Ohne diese Zuordnung bleibt der Peer wirkungslos.

Hat ein Standort eine wechselnde Adresse, lassen Sie auf der Seite mit fester Adresse die Endpoint Address leer; die dynamische Seite baut dann den Tunnel auf. Sitzt ein Standort hinter NAT, setzen Sie dort Keepalive auf 25 Sekunden, damit die NAT-Zuordnung bestehen bleibt. Verwenden Sie Hostnamen als Endpoint, löst WireGuard sie nur beim Start auf. Legen Sie dann unter System > Settings > Cron einen Job mit dem Befehl „Renew DNS for WireGuard on stale connections“ an.

Verifizieren: In der Instanz ist unter Peers genau die Gegenstelle eingetragen. Die Allowed IPs auf A enthalten das LAN von B und umgekehrt, keine Seite trägt das eigene LAN ein.

Schritt 4: Firewall, MSS und Tunnelstart

Geben Sie unter Firewall > Rules auf der Schnittstelle WAN eingehend UDP an die eigene WAN-Adresse, Port 51820, frei. Als Quelle tragen Sie die feste Adresse der Gegenseite ein; bei dynamischer Gegenstelle bleibt die Quelle auf „any“.

Damit TCP-Verbindungen nicht an zu großen Paketen scheitern, legen Sie unter Firewall > Settings > Normalization eine Regel für die Schnittstelle WireGuard (Group) an, Richtung und Protokoll „any“, Max mss 1380. Der Wert ergibt sich aus MTU 1420 minus 40 Byte für IPv4- und TCP-Header; für IPv6 ziehen Sie 60 Byte ab.

Aktivieren Sie anschließend auf beiden Seiten unter VPN > WireGuard > Settings die Option Enable WireGuard und übernehmen Sie mit Apply. Zuletzt erlauben Sie den Verkehr zwischen den Netzen:

• Standort A, Schnittstelle LAN: Quelle 172.16.0.0/24, Ziel 192.168.0.0/24, Aktion Pass.
• Standort A, Schnittstelle WireGuard (Group): Quelle 192.168.0.0/24, Ziel 172.16.0.0/24, Aktion Pass.
• Standort B spiegelbildlich.

Die Beispielregeln erlauben jeden Dienst. Im Betrieb schränken Sie das Ziel auf die tatsächlich benötigten Server und Ports ein, zum Beispiel SMB nur zum Dateiserver.

Verifizieren: Unter VPN > WireGuard > Diagnostics zeigt die Gegenstelle einen Wert bei „Handshake“ sowie steigende Zähler für Send und Received. Auf der Konsole meldet wg show eine Zeile „latest handshake“ mit wenigen Sekunden oder Minuten Alter.

Schritt 5: Alternative IPsec mit Connections und VTI

Für IPsec nutzen Sie VPN > IPsec > Connections. Die früheren Seiten „Tunnel Settings“ mit Phase 1 und Phase 2 liegen seit OPNsense 25.7 im Plugin os-strongswan-legacy; OPNsense nennt das einen ersten Schritt zur Abkündigung. Die routenbasierte Variante mit Virtual Tunnel Interface (VTI) verhält sich wie eine normale Schnittstelle, Sie routen also wie bei WireGuard.

1. VTI anlegen: VPN > IPsec > Virtual Tunnel Interfaces, Reqid 10, Local address 203.0.113.1, Remote address 203.0.113.2, Tunnel local address 192.168.123.1, Tunnel remote address 192.168.123.2. Auf B jeweils vertauscht, die Reqid bleibt 10.
2. Pre-Shared Key: VPN > IPsec > Pre-Shared Keys, Local Identifier standort-a, Remote Identifier standort-b, ein langer Zufallsschlüssel. Auf B die Identifier vertauscht.
3. Connection: VPN > IPsec > Connections, Häkchen „Enable“ setzen, neuen Eintrag mit Local addresses 203.0.113.1, Remote addresses 203.0.113.2, im erweiterten Modus Unique „Replace“. Local Authentication „Pre-Shared Key“ mit Id standort-a, Remote Authentication „Pre-Shared Key“ mit Id standort-b.
4. Child: Mode Tunnel, Reqid 10, Policies abgewählt, Local und Remote jeweils 0.0.0.0/0, Start action „Trap“. Speichern und auf der Connections-Seite Apply wählen.
5. Gateway und Route: System > Gateways > Configuration, Gateway auf Schnittstelle IPSEC10 mit Adresse 192.168.123.2 (auf B: 192.168.123.1). Unter System > Routes > Configuration das LAN der Gegenseite über dieses Gateway leiten.
6. Firewall: Connections legen keine WAN-Regeln automatisch an. Geben Sie auf WAN von der Gegenstelle ESP, UDP 500 und UDP 4500 frei. Den Verkehr im Tunnel erlauben Sie unter Firewall > Rules auf der Schnittstelle IPsec.

Die Warnung aus der OPNsense-Dokumentation ist ernst zu nehmen: Bleiben bei Local und Remote 0.0.0.0/0 die Policies aktiv, fängt der Tunnel den gesamten Verkehr ein und Sie erreichen die Firewall nicht mehr. Proposals lassen Sie auf beiden Seiten identisch; bei Fremdgeräten tragen Sie die Werte des Partners explizit ein.

Verifizieren: VPN > IPsec > Status Overview zeigt die Verbindung als verbunden mit einer installierten Child-SA. Auf der Konsole listet swanctl --list-sas die Verbindung mit Zustand „ESTABLISHED“ und das Child mit „INSTALLED“.

Schritt 6: Tunnel auf der Konsole prüfen

OPNsense basiert auf FreeBSD. Linux-Befehle wie ip route, iptables oder sysctl rp_filter gibt es dort nicht. Melden Sie sich per SSH an und wählen Sie im Konsolenmenü die Shell (Option 8).

# WireGuard: Handshake, Endpunkte und Zähler
wg show

# Welche Route nimmt ein Paket ins andere LAN?
route -n get 192.168.0.10

# Passt die Paketgröße? -D verbietet Fragmentierung (FreeBSD-ping)
ping -D -s 1392 -c 3 10.2.2.2

# Kommen Pakete im Tunnel an?
tcpdump -ni wg0 host 192.168.0.10

# IPsec: aufgebaute Security Associations
swanctl --list-sas

Bei WireGuard ergeben 1392 Byte Nutzlast plus 28 Byte ICMP- und IP-Header genau die Tunnel-MTU von 1420. Kommt diese Größe nicht durch, eine kleinere aber schon, liegt auf dem Weg eine kleinere MTU vor; senken Sie dann MTU und MSS auf beiden Seiten gleichmäßig.

Verifizieren: route -n get 192.168.0.10 nennt als „interface“ die WireGuard-Schnittstelle (bei IPsec ipsec10). Ein Ping von einem Client in A auf einen Server in B wird beantwortet, und tcpdump zeigt Anfrage und Antwort.

Typische Fehler

• Kein Handshake: WAN-Regel für UDP 51820 fehlt, Public Keys vertauscht oder die Instanz ist dem Peer nicht zugeordnet. Prüfen Sie unter Firewall > Log Files > Live View, ob die Pakete auf WAN ankommen und durchgelassen werden.
• Handshake da, aber kein Verkehr: Das LAN der Gegenseite fehlt in den Allowed IPs, oder die Regel auf WireGuard (Group) beziehungsweise IPsec fehlt.
• Ping geht, SMB oder HTTPS hängen: Klassisches MTU-Problem. MSS-Regel aus Schritt 4 anlegen und mit ping -D die tatsächliche Größe messen.
• Tunnel fällt nach Adresswechsel aus: Beide Seiten nutzen dynamische Hostnamen. Cron-Job „Renew DNS for WireGuard on stale connections“ anlegen oder eine Seite mit fester Adresse als Responder betreiben.
• IPsec: Firewall nicht mehr erreichbar: Policies im Child mit 0.0.0.0/0 aktiv. Über die Konsole IPsec deaktivieren, Policies abwählen, neu übernehmen.
• IPsec baut nicht auf: Identitäten, Pre-Shared Key oder Proposals passen nicht zusammen. Unter VPN > IPsec > Log File die Meldung beider Seiten lesen und die Werte abgleichen.
• Antworten kommen nicht zurück: Die Gegenseite hat keine Route oder nutzt eine andere Firewall als Standardgateway. Routen auf beiden Seiten mit route -n get prüfen.

Häufige Fragen

Muss ich für WireGuard ein Plugin installieren?

Nein. Seit OPNsense 24.1 ist WireGuard Bestandteil des Systems und läuft mit dem FreeBSD-Kernelmodul. Das frühere Plugin os-wireguard-go wurde eingestellt.

Kann ich die alten IPsec-Tunnel-Settings weiter nutzen?

Mit dem Plugin os-strongswan-legacy ja. Neue Tunnel richten Sie trotzdem unter Connections ein und migrieren bestehende Tunnel geplant; die OPNsense-Dokumentation zu IPsec enthält dafür den Abschnitt „Migrating from tunnels to connections“.

Welches Verfahren ist schneller?

Das hängt von CPU, Netzwerkkarten und Verkehrsmuster ab. Die OPNsense-Dokumentation weist darauf hin, dass ein einzelner IPsec-Tunnel oft nur auf einem CPU-Kern empfangen wird. Messen Sie mit iperf3 zwischen zwei Clients, statt sich auf Tabellen zu verlassen.

Was tun bei überlappenden LANs?

Am saubersten nummerieren Sie ein Netz um. Ist das nicht möglich, lässt sich bei IPsec eine Adressumsetzung vor dem Tunnel einrichten; die OPNsense-Dokumentation beschreibt das im How-to „IPsec - NAT before IPsec“.

Fazit

Für zwei eigene OPNsense-Standorte ist WireGuard mit wenigen Feldern je Seite eingerichtet und gut zu diagnostizieren. IPsec über Connections mit VTI bleibt die Wahl für gemischte Umgebungen und Cloud-Anbindungen. In beiden Fällen entscheiden ein sauberer Adressplan, die MSS-Begrenzung und eng gefasste Regeln darüber, ob die Verbindung im Alltag stabil läuft. Halten Sie die Konfiguration beider Seiten dokumentiert und sichern Sie sie nach jeder Änderung.

Weiterführende Anleitungen und Quellen

• pfSense / OPNsense als Firewall: Erstkonfiguration
• WireGuard-VPN für Homeoffice und Standortvernetzung einrichten
• Zero-Trust-Netzwerksegmentierung im KMU
• OPNsense: WireGuard Site-to-Site Setup
• OPNsense: IPsec Route based (VTI) PSK setup
• OPNsense: IPsec (Connections, Firewall-Regeln, Performance)
• OPNsense Release Notes (24.1, 25.7, 26.7)
• FreeBSD-Handbuchseite ping(8)