WireGuard Site-to-Site VPN in 30 Minuten

WireGuard hat sich in den letzten Jahren als Standard für Site-to-Site-VPNs im Mittelstand etabliert. Die Performance ist sehr gut (Kernel-Modul, oft 800 Mbit+ über typische ISP-Links), die Konfiguration ist überschaubar, und auf OPNsense ist die Integration ausgereift. Dieser Artikel ist ein konkretes Tutorial: zwei Standorte per WireGuard verbinden, in 30 Minuten, mit Erklärungen zu den typischen Stolpersteinen.

Wer noch grundsätzlich überlegt, ob WireGuard oder OpenVPN: wir haben dazu einen Vergleichsartikel mit Performance-Daten. Für Site-to-Site-Setups ist WireGuard inzwischen klar die erste Wahl.

Das Szenario

• Standort A — Hauptbüro: OPNsense-Firewall, statische öffentliche IPv4, LAN 192.168.10.0/24
• Standort B — Filiale: OPNsense-Firewall, dynamische öffentliche IPv4 (DSL), LAN 192.168.20.0/24
• Ziel: Beide LANs sehen sich gegenseitig, Routing in beide Richtungen, Tunnel baut auch nach Reconnect der Filiale automatisch wieder auf.

Voraussetzungen

• OPNsense ≥ 23.7 auf beiden Standorten — die aktuelle WireGuard-Implementierung ist ein integriertes Plugin (os-wireguard)
• Auf Standort A: statische öffentliche IP oder zumindest sehr stabiler DynDNS-Eintrag
• Beide Standorte können ausgehende UDP-Verbindungen aufbauen (Standard, fast überall der Fall)
• Optional: DynDNS auf Standort A für robustere Konfiguration

Schritt 1 — WireGuard-Plugin installieren (falls noch nicht da)

In OPNsense unter System → Firmware → Plugins:

• os-wireguard installieren (auf beiden Standorten)

Nach der Installation taucht WireGuard unter VPN → WireGuard auf.

Schritt 2 — Schlüsselpaare erzeugen

WireGuard arbeitet mit asymmetrischen Schlüsseln: jeder Peer hat einen privaten und einen öffentlichen Schlüssel. Pro Standort wird ein Schlüsselpaar erzeugt.

In OPNsense unter VPN → WireGuard → Local:

• “Add” — neue Instanz für Standort A:
  • Name: wg_site_to_site
  • Listen Port: 51820 (Standard)
  • Public Key / Private Key: per Button “Gen” erzeugen lassen
  • Tunnel Address: 10.10.0.1/24 (privates Transit-Netz, nicht dein LAN)

Auf Standort B dasselbe — aber Tunnel Address: 10.10.0.2/24. Der Public Key beider Instanzen wird gleich gebraucht.

Stolperstein: Das Tunnel-Netz (10.10.0.0/24) ist nicht das LAN — es ist ein eigenes Transit-Netz nur für die Tunnel-Endpunkte. Wir empfehlen ein /30-Subnetz oder ein /24, das nirgendwo sonst auftaucht.

Schritt 3 — Peers konfigurieren

Jeder Standort braucht den anderen als “Peer” eingetragen. Unter VPN → WireGuard → Endpoints:

Auf Standort A: Peer für Standort B

• Name: peer_site_b
• Public Key: Public Key der Instanz auf Standort B
• Allowed IPs: 10.10.0.2/32, 192.168.20.0/24
• Endpoint Address: Public IP oder DynDNS-Name von Standort B
• Endpoint Port: 51820
• Keepalive: 25 (Sekunden)

Auf Standort B: Peer für Standort A

• Name: peer_site_a
• Public Key: Public Key der Instanz auf Standort A
• Allowed IPs: 10.10.0.1/32, 192.168.10.0/24
• Endpoint Address: Public IP oder DynDNS-Name von Standort A
• Endpoint Port: 51820
• Keepalive: 25

Allowed-IPs — der häufigste Fallstrick. Allowed-IPs hat in WireGuard eine doppelte Bedeutung:

1. Routing: “Welche Ziel-IPs gehen über diesen Tunnel?”
2. Filter: “Welche Source-IPs akzeptieren wir auf diesem Tunnel?”

