OPNsense - WireGuard Site-to-Site und Road Warrior
Auf einen Blick
| Gilt für | OPNsense 26.1 und 26.7 (VPN → WireGuard, im Kern enthalten) |
|---|---|
| Bereich | IT-Security |
| Dauer | ca. 20 Minuten (Site-to-Site), ca. 15 Minuten pro Road-Warrior-Client |
| Rechte | Administrator (OPNsense-WebUI) |
| Stand | Oktober 2026 (OPNsense 26.7.5) |
WireGuard auf OPNsense ist die schnellste und einfachste Möglichkeit, Standorte per Site-to-Site-Tunnel zu verbinden oder mobile Geräte als Road Warrior an das Firmennetz anzubinden. Statt Zertifikaten, Cipher-Listen und Phasen wie bei IPsec arbeitet WireGuard wie SSH mit öffentlichen und privaten Schlüsseln. In OPNsense ist WireGuard seit Version 24.1 fester Bestandteil des Kerns und nutzt die Kernel-Implementierung von FreeBSD (wg(4)).
Dieser Artikel zeigt die Einrichtung mit der aktuellen Oberfläche (Stand OPNsense 26.7): Grundbegriffe, eine Site-to-Site-Verbindung zwischen zwei OPNsense-Firewalls, ein Client-VPN mit dem Peer generator (inklusive QR-Code für Smartphones), Routing, NAT und Firewall-Regeln sowie Hochverfügbarkeit mit CARP und die Fehlersuche.
WireGuard in OPNsense: Grundbegriffe
WireGuard kennt keine Rollen „Server“ und „Client“ – alle Teilnehmer sind gleichberechtigte Peers. OPNsense bildet das in zwei Objekten ab:
| Objekt | Bedeutung | Wichtige Felder |
|---|---|---|
| Instance (lokale Seite) | Die WireGuard-Schnittstelle auf dieser Firewall (Gerät wg0, wg1 …) mit eigenem Schlüsselpaar und UDP-Port. |
Public/Private key, Listen port, Tunnel address, Peers, MTU, Disable routes, Depend on (CARP) |
| Peer (Gegenseite) | Ein entfernter Teilnehmer: eine andere Firewall, ein Notebook oder ein Smartphone. | Public key, Allowed IPs, Endpoint address/port, Pre-shared key, Keepalive interval |
Das zentrale Konzept ist Allowed IPs (Cryptokey Routing): Diese Netze werden über den Peer geroutet, und nur Pakete mit Absenderadressen aus diesen Netzen werden von ihm angenommen. Eine Instanz kann beliebig viele Peers haben; ein Peer kann mehreren Instanzen zugeordnet sein.
Die Menüpunkte unter VPN → WireGuard:
- Instances – lokale WireGuard-Schnittstellen; unter der Liste befindet sich auch der globale Schalter Enable WireGuard.
- Peers – die Gegenstellen.
- Peer generator – erzeugt Schlüssel und fertige Client-Konfiguration samt QR-Code.
- Status – Handshakes, übertragene Daten und Endpunkte je Peer.
- Log File – Meldungen des Dienstes (ausführlicher mit der Instanz-Option Debug Log).
WireGuard, IPsec oder OpenVPN?
| Kriterium | WireGuard | IPsec | OpenVPN |
|---|---|---|---|
| Einrichtung | Sehr einfach (Schlüsselpaare) | Aufwendig (Phasen, Proposals) | Mittel (PKI, Zertifikate) |
| Durchsatz | Sehr hoch (Kernel) | Sehr hoch | Gut, mit DCO sehr gut |
| Interoperabilität mit anderen Herstellern | Wachsend (MikroTik, Linux, viele Router) | Industriestandard | Begrenzt |
| Benutzer-Anmeldung / MFA | Nein, nur Schlüssel pro Gerät | Möglich (EAP/RADIUS) | Ja, integriert (LDAP, RADIUS, TOTP) |
| Roaming (WLAN ↔ Mobilfunk) | Nahtlos | Mit MOBIKE | Neuverbindung |
WireGuard ist ideal für Standortkopplungen zwischen OPNsense-Firewalls und für Geräte-VPNs. Wird für das Client-VPN eine Benutzeranmeldung mit Mehr-Faktor-Authentifizierung verlangt, ist OpenVPN die bessere Wahl – oder ein Zero-Trust-Ansatz auf WireGuard-Basis wie NetBird mit Anmeldung über den Identity Provider.
Teil 1: WireGuard Site-to-Site zwischen zwei OPNsense
Beispiel-Szenario
| Eigenschaft | Standort A (Zentrale) | Standort B (Filiale) |
|---|---|---|
| Öffentliche Adresse | 203.0.113.1 |
203.0.113.2 (oder dynamisch)
|
| LAN | 172.16.0.0/24 |
192.168.0.0/24
|
Tunneladresse (Transfernetz 10.2.2.0/24) |
10.2.2.1/24 |
10.2.2.2/24
|
| Listen port | 51820 |
51820
|
Schritt 1: Instanzen anlegen (beide Seiten)
VPN → WireGuard → Instances → + (erweiterten Modus einschalten):
| Feld | Standort A | Standort B |
|---|---|---|
| Enabled | ✔ | ✔ |
| Name | wg-site-a |
wg-site-b
|
| Public key / Private key | mit dem Zahnrad erzeugen | mit dem Zahnrad erzeugen |
| Listen port | 51820 |
51820
|
| MTU | 1420 (Standard), bei PPPoE 1412 |
wie A |
| Tunnel address | 10.2.2.1/24 |
10.2.2.2/24
|
| Peers | zunächst leer | zunächst leer |
Speichern. Den Public key jeder Instanz notieren – er wird auf der jeweils anderen Seite als Peer-Schlüssel eingetragen. Der Private key verlässt die Firewall nie.
/24), nicht als /32. Seit FreeBSD 15 (OPNsense 26.x) werden Adressen ohne Netzmaske ohnehin nicht mehr akzeptiert.Schritt 2: Peers anlegen (beide Seiten)
VPN → WireGuard → Peers → +:
| Feld | Auf Standort A (Peer = B) | Auf Standort B (Peer = A) |
|---|---|---|
| Name | wg-site-b |
wg-site-a
|
| Public key | Public key der Instanz von B | Public key der Instanz von A |
| Pre-shared key | optional, auf beiden Seiten identisch (erzeugen mit wg genpsk bzw. Generator) | identisch |
| Allowed IPs | 10.2.2.2/32, 192.168.0.0/24 |
10.2.2.1/32, 172.16.0.0/24
|
| Endpoint address / port | 203.0.113.2 / 51820 |
203.0.113.1 / 51820
|
| Instances | wg-site-a |
wg-site-b
|
| Keepalive interval | leer | 25, falls B hinter NAT liegt
|
Anschließend die Instanz erneut öffnen und prüfen, dass der Peer unter Peers ausgewählt ist. Der Pre-shared key ist optional, ergänzt das Schlüsselverfahren aber um eine symmetrische Komponente und gilt als Schutz gegen künftige Angriffe mit Quantencomputern („harvest now, decrypt later“).
Dynamische IP-Adresse: Hat ein Standort keine feste Adresse, bleibt auf der Gegenseite (mit fester IP) das Feld Endpoint address leer. Die Seite mit dynamischer IP baut die Verbindung dann immer auf; die WAN-Regel der festen Seite muss jede Quelladresse zulassen.
Schritt 3: WireGuard aktivieren
Unter VPN → WireGuard → Instances unterhalb der Liste Enable WireGuard anhaken und Apply klicken. Unter VPN → WireGuard → Status sollte nach dem ersten Datenverkehr ein aktueller Handshake sowie gesendete und empfangene Daten erscheinen.
Schritt 4: Firewall-Regeln und MSS-Clamping
Seit OPNsense 26.7 werden Regeln unter Firewall → Rules mit Auswahl der Schnittstelle gepflegt:
- WAN (beide Seiten): Pass, Protokoll UDP, Quelle = öffentliche IP der Gegenseite (bei dynamischer Gegenseite any), Ziel WAN address, Port
51820. - LAN (ausgehend): Verkehr vom eigenen LAN zum entfernten LAN erlauben – entfällt, wenn auf dem LAN ohnehin eine LAN to any-Regel besteht.
- Interface-Gruppe WireGuard (eingehend aus dem Tunnel): z. B. auf A Quelle
192.168.0.0/24→ Ziel172.16.0.0/24, auf B umgekehrt. Hier lässt sich fein steuern, welche Dienste die Filiale erreichen darf.
Gegen fragmentierte TCP-Verbindungen (Symptom: Ping funktioniert, HTTPS oder SMB hängen) unter Firewall → Settings → Normalization auf beiden Seiten eine Regel für die Interface-Gruppe WireGuard mit Max mss 1380 anlegen (WireGuard-MTU minus 40 Byte; für IPv6-TCP minus 60 Byte).
Weitere Netze und IPv6
Zusätzliche Netze werden einfach in den Allowed IPs des Peers ergänzt und in den Regeln freigegeben – OPNsense setzt die Routen automatisch. Für einen Dual-Stack-Tunnel werden IPv6-Netze (ULA oder GUA, meist /64) auf dieselbe Weise ergänzt.
Teil 2: Road Warrior (Client-VPN)
Schritt 1: Instanz für Clients
Für mobile Clients empfiehlt sich eine eigene Instanz mit eigenem Tunnelnetz, z. B. Name wg-clients, Listen port 51821, Tunnel address 10.10.10.1/24. Das Feld DNS servers der Instanz (erweiterter Modus) bleibt leer – es würde sonst die DNS-Konfiguration der Firewall selbst überschreiben.
Für den Peer generator zusätzlich in der Instanz hinterlegen:
- Endpoint: öffentliche Adresse bzw. DNS-Name der Firewall, z. B.
vpn.example.com:51821 - DNS Servers: DNS-Server für die Clients, z. B.
10.10.10.1(Unbound auf der Firewall) - Allowed IPs: die Netze, die die Clients über den Tunnel erreichen sollen, z. B.
172.16.0.0/24(Split Tunnel) oder0.0.0.0/0, ::/0(Full Tunnel)
Schritt 2: Clients mit dem Peer generator anlegen
VPN → WireGuard → Peer generator:
- Instance wählen – Endpoint, DNS und Allowed IPs werden aus der Instanz übernommen.
- Name vergeben (z. B. nb-mueller); Schlüsselpaar und nächste freie Address (z. B.
10.10.10.2/32) werden vorgeschlagen. - Optional Pre-shared key und Keepalive interval (
25für Mobilgeräte hinter NAT) setzen. - Optional Store private key on this firewall aktivieren: Dann kann die Konfiguration später erneut angezeigt werden. Aus Sicherheitsgründen ist es besser, den Schlüssel nicht zu speichern und die Konfiguration direkt zu übergeben.
- Die angezeigte Config kopieren bzw. den QR code mit der WireGuard-App auf dem Smartphone scannen.
- Den Peer speichern – er wird angelegt und der Instanz automatisch zugeordnet.
Anschließend Apply auf der Seite Instances bzw. Peers nicht vergessen. Wurde der private Schlüssel gespeichert, lässt sich ein bestehender Peer in der Liste Peers über Open in peer generator erneut als Konfiguration bzw. QR-Code anzeigen (seit 26.7.3 mit übersichtlicheren QR-Codes).
Manuell angelegte Client-Peers erhalten als Allowed IPs nur ihre eigene Tunneladresse (/32 bzw. /128) – niemals das gesamte Tunnelnetz, sonst würde nur ein Client funktionieren.
Schritt 3: Schnittstelle zuweisen (empfohlen)
Unter Interfaces → Assignments das Gerät der Instanz (z. B. wg1) zuweisen, aktivieren, Lock setzen und IPv4/IPv6-Konfiguration auf None lassen – die Tunneladresse setzt WireGuard selbst. Danach WireGuard über Enable WireGuard bzw. Apply neu starten. Vorteile:
- ein automatischer Alias (z. B. WG_CLIENTS net) für Firewall-Regeln,
- bei Full Tunnel automatisch eine passende Source-NAT-Regel im Modus Automatic oder Hybrid,
- eigene Regeln pro Instanz statt nur in der Gruppe WireGuard,
- Unbound DNS beantwortet nach einem Neustart auch Anfragen aus dem Tunnel.
Schritt 4: Regeln und NAT
- WAN: Pass, UDP, Quelle any, Ziel WAN address, Port
51821. - Interface der Instanz (oder Gruppe WireGuard): erlaubte Ziele für die Clients, z. B. WG_CLIENTS net →
172.16.0.0/24, DNS auf die Firewall. Für Full Tunnel zusätzlich Internetzugriff freigeben. - Ohne zugewiesene Schnittstelle bei Full Tunnel unter Firewall → NAT → Source NAT manuell eine Regel anlegen: Interface WAN, Quelle
10.10.10.0/24, Übersetzung Interface address.
Clients
WireGuard-Apps gibt es für Windows, macOS, Linux, iOS und Android. Auf dem Client entspricht die Konfiguration dem Format:
[Interface] PrivateKey = <privater Schlüssel des Clients> Address = 10.10.10.2/32 DNS = 10.10.10.1 [Peer] PublicKey = <Public key der OPNsense-Instanz> PresharedKey = <optional> Endpoint = vpn.example.com:51821 AllowedIPs = 172.16.0.0/24 PersistentKeepalive = 25
Unter iOS und macOS kann die WireGuard-App die Verbindung per On-Demand automatisch außerhalb des Firmen-WLANs aufbauen. Für zentrale Verteilung der Konfiguration in größeren Umgebungen sind Lösungen wie NetBird oder Tailscale komfortabler.
Teil 3: Routing, Gateways und Hochverfügbarkeit
Disable routes und Gateway (Policy-based Routing)
Standardmäßig legt OPNsense für alle Allowed IPs Routen an. Bei einem Peer mit 0.0.0.0/0 – etwa bei einem kommerziellen VPN-Anbieter oder einem Breakout über ein anderes Rechenzentrum – würde das die Standardroute der Firewall übernehmen. Dafür gibt es in der Instanz:
- Disable routes: keine automatischen Routen installieren.
- Gateway (erweiterter Modus): eine IP für das Tunnel-Gateway, die anschließend unter System → Gateways → Configuration als Gateway auf der zugewiesenen WireGuard-Schnittstelle angelegt wird (Option Far Gateway).
Mit Firewall-Regeln, die dieses Gateway verwenden, wird dann nur ausgewählter Verkehr (z. B. bestimmte Hosts oder VLANs) durch den Tunnel geleitet. Mit Gateway-Überwachung und Gateway-Gruppen lassen sich so auch redundante Tunnel oder ein Failover zwischen zwei WireGuard-Verbindungen umsetzen. Die OPNsense-Dokumentation beschreibt das Vorgehen ausführlich als Selective Routing.
Dynamisches Routing
Mit zugewiesenen Schnittstellen und Disable routes lässt sich über WireGuard auch OSPF oder BGP (Plugin os-frr) betreiben. Die Allowed IPs müssen dann alle Netze umfassen, die dynamisch gelernt werden können (im Zweifel 0.0.0.0/0 bei einem Peer pro Instanz).
Hochverfügbarkeit mit CARP
In einem HA-Cluster wird die WireGuard-Konfiguration per System → High Availability synchronisiert. In jeder Instanz Depend on (CARP) auf die VHID der WAN-CARP-Adresse setzen: Die Instanz läuft dann nur auf dem jeweiligen Master und wird auf dem Backup heruntergefahren. Die Gegenstellen verwenden als Endpoint die CARP-Adresse.
Sicherheitsempfehlungen
- Ein Schlüsselpaar pro Gerät – keine Client-Konfiguration mehrfach verwenden; verlorene Geräte durch Deaktivieren bzw. Löschen des Peers sperren.
- Pre-shared key für jeden Peer setzen.
- Allowed IPs so eng wie möglich und den Zugriff zusätzlich per Firewall-Regel auf benötigte Ziele und Dienste begrenzen.
- Private Schlüssel von Clients nicht auf der Firewall speichern und Konfigurationen nur über sichere Kanäle übergeben.
- Da WireGuard keine Benutzeranmeldung kennt, für Benutzerzugänge mit MFA-Pflicht OpenVPN mit TOTP/RADIUS oder eine Zero-Trust-Lösung einsetzen.
- Firewall auf aktuellem Stand halten (mindestens 26.7.2 wegen FREEBSD-SA:26:52.if_wg).
- Neue Handshakes und Verbindungsfehler über das Log an ein SIEM übertragen, z. B. mit dem Wazuh-Agent in ein Open-Source-SIEM auf Wazuh-Basis.
Typische Probleme und Lösungen
| Symptom | Ursache und Lösung |
|---|---|
| Kein Handshake im Status | WAN-Regel für den UDP-Port fehlt, falscher Port oder Endpoint, vertauschte Public keys, Enable WireGuard nicht aktiv. |
| Handshake ja, aber kein Verkehr | Allowed IPs unvollständig (Tunneladresse oder LAN der Gegenseite fehlt) oder Regel auf der Gruppe WireGuard fehlt. |
| Nur ein Road-Warrior-Client funktioniert | Client-Peers haben das gesamte Tunnelnetz statt einer /32-Adresse als Allowed IPs. |
| Ping geht, HTTPS/SMB hängen | MTU/MSS: Normalization-Regel mit Max mss 1380 anlegen, bei PPPoE MTU 1412. |
| Tunnel fällt nach IP-Wechsel aus | Endpoint-Hostname nur einmal aufgelöst: Cron-Job Renew DNS for WireGuard on stale connections anlegen; Keepalive auf der Seite hinter NAT setzen. |
| Firewall verliert nach Aktivieren das Internet | Peer mit 0.0.0.0/0 übernimmt die Standardroute: Disable routes + Gateway verwenden.
|
| DNS der Firewall verändert | DNS servers in der Instanz gesetzt – Feld leeren, DNS für Clients nur im Peer generator angeben. |
| Clients können keine Namen auflösen | Unbound nach dem Zuweisen der Schnittstelle neu starten und DNS-Regel auf der WireGuard-Schnittstelle freigeben. |
| HA: Tunnel auf beiden Knoten aktiv | Depend on (CARP) in der Instanz setzen. |
Zur Diagnose auf der Konsole: wg show zeigt Peers, Endpunkte, letzte Handshakes und Datenvolumen; ausführlichere Meldungen liefert die Instanz-Option Debug Log unter VPN → WireGuard → Log File.
Fazit
WireGuard ist auf OPNsense 2026 die schnellste Art, ein VPN aufzubauen: Zwei Schlüsselpaare, ein UDP-Port und passende Allowed IPs genügen für eine Standortkopplung, und der Peer generator macht das Anbinden von Notebooks und Smartphones per QR-Code zur Sache von Minuten. Mit Disable routes, Gateways und CARP deckt WireGuard auch anspruchsvolle Szenarien wie Policy-based Routing, Failover und Hochverfügbarkeit ab. Wo eine Benutzeranmeldung mit MFA gefordert ist, ergänzen OpenVPN oder eine Zero-Trust-Lösung das Konzept.
Unterstützung von m.a.x. it
Sie möchten Standorte per WireGuard vernetzen, ein Client-VPN aufbauen oder bestehende IPsec- und OpenVPN-Tunnel modernisieren? 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
- OPNsense - Hochverfügbarkeit mit CARP und pfsync
- OPNsense - FRR Dynamisches Routing
- OPNsense - BGP mit FRR
- OPNsense - Unbound DNS Resolver
- WireGuard
- VPN Techniken für das Homeoffice
- OPNsense - IPsec Site-to-Site route-based
- OPNsense - OpenVPN Site-to-Site und Client-VPN
- OPNsense - NetBird-Plugin
- NetBird – Zero-Trust-Netzwerk mit WireGuard
- Tailscale – Mesh-VPN auf WireGuard-Basis
- OPNsense - Tinc Mesh-VPN
Links und Quellen
- OPNsense-Doku – Virtual Private Networking (WireGuard)
- OPNsense-Doku – WireGuard Site-to-Site Setup
- OPNsense-Doku – WireGuard Road Warrior Setup
- OPNsense-Doku – WireGuard Selective Routing
- WireGuard – offizielle Website
- m.a.x. it – OPNsense-Firewall-Services
Ü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?
