Pattarin - stock.adobe.com
Site-to-Site-VPN mit WireGuard und OPNsense einrichten
Ein Site-to-Site-VPN mit WireGuard und OPNsense verbindet zwei Standorte leistungsfähig und dauerhaft, ohne komplexe IPsec-Policy-Strukturen oder überladene Konfigurationen.
Die sichere und leistungsfähige Vernetzung von Unternehmensstandorten ist heute eine der zentralen Aufgaben moderner IT-Infrastrukturen. Mit WireGuard in Kombination mit OPNsense lässt sich eine schlanke, wartungsarme und zugleich hoch effiziente Site-to-Site-Verbindung auf Layer 3 realisieren.
Der folgende Beitrag zeigt praxisnah, wie sich zwei Netzwerke strukturiert koppeln lassen – von der sauberen Adressplanung über die technische Einrichtung bis hin zu Routing, Firewall-Regeln und Betrieb. Dabei steht ein klarer, reproduzierbarer Ansatz im Fokus, der typische Fehlerquellen vermeidet und eine stabile Kommunikation zwischen den Standorten sicherstellt.
Grundlagen der Standortvernetzung mit WireGuard
Eine Standortvernetzung auf Layer 3 zielt auf direkte Kommunikation zwischen zwei IP-Netzen ohne Client-seitige Einwahl. Die Firewalls an beiden Standorten terminieren den Tunnel und entscheiden anhand ihrer Routingtabellen, ob Verkehr lokal bleibt oder über das WireGuard-Interface an den entfernten Standort fließt. Clients verwenden weiterhin ihr lokales Default-Gateway. Für sie ändert sich weder IP-Konfiguration noch Zugriffsmuster.
Die Planung beginnt mit einer eindeutigen Netzstruktur. Standort A nutzt im folgenden Szenario 192.168.0.0/24. Standort B arbeitet mit 192.168.100.0/24. Beide Netze dürfen sich nicht überschneiden. Eine Überlappung verhindert eindeutige Routenentscheidungen und führt zu inkonsistentem Verhalten auf Layer 3.
Zusätzlich definiert die Architektur ein eigenes Transfernetz für den Tunnel. Hier dient 10.0.10.0/24 als isolierter Adressraum für die WireGuard-Endpunkte. Standort B erhält 10.0.10.1/24, Standort A 10.0.10.2/24. Dieses Netz dient ausschließlich der Tunneladressierung und taucht in keinem DHCP-Pool oder Client-VLAN auf.
Mindestens eine Seite benötigt eine öffentliche IPv4-Adresse oder einen FQDN (Fully Qualified Domain Name) mit externer Auflösung. Nur dort erlaubt die Konfiguration eingehenden UDP-Verkehr auf dem gewählten Port. Befindet sich die Gegenstelle hinter CGNAT (Carrier-Grade NAT) oder einer reinen IPv6-Anbindung, baut sie die Verbindung aktiv auf. Nach erfolgreichem Handshake transportiert der Tunnel Verkehr in beide Richtungen, sofern die Filterregeln und Routen korrekt gesetzt sind.
Aktivierung und Instanzkonfiguration in OPNsense
Die Einrichtung beginnt in der Weboberfläche über VPN und anschließend WireGuard und Instances. Auf der Registerkarte General aktiviert man Enabled und übernimmt die Einstellung mit Apply. Danach steht die Instanzverwaltung bereit.
Über + erstellt man eine neue Instanz. In Name wird eine eindeutige Bezeichnung eingetragen, zum Beispiel wg-site-b oder WireGuard2. Das Schlüsselpaar erzeugt man über das Zahnradsymbol. Der private Schlüssel verbleibt ausschließlich auf dieser Firewall. Der öffentliche Schlüssel fließt in die Konfiguration der Gegenstelle ein.
In Listen Port definiert man einen festen UDP-Port, hier 51821. Dieser Port muss später in der WAN-Regel sowie im Peer identisch erscheinen. In Tunnel Address wird die lokale Adresse aus dem Transfernetz eingetragen, zum Beispiel 10.0.10.1/24. Es sind aber auch andere Netze möglich. Nach Save und Apply legt OPNsense das WireGuard-Interface an und lauscht auf dem konfigurierten Port.
Peer-Definition und Routingwirkung von Allowed IPs
Innerhalb desselben Menüs wechselt man zur Registerkarte Peers und erstellt über + einen neuen Peer. In Name wird eine sprechende Kennung für die Gegenstelle eingetragen. Public key enthält den öffentlichen Schlüssel des entfernten Systems. Optional ergänzt Pre-shared key die zusätzliche Absicherung. Die Einrichtung erfolgt an dieser Stelle genauso, wie die Einrichtung von VPN-Clients, zum Beispiel PCs, Smartphones oder Tablets.
Die zentrale Konfiguration befindet sich in Allowed IPs. Dort trägt man das entfernte LAN ein, im Beispiel 192.168.0.0/24. Dieser Eintrag erfüllt zwei Funktionen. Er definiert zulässige Zielnetze für diesen Peer und erzeugt gleichzeitig die interne Route über das WireGuard-Interface. Fehlt das entfernte Netz in dieser Liste, steht der Tunnel zwar, das Ziel bleibt jedoch unerreichbar.
Endpoint address enthält die öffentliche IPv4-Adresse oder den FQDN der Gegenstelle. Endpoint port übernimmt den zuvor definierten UDP-Port. Über Instances verknüpft man den Peer mit der lokalen Instanz. Keepalive interval erhält den Wert 25, damit NAT-Tabellen in Routern nicht ablaufen. Nach Save und Apply ist die Tunneldefinition vollständig im System hinterlegt.
Paketfilterregeln für bidirektionalen Verkehr
Ein funktionierender Tunnel allein garantiert keinen Datentransfer zwischen den LANs. Der Paketfilter entscheidet weiterhin über jede Verbindung.
Für Verkehr aus dem lokalen Netz in das entfernte Netz öffnet man Firewall und anschließend Rules und wählt das Interface LAN. Über + legt man eine Regel an. Als Quelle dient 192.168.100.0/24, als Ziel 192.168.0.0/24. Nach dem Speichern übernimmt Apply changes die Regel in die aktive Konfiguration.
Für den umgekehrten Weg wechselt man zu Firewall und Rules und WireGuard (Group). Dort definiert man eine Regel mit Quelle 192.168.0.0/24 und Ziel 192.168.100.0/24. Erst mit dieser Definition darf Verkehr aus dem Tunnel in das lokale LAN gelangen.
Soll diese OPNsense eingehende Tunnelverbindungen akzeptieren, ergänzt man auf dem Interface WAN eine Regel. In Protocol wählt man UDP. Als Ziel wählt man WAN address. In Destination port range trägt man den Listen-Port 51821 ein.
Anpassung der MTU und MSS-Clamping
WireGuard kapselt IP-Pakete in UDP-Frames. Dadurch reduziert sich die nutzbare MTU. Ohne Anpassung fragmentieren größere TCP-Segmente, was sich als Verbindungsabbrüche bei bestimmten Anwendungen äußert.
Über Firewall und Settings und Normalization legt man eine neue Regel für das Interface WireGuard (Group) an. In Max mss trägt man 1380 ein. Dieser Wert reduziert die maximale TCP-Segmentgröße und verhindert Fragmentierung im Tunnel.
Integration in bestehende Routingstrukturen
Befindet sich die OPNsense-Firewall nicht als Default-Gateway im jeweiligen LAN, muss ein vorgelagerter Router das entfernte Netz kennen. Dort legt man eine statische Route mit Ziel 192.168.0.0/24 an. Als Gateway ist dann die interne IP-Adresse der OPNsense einzutragen. Fehlt dieser Eintrag, gelangen Pakete zwar an die Firewall, kehren jedoch nicht korrekt ins entfernte Netz zurück.
In komplexeren Umgebungen mit mehreren VLANs erweitert man Allowed IPs um zusätzliche Netze und ergänzt entsprechende Firewall-Regeln. Jede Erweiterung erfordert eine eindeutige Route und eine passende Filterdefinition.
WireGuard-Instanz auf dem Remote-Standort
Auf der zweiten Firewall erfolgt zunächst dieselbe Grundkonfiguration. In der Oberfläche geht man zu VPN und WireGuard und Instances. Dort aktiviert man Enable WireGuard und bestätigt mit Apply.
Über + legt man eine neue Instanz an. In Name steht eine eindeutige Kennung, zum Beispiel wg-site-a. In Listen Port trägt man denselben UDP-Port ein, der auf der ersten Seite verwendet wird, zum Beispiel 51821, sofern diese Firewall ebenfalls eingehende Verbindungen akzeptieren soll. Baut diese Seite den Tunnel aktiv auf und nimmt keine eingehenden Verbindungen an, kann der Port leer bleiben oder identisch gesetzt werden.
In Tunnel Address trägt man die zweite Adresse aus dem Transfernetz ein, im Beispiel 10.0.10.2/24. Danach speichert man mit Save und übernimmt die Konfiguration mit Apply. Das Schlüsselpaar erzeugt man über das Zahnradsymbol. Den öffentlichen Schlüssel benötigt die erste Firewall für ihre Peer-Definition.
Peer-Definition der Gegenstelle
Anschließend wechselt man zur Registerkarte Peers und erstellt über + einen neuen Eintrag. In Public key" ist der öffentliche Schlüssel der ersten Firewall einzutragen. In Allowed IPs steht das entfernte LAN, im Beispiel 192.168.100.0/24, sofern sich dieses Netz auf der ersten Seite befindet. Damit erzeugt das System die Route über das WireGuard-Interface in Richtung dieses Netzes.
In Endpoint address wird die öffentliche IPv4-Adresse oder der FQDN der ersten Firewall eingetragen, sofern diese Seite als erreichbarer Endpunkt dient. In Endpoint port steht der zuvor gewählte UDP-Port. Unter Instances wählt man die lokale Instanz. In Keepalive interval wird 25 eingetragen, damit NAT-Zustände erhalten bleiben. Nach Save und Apply steht die Peer-Definition auch auf dieser Seite.
Firewall-Regeln am Remote-Standort
Auf dem zweiten Standort greift ebenfalls der Paketfilter. Ohne passende Regeln bleibt der Tunnel zwar aktiv, das LAN jedoch unerreichbar. Für den Verkehr vom lokalen Netz in Richtung Gegenstelle erfolgt die Konfiguration über Firewall und anschließend Rules und das Interface LAN. Dort wird eine Regel angelegt, deren Quelle das eigene Subnetz 192.168.0.0/24 ist und deren Ziel das entfernte Netz 192.168.100.0/24 darstellt. Nach dem Speichern übernimmt Apply changes diese Regel in die aktive Filterkonfiguration.
Der Rückweg erfordert eine separate Definition. Über Firewall und Rules und das Interface WireGuard (Group) wird eine weitere Regel erstellt. Als Quelle wird hier das entfernte Netz 192.168.100.0/24 eingetragen, als Ziel das lokale Netz 192.168.0.0/24. Erst diese Kombination erlaubt Verkehr aus dem Tunnel in das eigene LAN.
Soll die Firewall selbst eingehende Tunnelverbindungen annehmen, muss zusätzlich auf dem Interface WAN eine UDP-Regel angelegt werden. In dieser Regel steht als Ziel die WAN address und als Zielport der konfigurierte Listen-Port, im Beispiel 51821. Arbeitet dieser Standort ausschließlich initiierend und akzeptiert keine eingehenden Handshakes, kann diese WAN-Regel entfallen.
Technische Inbetriebnahme und Validierung
Nach Abschluss der Konfiguration folgt die Validierung. Zunächst prüfen Sie die Tunneladressierung durch einen Ping von 10.0.10.1 auf 10.0.10.2. Erfolgreiche Antworten bestätigen den Handshake.
Den Status kontrollieren Sie über VPN und WireGuard und Status. Dort erscheint der Zeitpunkt des letzten Handshakes. Ein aktueller Eintrag zeigt aktiven Datenaustausch.
Anschließend testen Sie die Erreichbarkeit eines Systems im entfernten Netz von einem Client im lokalen LAN. Funktioniert dieser Zugriff, greifen Tunnel, Routing und Paketfilter ineinander.
Betrieb, Monitoring und Erweiterung
Für den produktiven Betrieb empfiehlt sich eine kontinuierliche Überwachung. Ein Monitoring-System kann regelmäßige ICMP-Tests zwischen den Standorten durchführen. Zusätzlich lohnt ein Blick in die System-Logs, um wiederkehrende Re-Keys oder Verbindungsabbrüche frühzeitig zu erkennen. WireGuard skaliert ohne komplexe Policy-Strukturen. Weitere Standorte erhalten eigene Tunneladressen im Transfernetz und separate Peer-Einträge. Jede neue Verbindung erfordert eine eindeutige Netzdefinition, eine passende Route und korrespondierende Firewall-Regeln.
Eine belastbare Standortkopplung mit WireGuard auf OPNsense ergibt sich nicht durch eine Vielzahl an Optionen, sondern durch konsequente Netzwerkplanung, vollständige Peer-Definition und sorgfältig abgestimmte Filterregeln. Wer diese Elemente durchgängig beachtet, betreibt eine leistungsfähige und wartungsarme Verbindung zwischen zwei Unternehmensstandorten.