Wenn Standort A unter Allowed-IPs für Standort B 192.168.20.0/24 einträgt, heißt das: “Pakete an 192.168.20.x werden über diesen Peer geroutet UND nur Pakete von 192.168.20.x (plus Tunnel-IP 10.10.0.2) werden akzeptiert.”

Symmetrie ist Pflicht. Wer auf einer Seite das LAN-Netz vergisst, hat Pakete, die zwar rausgehen, aber nicht reinkommen. Beim Debugging immer beide Allowed-IPs-Listen vergleichen.

Persistent Keepalive 25 Sekunden ist die Empfehlung für NAT-Traversal. WireGuard ist als UDP-Protokoll standardmäßig “stateless” — wenn 5 Minuten kein Paket fließt, vergessen Stateful-NATs (typisch bei ISP-DSL-Routern) den State und der Tunnel “stirbt” stillschweigend. Mit 25-Sekunden-Keepalive bleibt der State warm.

Schritt 4 — Tunnel aktivieren

In der WireGuard-Instanz unter Local:

• “Enabled” anhaken
• Unter “Peers” den eben erstellten Endpoint zuweisen

Nach Speichern und “Apply” sollte unter VPN → WireGuard → Status der Peer auftauchen, mit “Latest Handshake” zeitnah (< 30 Sekunden).

Schritt 5 — Firewall-Regeln

Standard-OPNsense blockiert allen Traffic auf dem WireGuard-Interface, bis Regeln existieren. Unter Firewall → Rules → WireGuard (oder dem WireGuard-Interface) braucht es mindestens:

• From Source: alle, To Destination: LAN-Net Standort A — wenn Filiale auf Hauptbüro zugreifen soll
• Auf der anderen Seite analog

Für den Anfang reicht eine “any to any”-Regel auf dem WG-Interface. Sobald das Setup läuft, kann das auf bestimmte Subnetze oder Ports eingeschränkt werden — z.B. nur Hauptbüro-LAN zu Filiale-Fileserver.

Zusätzlich: WAN-Regel für eingehenden WG-Traffic. Auf Standort A unter Firewall → Rules → WAN:

• Protocol: UDP
• Destination Port: 51820
• Source: any (oder eingeschränkt auf Standort-B-Public-IP, wenn statisch)
• Action: Allow

Das ist die Regel, die den eingehenden UDP-Tunnel auf Port 51820 durchlässt.

Schritt 6 — Routing

Mit Allowed-IPs sauber gesetzt routet WireGuard automatisch. Wichtig: Allowed-IPs schreiben automatisch eine Route ins Routing-System. Du musst keine zusätzliche statische Route eintragen.

Wer trotzdem manuell prüfen will, kann auf der OPNsense-CLI:

netstat -rn | grep 10.10
netstat -rn | grep 192.168.20

Beide sollten Routen über das WireGuard-Interface zeigen.

Schritt 7 — Test

Ping vom Standort-A-LAN (192.168.10.x) zu Standort-B-LAN (192.168.20.1 = OPNsense-Filiale):

ping 192.168.20.1

Wenn das geht: SMB-Share auf einem Filiale-Server prüfen:

smbclient -L //192.168.20.10 -U benutzer

Wenn auch das funktioniert — Tunnel läuft, Routing greift, Firewall lässt durch. Fertig.

Häufige Fehlerquellen

1. Latest Handshake bleibt leer

• Endpoint-Adresse oder Port falsch
• WAN-Firewall blockiert eingehenden UDP 51820
• ISP-NAT-Carrier-Grade blockiert (selten bei normalem KMU-Anschluss; kommt bei ISP-LTE vor)

2. Handshake da, aber Pings gehen nicht durch

• Allowed-IPs auf einer Seite falsch (LAN-Subnetz fehlt)
• Firewall-Regel auf WG-Interface blockiert

3. Tunnel stirbt nach einigen Minuten

• Keepalive nicht gesetzt
• ISP-NAT-Timeout aggressiv (selten)

4. Routing über Tunnel nur einseitig

• Allowed-IPs nicht symmetrisch konfiguriert
• Asymmetric Routing in der OPNsense (anderes Default-Gateway zieht den Rückweg woandershin)

5. Performance enttäuschend

• MTU-Problem: WireGuard reduziert die effektive MTU. Default 1420 ist meistens richtig. Bei seltsamen Performance-Mustern (große Pakete brechen) MTU testweise auf 1380 oder 1400 absenken.

