Quelltext der Seite OPNsense - WireGuard Site-to-Site und Road Warrior

{{Steckbrief
| gilt_fuer   = 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 (<code>wg(4)</code>).

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.

{{Hinweis|Mit '''OPNsense 26.7.2''' (August 2026) wurde die FreeBSD-Sicherheitslücke ''FREEBSD-SA:26:52.if_wg'' im WireGuard-Kerneltreiber geschlossen. Firewalls mit WireGuard sollten mindestens auf diesem Stand sein – aktuell ist 26.7.5.}}

== WireGuard in OPNsense: Grundbegriffe ==
WireGuard kennt keine Rollen „Server“ und „Client“ – alle Teilnehmer sind gleichberechtigte '''Peers'''. OPNsense bildet das in zwei Objekten ab:
{| class="wikitable"
! Objekt !! Bedeutung !! Wichtige Felder
|-
| '''Instance''' (lokale Seite) || Die WireGuard-Schnittstelle auf dieser Firewall (Gerät <code>wg0</code>, <code>wg1</code> …) 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? ===
{| class="wikitable"
! Kriterium !! WireGuard !! [[OPNsense - IPsec Site-to-Site route-based|IPsec]] !! [[OPNsense - OpenVPN Site-to-Site und Client-VPN|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 [[OPNsense - OpenVPN Site-to-Site und Client-VPN|OpenVPN]] die bessere Wahl – oder ein Zero-Trust-Ansatz auf WireGuard-Basis wie [[OPNsense - NetBird-Plugin|NetBird]] mit Anmeldung über den Identity Provider.

[[Datei:OPNsense-WireGuard.png|thumb|center|750px|WireGuard auf OPNsense: Instanz mit Schlüsselpaar und UDP-Port 51820, Site-to-Site-Peer mit Allowed IPs für das entfernte LAN und Road-Warrior-Peers mit je einer /32-Tunneladresse.]]

== Teil 1: WireGuard Site-to-Site zwischen zwei OPNsense ==
=== Beispiel-Szenario ===
{| class="wikitable"
! Eigenschaft !! Standort A (Zentrale) !! Standort B (Filiale)
|-
| Öffentliche Adresse || <code>203.0.113.1</code> || <code>203.0.113.2</code> (oder dynamisch)
|-
| LAN || <code>172.16.0.0/24</code> || <code>192.168.0.0/24</code>
|-
| Tunneladresse (Transfernetz <code>10.2.2.0/24</code>) || <code>10.2.2.1/24</code> || <code>10.2.2.2/24</code>
|-
| Listen port || <code>51820</code> || <code>51820</code>
|}

=== Schritt 1: Instanzen anlegen (beide Seiten) ===
'''VPN → WireGuard → Instances''' → '''+''' (erweiterten Modus einschalten):
{| class="wikitable"
! Feld !! Standort A !! Standort B
|-
| Enabled || ✔ || ✔
|-
| Name || <code>wg-site-a</code> || <code>wg-site-b</code>
|-
| Public key / Private key || mit dem Zahnrad erzeugen || mit dem Zahnrad erzeugen
|-
| Listen port || <code>51820</code> || <code>51820</code>
|-
| MTU || <code>1420</code> (Standard), bei PPPoE <code>1412</code> || wie A
|-
| Tunnel address || <code>10.2.2.1/24</code> || <code>10.2.2.2/24</code>
|-
| 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.

{{Hinweis|Die Tunneladresse immer in CIDR-Notation mit dem '''Netz des Transfernetzes''' angeben (z. B. <code>/24</code>), nicht als <code>/32</code>. Seit FreeBSD 15 (OPNsense 26.x) werden Adressen ohne Netzmaske ohnehin nicht mehr akzeptiert.}}

=== Schritt 2: Peers anlegen (beide Seiten) ===
'''VPN → WireGuard → Peers''' → '''+''':
{| class="wikitable"
! Feld !! Auf Standort A (Peer = B) !! Auf Standort B (Peer = A)
|-
| Name || <code>wg-site-b</code> || <code>wg-site-a</code>
|-
| 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 || <code>10.2.2.2/32</code>, <code>192.168.0.0/24</code> || <code>10.2.2.1/32</code>, <code>172.16.0.0/24</code>
|-
| Endpoint address / port || <code>203.0.113.2</code> / <code>51820</code> || <code>203.0.113.1</code> / <code>51820</code>
|-
| Instances || <code>wg-site-a</code> || <code>wg-site-b</code>
|-
| Keepalive interval || leer || <code>25</code>, 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.

{{Hinweis|Hostnamen im Feld ''Endpoint address'' (z. B. DynDNS) werden nur beim Start des Tunnels aufgelöst. Ändert sich die Adresse, unter '''System → Settings → Cron''' einen regelmäßigen Job mit dem Befehl '''Renew DNS for WireGuard on stale connections''' anlegen (z. B. alle 5 Minuten).}}

=== 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 <code>51820</code>.
* '''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 <code>192.168.0.0/24</code> → Ziel <code>172.16.0.0/24</code>, 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''' <code>1380</code> 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 <code>/64</code>) 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 <code>51821</code>, Tunnel address <code>10.10.10.1/24</code>. 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. <code>vpn.example.com:51821</code>
* '''DNS Servers:''' DNS-Server für die Clients, z. B. <code>10.10.10.1</code> ([[OPNsense - Unbound DNS Resolver|Unbound]] auf der Firewall)
* '''Allowed IPs:''' die Netze, die die Clients über den Tunnel erreichen sollen, z. B. <code>172.16.0.0/24</code> (Split Tunnel) oder <code>0.0.0.0/0, ::/0</code> (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. <code>10.10.10.2/32</code>) werden vorgeschlagen.
# Optional '''Pre-shared key''' und '''Keepalive interval''' (<code>25</code> fü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 (<code>/32</code> bzw. <code>/128</code>) – 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. <code>wg1</code>) 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 <code>51821</code>.
* '''Interface der Instanz''' (oder Gruppe ''WireGuard''): erlaubte Ziele für die Clients, z. B. ''WG_CLIENTS net'' → <code>172.16.0.0/24</code>, DNS auf die Firewall. Für Full Tunnel zusätzlich Internetzugriff freigeben.
* Ohne zugewiesene Schnittstelle bei Full Tunnel unter '''Firewall → NAT → Source NAT''' (Modus Hybrid oder Manual, siehe [[OPNsense - NAT und Portweiterleitungen|NAT in OPNsense]]) manuell eine Regel anlegen: Interface ''WAN'', Quelle <code>10.10.10.0/24</code>, Übersetzung ''Interface address''.

=== Clients ===
WireGuard-Apps gibt es für Windows, macOS, Linux, iOS und Android. Auf dem Client entspricht die Konfiguration dem Format:
<pre>
[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
</pre>
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 – Zero-Trust-Netzwerk mit WireGuard|NetBird]] oder [[Tailscale – Mesh-VPN auf WireGuard-Basis|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 <code>0.0.0.0/0</code> – 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 [[OPNsense - Gateways und Multi-WAN|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 [[OPNsense - OSPF und OSPFv3 mit FRR|OSPF]] oder [[OPNsense - BGP mit FRR|BGP]] (Plugin [[OPNsense - FRR Dynamisches Routing|os-frr]]) betreiben. Die '''Allowed IPs''' müssen dann alle Netze umfassen, die dynamisch gelernt werden können (im Zweifel <code>0.0.0.0/0</code> bei einem Peer pro Instanz).

=== Hochverfügbarkeit mit CARP ===
In einem [[OPNsense - Hochverfügbarkeit mit CARP und pfsync|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 [[OPNsense - OpenVPN Site-to-Site und Client-VPN|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 [[OPNsense - Wazuh-Agent|Wazuh-Agent]] in ein [https://www.max-it.de/it-services/siem-open-source/ Open-Source-SIEM auf Wazuh-Basis].

== Typische Probleme und Lösungen ==
{| class="wikitable"
! 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 <code>0.0.0.0/0</code> ü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: <code>wg show</code> 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 [https://www.max-it.de/it-services/opnsense/ OPNsense-Firewall-Services von m.a.x. it] und einer [https://www.max-it.de/it-services/managed-firewall/ Managed Firewall von m.a.x. it].

== Siehe auch ==
* [[OPNsense - NAT und Portweiterleitungen]]
* [[OPNsense - Gateways und Multi-WAN]]
* [[OPNsense - IPsec Road Warrior mit IKEv2]]
* [[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 ==
* [https://docs.opnsense.org/manual/vpnet.html OPNsense-Doku – Virtual Private Networking (WireGuard)]
* [https://docs.opnsense.org/manual/how-tos/wireguard-s2s.html OPNsense-Doku – WireGuard Site-to-Site Setup]
* [https://docs.opnsense.org/manual/how-tos/wireguard-client.html OPNsense-Doku – WireGuard Road Warrior Setup]
* [https://docs.opnsense.org/manual/how-tos/wireguard-selective-routing.html OPNsense-Doku – WireGuard Selective Routing]
* [https://www.wireguard.com/ WireGuard – offizielle Website]
* [https://www.max-it.de/it-services/opnsense/ m.a.x. it – OPNsense-Firewall-Services]

{{Uebermax}}
[[Kategorie:IT-Security]]