Persistent-Keepalive — was das wirklich tut

Wir haben Keepalive 25 Sekunden empfohlen. Hintergrund: WireGuard-Pakete sind UDP. NAT-Geräte (auch eure eigene OPNsense, wenn sie hinter NAT sitzt) bauen für jede UDP-Verbindung eine NAT-Mapping auf, die nach Inaktivität verfällt — typisch 30 Sekunden bis wenige Minuten.

Mit Keepalive 25 schickt der Peer alle 25 Sekunden ein leeres Handshake-Paket. Damit bleibt der NAT-State warm, und der Tunnel reagiert sofort, wenn echte Pakete fließen.

Wer braucht das nicht? Wer mit statischer Public-IP auf beiden Seiten arbeitet und keine NAT dazwischen hat. Aber: zu setzen schadet nicht, kostet nur ein paar Pakete pro Minute.

Latenz und Durchsatz — qualitativ

WireGuard nutzt ein Kernel-Modul mit ChaCha20-Poly1305-Verschlüsselung — auf modernen CPUs deutlich performanter als OpenVPNs userspace-AES. In typischen KMU-Setups (Standort-Glasfaser-Standort) erreicht WireGuard regelmäßig 80-90% der zugrunde liegenden Link-Bandbreite. Quantitative Aussagen sparen wir hier — der Benchmark-Artikel hat reproduzierbare Zahlen.

Für Site-to-Site mit Glasfaser-Anbindungen jenseits 200 Mbit ist WireGuard fast immer die richtige Wahl. Für reine RDP- oder VoIP-Verbindungen ist auch klassisches IPsec oder OpenVPN ausreichend — bei neuen Setups würden wir trotzdem WireGuard wählen.

OpenVPN-Vergleich kurz

Wer von OpenVPN-Site-to-Site umsteigt: WireGuard ist konzeptionell anders. Es gibt keine “Server”- und “Client”-Rollen, sondern nur Peers. Es gibt keine separate TLS-Initiierung, sondern Schlüssel-basierte Authentifizierung. Es gibt keine Konfigurationsdatei pro Verbindung, sondern Peer-Listen.

Vorteile WireGuard: schneller, einfacher, weniger State zum Pflegen. Nachteile: kein Username/Passwort-Login (für Road-Warrior-VPNs braucht es ergänzende Tools), kein Push-Konfig-Mechanismus.

Für Site-to-Site sind die Nachteile irrelevant — die Schlüssel werden einmal ausgetauscht und gut.

Site-to-Site-Skalierung

Für drei oder mehr Standorte gibt es zwei Topologien:

• Hub-and-Spoke: zentrale OPNsense (z.B. Hauptbüro) als Hub, alle Filialen als Spokes. Einfach zu warten, aber Hub als Single-Point-of-Failure.
• Full Mesh: jede Filiale hat eine Tunnel-Verbindung zu jeder anderen. Robuster, aber Konfigurations-Aufwand wächst quadratisch.

Für vier oder mehr Standorte mit hohem Resilience-Bedarf lohnt sich ein Mesh-VPN-Tool wie NetBird oder Tailscale — die kapseln die Mesh-Verwaltung in einer Steuerebene.

DATAZONE-Empfehlung

WireGuard Site-to-Site ist heute Standard-Repertoire. Wir richten das pro Standort in unter 30 Minuten ein — vorausgesetzt, die WAN-Anschlüsse und die OPNsense-Installationen sind sauber.

Wer mehrere Standorte koordinieren muss, kommt mit dem Konfigurations-Modell aus diesem Artikel weit. Sobald es über vier Standorte hinausgeht oder Road-Warrior-Zugänge dazu kommen, lohnt sich der Blick auf ein Overlay-Mesh.

Quellen und weiterführende Artikel

• OPNsense Documentation — WireGuard — offizielle Dokumentation
• WireGuard vs. OpenVPN 2026 Benchmark — Performance-Vergleich
• OPNsense WireGuard VPN einrichten — Road-Warrior-Setup
• OPNsense Multi-WAN Failover — Multi-WAN-Hintergrund
• NetBird vs. Tailscale Mesh VPN — Mesh-Alternativen
• OPNsense VLAN Routing Best Practices — interne Segmentierung

Wer das Setup geführt einrichten will: gerne Termin vereinbaren — wir machen das auch remote.