Merkzettel: VPN Installation mit Wireguard

Home Office und VPNs sowie VPN Standort Vernetzungen sind im Forum oftmals Grund technischer Fragen zum Thema VPN. Insbesondere wenn es um das recht neue Wireguard VPN geht.
Wireguard hat weniger Hürden bei der Schlüsselerstellung und man kommt auch als Laie schnell und unkompliziert zu einem VPN Setup sowohl für den mobilen Client Zugang als auch zur VPN Standort Vernetzung. Auch hier gilt wie im OpenVPN Schwester-Tutorial das mit einem alten ausrangierten PC, einem Raspberry Pi 4 oder einem NAS mit Wireguard App so ein VPN schnell aufgesetzt ist.
Ebenso haben eine Vielzahl von Routern und Firewalls (pfSense, OPNsense) als auch das alternative Router Betriebssystem OpenWRT von sich aus Wireguard schon an Bord und können (und sollten) einen VPN Server im internen LAN ersetzen.
Ob es ein Raspberry Pi, Ubuntu, Windows, Mac OS oder die Router Hardware selber ist, spielt dabei keine Rolle. Analog zu OpenVPN ist der Vorteil das die VPN Server und Client Konfiguration über alle Plattformen und Betriebssysteme hinweg identisch ist.
Die Einfachheit der Schlüsselerstellung und das unkomplizierte Setup in Kombination mit sehr guter VPN Performance ist ein Grund für den rasanten Erfolg von Wireguard.
Zweifelsohne gibt es auch noch andere VPN Protokolle, wie das von der FritzBox benutzte, standartisierte und weit verbreitete IPsec. Desweiteren L2TP und OpenVPN. Alles zu behandeln würde aber den Rahmen dieses kurzen, rein auf Wireguard bezogenen, "Merkzettels" sprengen und es wird auf die weitereren VPN Tutorials hier im Forum verwiesen, die in den weiterführenden Links unten zu finden sind.


Erfahrene Netzwerk Admins erkennen das das hier vorgestellte VPN Design mit dem Betrieb des VPN Servers im internen LAN aus Sicherheits Aspekten alles andere als ideal ist. Der Grund dafür ist, das man von außen ungeschützten (VPN) Traffic ins interne, geschützte LAN lassen muss.
Ein Sicherheits Nachteil der im Vergleich bei VPN Betrieb direkt auf der Netzwerk Peripherie wie Router oder Firewall nicht besteht. VPN Traffic muss so nicht durch Löcher in der Firewall (Port Forwarding) ins interne, geschützte LAN gesendet werden.
Ein VPN in der Peripherie ist also per se sicherer.
Dazu kommt das bei einem sog. "one armed" VPN Server im lokalen LAN aller VPN Datenverkehr über ein gemeinsames Interface zum und vom VPN Server laufen muss. Dies schränkt zusätzlich Performance und Skalierbarkeit ein, ist in einfachen Heimnetzen aber oft tolerabel.
In kleinen Netzwerken sind diese VPN fähigen Router oder Firewalls häufig nicht vorhanden oder es fehlt schlicht entsprechendes Netzwerk KnowHow oder andere Gründe die vorhandene Hardware zu ersetzen.
Das Tutorial versucht mit den folgenden Installations Tips einen Spagat zwischen beiden Optionen. Grundlage ist wieder, wie auch im hiesigen OpenVPN Tutorial, ein klassisches VPN Standard Design:

(Die o.a. Abbildung gilt für ein Design wo die Client VPN Verbindung auf einen internen Server und nicht direkt auf Router oder Firewall terminiert ist. Letztere Option ist immer die bessere da deutlich sicherer!)

Oder als Site to Site Installation:

Die Internet Router Einstellungen sind auch hier wieder stellvertretend für andere Router Hardware anhand einer FritzBox beschrieben.
Die anschaulichen Setups der AVM Router gelten hier stellvertretend für ALLE anderen Router Modelle !
Das lokale LAN mit dem Wireguard Server im obigen Beispiel arbeitet mit der IP Netzwerk Adresse 192.168.188.0 /24 und dem internen Wireguard IP Netzwerk 100.64.64.0 /24. Der 100.64.0.0 /10 Adress Block wird im Internet nicht geroutet (RFC 6598).
Die Adressierung dient nur als Beispiel und kann man natürlich auf eigene IP Adressierungen anpassen. Dabei sollte man immer eine vorausschauende VPN IP Adressierung (u.a. HIER) beachten!
Los gehts...!



Das Tutorial geht von einer klassischen Wireguard Installation aus mit dem Default Port UDP 51820. Hat man das im Setup geändert, muss dies in den Konfig Dateien entsprechend angepasst werden.
Wer aus Sicherheitsgründen nicht den Standard Port verwenden will, sollte aufgrund der weltweit fest genormten Port Zuweisungen durch die IANA immer auf die sog. freien Ephemeral_Ports im Bereich 49152 bis 65535 ausweichen. Diese Ports werden in der Regel von Angreifern wenig bis gar nicht gescannt.
Oft limitieren auch vorgeschaltete Firewalls den Port. Hier kann man dann auf Port 443 (HTTPS) oder 22 (SSH) wechseln. Allerdings erzwingt Wireguard immer eine UDP Encapsulierung so das bei korrekt konfigurierten Firewalls (TCP) ein solcher Portwechsel keine Lösung ist.


Im obigen Design mit separatem internem Wireguard Server statt Server auf Router oder Firewall, ist eine feste, statische IP Route im Internet Router erforderlich die auf die lokale Wireguard Server IP Adresse und sein internes VPN IP Netz zeigt. Es ist daher sinnvoll dem Wireguard Server immer eine statische und damit verlässliche IP Adresse zu vergeben. Sollte eine dynamische DHCP IP Adresse sich einmal ändern, läuft in so einem Fall diese Route ins Leere und das VPN verliert die Verbindung. Etwas, das es zu vermeiden gilt !
Es ist deshalb immer eine gute Idee dem VPN Server eine statische IP Adresse zu vergeben. Er ist VPN Router und Router bekommen aus den o.a. Gründen prinzipbedingt statische IP Adressen an ihren Interfaces.
Das kann manuell am Server selbst im Netzwerk Setup gemacht werden. Einfacher ist es über die Hardware MAC Adresse der verwendeten Server Hardware (Netzwerkkarte), via DHCP Server im Router (z.B. Fritzbox) eine feste IP zuzuweisen.
So kann der Server flexibel im DHCP Betrieb verbleiben (was meist Default in allen OS ist), bekommt aber über diese feste Mac Adresszuweisung dennoch immer eine feste IP Adresse.
Das Screenshot Beispiel zeigt diese Einstellung an einem FritzBox DHCP Server:


Welche Hardware Adresse (Mac) der Server verwendet verrät auf dem Server das Kommando ipconfig -all (Windows) oder ifconfig (Linux, MacOS).
Wer diese Option der Mac Adress basierten Zuweisung nicht hat, sollte immer eine statische Server IP vergeben die außerhalb des DHCP Adressbereich des Routers liegt !


Der VPN Tunnel selber verwendet in Wireguard, analog wie bei OpenVPN, ein eigenes IP Netzwerk das mit dem Konfig Kommando (Beispiel) Address = 100.64.64.1/24 in der Server Konfigurations Datei bestimmt wird. Dazu später mehr.
❗️Dieses VPN interne IP Netzwerk muss, wie immer in einem gerouteten Umfeld, einzigartig sein im gesamten Netz und ist deshalb nicht trivial. Auch hier gilt es eine Überschneidung mit den zahllosen Standard Allerweltsnetzen aus dem Wege zu gehen. (Siehe Hinweise HIER).

👉🏽 Ein Wort zur hier verwendeten internen Wireguard Adressierung:
Der Server bekommt hier die Hostadresse .1 als interne IP und der Client Bereich beginnt bei der Adresse .100.
Oftmals wird bei der internen IP Adressierung mit dem Server bei der .1 angefangen und die Clients dann fortlaufend zu vergeben.
Anders herum macht es deutlich mehr Sinn und ist IP kosmetisch noch viel eleganter.
Bei einem internen /24er Netz fängt man "oben" mit der .254 für den Server an und nummeriert die Clients angefangen mit der .1 aufsteigend "nach oben".
So hat man den Client Block adresskosmetisch sauber getrennt und kann die fortlaufenden Client IP Adressen im Troubleshooting Fall .1xy sehr schnell und übersichtlich sofort identifizieren. 1.Client = .1, 2.Client = .2 usw.
Diese IP Adressierung der Übersicht halber ist rein kosmetischer Natur und kann letztlich jeder nach eigenem Ermessen vornehmen.
Ein klein wenig "Struktur" bei der Wireguard IP Adressplanung kann aber generell nie schaden und erleichtert immer ein späteres Management (Zugangskontrolle etc.) und Troubleshooting! 😉



Damit VPN Clients von außen einen internen Wireguard VPN Server überhaupt erreichen können, müssen diese die von außen schützende Firewall des Routers überwinden. Ohne ein entsprechendes Port Forwarding (Port Weiterleitung, siehe Betrachtung zum VPN Design oben!) würde die Router NAT Firewall solche externen Verbindungen immer blockieren, mit dem Effekt das kein VPN Client den internen VPN Server erreichen kann.
Man "sagt" hier also mit der Port Forwarding Freigabe der Router Firewall das sie doch bitte eingehende IP Pakete mit Port UDP 51820 auf die interne Server IP Adresse (hier 192.168.188.254 = Wireguard VPN Server) passieren lassen soll:


Diese Einstellung lässt dann am Router Internet Port den eingehenden Wireguard Verkehr mit UDP 51820 (und NUR diesen Verkehr !) auf die interne Wireguard VPN Server IP 192.168.188.254 passieren.
Daraus folgt, dass die VPN Ziel IP, die im Client zu konfigurieren ist immer die WAN Port/Internet IP des Routers sein muss und nicht die lokale LAN IP des VPN Servers !

⚠️ An diesem Punkt ist der oben schon angesprochenen gravierende Nachteil einer solchen internen VPN Lösung zu erkennen!
Wäre der VPN Server direkt auf dem Internet Router oder Firewall onboard, wie es üblicherweise "Best Practice" ist, dann müsste man keine dieser "Löcher" in die Firewall bohren und ungeschützten Traffic ins interne Netz leiten. Das VPN Konzept wäre in sich deutlich sicherer. Deshalb gilt immer die goldene VPN Regel: "VPNs gehören auf die Peripherie" und nicht ins interne LAN!!


Der Wireguard VPN Server spannt, wie oben bereits beschrieben, intern ein eigenes IP Netz auf. Damit externe VPN Clients alle Endgeräte des lokalen LANs erreichen können, muss der Internet Router natürlich wissen wie er das interne Wireguard IP Netz erreichen kann.
Das übernimmt eine feste, statische Route im Internet Router die allen Traffic für das Wireguard IP Netz (hier 100.64.64.0 /24) dann an den Wireguard VPN Server (192.168.188.254) sendet.
Die statische Route im Beispiel mit einem 18 Bit Prefix (255.255.192.0 Maske) routet alle remoten IP Netze von 192.168.0.0 bis 192.168.63.0 an den Wireguard Server. Dies muss ggf. an die eigene IP Adressierung entsprechend angepasst werden.
(siehe dazu auch Netzwerk Skizze oben).


Auch wieder analog zu OpenVPN werden Server und Client mit einer einfachen Text Datei konfiguriert. Bei Windows und anderen grafischen Betriebssystemen ist das in den grafischen Wireguard Client entsprechend eingebunden. Idealerweise erstellt man mit einem Text Editor diese Konfig Datei mit der Endung .conf und kann sie dann ganz einfach über die Import Funktion ins grafische Wireguard Setup importieren.
Für mobile Endgeräte wie Smartphones und Tablets bieten sich QR Code Tools an, die diese Client Konfig als QR Code exportieren und so sehr einfach in diese Geräte per onboard Kamera importiert werden können. Dazu später mehr.
Server (Responder) Betrieb mit IPv4 an DS-Lite oder CG-NAT Anschlüssen siehe Thread Hinweis
Die folgenden Kapitel erklären die grundlegende Einrichtung von Server und Client.


Der Wireguard VPN Server ist aus IP Sicht ebenfalls ein Router, denn er routet immer zwischen dem lokalen LAN IP Netz und dem internen Wireguard Tunnel IP Netz (hier im Beispiel 100.64.64.0 /24).
Normalerweise ist das Routing (IP Forwarding) auf Endgeräten, egal mit welchem Betriebssystem, per Default immer deaktiviert !
Damit der Server nun IP Pakete vom lokalen LAN ins VPN IP Netz und umgekehrt überhaupt routen kann muss dafür das Routing (IP Forwarding) auf dem Wireguard Server Rechner im Betriebssystem aktiviert werden. Ein Umstand der leider oft vergessen wird und dann zu Frust führt.

Bei Windows geschieht dies über einen Eingriff in die Registry oder die Dienste Verwaltung.
(IPEnableRouter Parameter auf 1) siehe auch: edv-lehrgang.de/ip-routing-aktivieren/


Unter Linux/Raspberry Pi usw. editiert man mit dem nano Editor die Datei /etc/sysctl.conf und entkommentiert dort den Eintrag:


indem man das "#" vor der Zeile net.ipv4.ip_forward=1 entfernt und somit das IP Forwarding/Routing aktiviert.
Danach sichert man diese Datei und rebootet den Linux Rechner.


Am Anfang steht immer die Generierung der privaten und öffentlichen Schlüssel für den VPN Server und den VPN Client (Peer). Ein Schlüsselpaar besteht immer aus einem öffentlichen (public) Schlüssel den man offen weitergeben kann und aus einem privaten Schlüssel der entsprechend geschützt werden muss. Die Schlüssel sind einfache Text Strings die man per Cut and Paste in jedem Text Editor verarbeiten kann.
Unter Linux ist das schnell mit den bordeigenen Wireguard Tools erledigt:


Weitere VPN Client (Peer) Schlüssel generiert man dann nur noch mit wg genkey | tee client2_private.key | wg pubkey > client2_public.key usw.
Wie man den Schlüssel nennt ist beliebig. Eindeutige Bezeichnungen wie wg genkey | tee Meier_private.key | wg pubkey > Meier_public.key sind natürlich auch möglich.
Die Key Dateien sind einfache Text Dateien deren Inhalt man sich z.B. mit cat server_private.key oder Editor anzeigen lassen kann.

Unter Windows klickt man "Einen leeren Tunnel hinzufügen" was dann das entsprechende Schlüsselpaar generiert und komplettiert dann das Setup im Textfeld.
Alternativ importiert man hier eine komplett fertige Konfig Datei mit der Endung .conf

⚠️ Private Keys bleiben immer ausschliesslich nur auf dem lokalen Gerät! Nur die Public (Öffentliche) Keys werden auf den remoten Geräten (Peer Definition) konfiguriert! Klassisches asymetrisches Schlüsselverfahren.

• Der Server hat seinen privaten Key und erhält in der Client Peer Definition den Public (öffentlichen) Key des Clients.
• Der Client hat seinen Privaten Key und erhält in der Server Peer Definition den Public (öffentlichen) Key des Servers.

Diese simple Server/Client Keylogik ist dann vereinfacht dargestellt für den Server (Responder):

Server (VPN Responder):
[Interface]
Address = <Interne_WG_Server_IP>
PrivateKey = <Privater-Key-Server>
ListenPort = <UDP_Tunnelport>
[Peer]
PublicKey = <Öffentlicher-Key-Client>
AllowedIPs = <Interne_WG_Client_IP/32, remote_IP_Netze>

Client (VPN Initiator):
[Interface]
Address = <Interne_WG_Client_IP>
PrivateKey = <Privater-Key-Client>
(DNS = 192.168.x.y) --> Optional, nur wenn interner DNS erforderlich ist.
[Peer]
PublicKey = <Öffentlicher-Key-Server>
Endpoint = <Server_IP_FQDN>: <UDP_Tunnelport>
AllowedIPs = <Interne_WG_Server_IP/32>
PersistentkeepAlive = 25


Die Server Konfig Datei befindet sich unter /etc/wireguard/wg0.conf ist sehr schlank und schnell aufgesetzt z.B. mit dem nano Editor. Sollte die Datei wg0.conf nicht vorhanden sein erzeugt man sie mit dem nano Editor.

• Address = Die internen VPN Server Tunnel Adresse
• PrivateKey = Der private Server Schlüssel den man oben generiert hat
• ListenPort = Der UDP Port auf den der Server hört. (Achtung: Dieser muss zu dem im Port Forwarding Konfigurierten identisch sein !)
• Im Peer Bereich dann der öffentliche Schlüssel des Clients und unter "AllowedIPs" die Adressen die der Wireguard Server in den Tunnel routet. Wireguard nennt dies "Cryptokey Routing" was bewirkt das der Wireguard Server und Client das Routing für die jeweils remoten IP Netze automatisch in die Routing Tabelle übernimmt.

⚠️ Wichtiger Hinweis: Die WG internen IP Adressen der Peers müssen eine /32 Subnetzmaske (Hostmaske) unter den "Allowed IPs" haben damit das Wireguard Cryptokey Routing diese Peers eindeutig den Clients zuordnen kann. (Siehe dazu auch HIER!)
Dieser Punkt wird sehr häufig nicht beachtet und dadurch oft falsch konfiguriert und führt damit zu einem fehlerhaften Routing im VPN.
Beispiel einer WG Standard Konfig die die korrekte Subnetzmasken Adressierung zeigt.

Mit wg-quick up wg0 startet man den Wireguard Server. Entsprechend stoppt wg-quick down wg0 ihn.
Ob der Tunnel aufgebaut wurde überprüft man mit wg show (unixoide OS).

Den automatischen Start des Wireguard Servers beim Booten erledigt der Befehl: Macht man danach Änderungen an der Wireguard Server Konfig muss anschliessend auch der Wireguard Server mit systemctl restart wg-quick@wg0.service neu gestartet werden !


⚠️ Im eigenen, internen Netzwerk ist IP Address Translation (NAT) im Tunnel (nftables, iptables) immer kontraproduktiv und führt dazu das kein transparentes Routing im VPN mehr möglich ist. Einige Anleitungen im Internet gehen häufig von zweifelhaften, öffentlichen VPN Dienstleistern aus um Geolocation Grenzen (Streaming usw.) zu überwinden wo dies dann erforderlich sein kann.
So ein Setup ("PostUp = iptables..." Kommandos) führt in einem privaten Standort- oder Client VPN, wie hier im Tutorial beschrieben, immer zu Fehlfunktionen durch das NAT bedingte einseitige Routing. Die zahlreichen Foren Threads zu dieser Thematik (z.B. hier) belegen das. Diese Kommandos sollten deshalb in einem Site-2-Site und Client Setup immer aus der VPN Konfig entfernt werden.
❗️Es gilt also beim Setup:
In der Konfig KEIN NAT/Masquerading Kommando am Tunnelinterface aktivieren!
(Kein PostUp = iptables... oder ...nftables etc.)

(Ein NAT/Masquerading im Tunnel kann dennoch in einigen, sehr wenigen Ausnahmen sinnvoll sein. Z.B. ein Firmen VPN wo Clients immer nur zentral und einseitig auf einen einzigen Server arbeiten. In so einem Fall ist bidirektionales Routing nicht erforderlich und aus Security Sicht oft nicht gewünscht und kann in diesem speziellen Fall von Vorteil sein. Final also immer eine Frage der eigenen Security Policy und Anforderung. Abgesehen davon löst man dies immer im Firewall Setup selbst und NICHT innerhalb des VPN Setups!)



Ein weiterer wichtiger Punkt der ebenso oft falsch gemacht wird und entsprechend beachtet werden sollte!
Ein "Allowed IPs 0.0.0.0/0" im Client Setup schickt anstatt dediziert NUR den Traffic des remoten lokalen LANs, immer den gesamten Client Traffic in den VPN Tunnel! Quasi wird dann das Default Gateway des Clients auf den VPN Tunnel umgeleitet.
Wenn dies im Setup aktiviert wird darf kein weiteres IP Netz mehr unter den "AllowedIPs=" definiert werden!!
Warum auch, denn 0.0.0.0/0 bedeutet "route ALLEN Client Traffic in den Tunnel"! "Alles" inkludiert logischerweise alle IP Netze und damit systembedingt sämtlichen Traffic des Clients wie DNS (Namensauflösung), NTP (Uhrzeit) etc.

Redirect belastet damit prinzipbedingt den Tunnel zu Lasten der Performance je nach Client Trafficvolumen deutlich mehr als das schlankere Split Tunneling Verfahren. Performancetechnisch damit kontraproduktiv und ein Nachteil. Das sollte man immer beachten!
Leider ein häufiger Konfigurationsfehler der oft aus Routing Unkenntis gemacht wird bzw. wenn lediglich nur relevanter Traffic für das remote Zielnetz ins VPN gerroutet werden soll.
Wenn kein Redirect gefordert ist und per Split Tunneling nur der relevante Traffic für das remote LAN (oder die LANs) in den VPN Tunnel fliessen soll, gibt man hier außer der Server IP mit einer /32er Maske nur noch das oder die jeweilige(n) remote(n) IP Netz(e) an.
Summary Subnet Masken sind hier natürlich ausdrücklich erlaubt um mehrere IP Netze bei intelligentem Subnetting mit einer einzigen Maske zu erfassen.
Mit Split Tunneling wird effizient nur Traffic für das remote LAN in den Tunnel gesendet. Lokaler Internet Traffic bleibt hier immer lokal und belastet den Tunnel somit nicht.
❗️Split Tunneling ist damit performancetechnisch immer die bessere Wahl sofern es auf VPN Durchsatz ankommt.

Wer aber dennoch z.B. aus Sicherheitsgründen allen Client Traffic verschlüsseln will, um z.B. in öffentlichen WLAN Hotspots oder unsicheren Gastnetzen geschützt unterwegs zu sein, kommt um ein Gateway Redirect Setup nicht drumherum.

Welches dieser beiden Verfahren sinnvoll ist, ist deshalb immer vom Einsatzprofil des VPNs abhängig und muss jeder Netzwerk Admin im Einzelfall entscheiden.
👉🏽 Fazit:

• In einer Redirect Konfig wird ausschliesslich nur 0.0.0.0/0 unter den "AllowedIPs" definiert, NICHT mehr!
• Es ist immer entweder nur Split Tunnel oder nur Gateway Redirect erlaubt!
• Eine Kombination beider Setups ist NICHT möglich und routingtechnisch natürlich auch völlig unsinnig, da ein Gateway Redirect, wie der Name ja schon sagt, sämtlichen Traffic routet.

⚠️ Vorab ein Hinweis zur lokalen Windows Firewall, da dies immer wieder zu Forenanfragen führt.
Die Windows Firewall blockt in der Regel generell ICMP (Ping) und verbietet den Zugriff auf lokale Serverdienste aus fremden IP Netzen.
Wireguard ist ein geroutetes VPN Verfahren so das immer fremde Absender IP Adressen genutzt werden, was dann zu einem generellen Blocking in der Windows Firewall führt.
Wer also Endgeräte per Ping erreichen will oder Dienste für den VPN Zugriff freigeben will, der muss dies entsprechend in der lokalen Windows Firewall erlauben.

Entsprechend zu oben sieht eine Server Konfig im Windows Setup dann so aus:

Hier startet man den Wireguard Server mit einem Klick auf "Aktivieren".




Die Client Konfig sieht entsprechend passend dazu aus:

• PrivateKey = Privater Key des Clients
• Unter [Peer] dann PublicKey = öffentlicher Schlüssel des VPN Servers
• Zusätzlich kommt hier der Eintrag Endpoint = <Zieladresse_Server>:51820 hinzu, der die IP Adresse oder den (DDNS) Hostnamen des VPN Servers sowie dessen UDP Port definiert.
• Ein Keepalive macht nur auf einem Client (VPN Initiator) Sinn. Er gehört nicht auf einen VPN Server (Responder)! (UDP Session Timeout bei NAT und Firewalls liegt je nach Hersteller zw. 30 und 60 Sek. so das man mit 25 Sek. in der Regel sicher ist)

Zu beachten ist das bei einer Installation des VPN Servers innerhalb lokaler LAN Netze immer der DynDNS Hostname des dortigen Routers oder dessen öffentliche WAN Port IP Adresse in der Endpoint Konfig angegeben wird. Nur diese IP ist aus dem Internet ansprechbar und leitet per Port Forwarding, wie oben bereits beschrieben, den VPN Tunnel an den internen Wireguard Server im lokalen LAN weiter.
Beispiele sind dann z.B. Endpoint = meinrouter.dnshome.de:51820 bei DynDNS Hostnamen oder Endpoint = 85.1.2.3:51820 oder eine IPv6 Adresse wer eine öffentliche IP hat.
Bei einer VPN üblichen Installation auf der Peripherie wie Router oder Firewall, entfällt das unsichere Port Forwarding natürlich.
Ein VPN Setup mit internem VPN Server ist daher generell latent unsicher, weil durch das Port Forwarding Loch in der Firewall ungeschützer Internet Traffic ins lokale Netz gelangt. VPNs gehören deshalb, wenn immer möglich, auf die Peripherie wie Router oder Firewall!

⚠️ Auch hier gilt wieder der obige Warnhinweis bezüglich der internen Peers und den /32er Masken für interne WG Adressen unter "Allowed IPs"!

Entsprechend sieht die Konfig dann wieder im Windows Setup aus:



Die separate DNS Angabe in der WG Client Konfig bewirkt das der Client bei aktivem VPN Tunnel (und auch nur dann!) den konfigurierten DNS Server des jeweiligen Betriebssystems mit dem DNS im WG Client Setup überschreibt.
Ist der WG Tunnel aktiv, wird dann nur dieser im WG Setup konfigurierte DNS verwendet sofern dort einer konfiguriert wurde. Der Betriebssystem DNS ist dann inaktiv. Bei inaktivem Tunnel wird wieder der im Betriebssystem konfigurierte oder per DHCP Gelernte verwendet.
Das kann man sehr schön auch selber einmal prüfen wenn ein DNS Server angegeben wurde (z.B. lokaler DNS, Aguard o. PiHole Filter) und bei aktivem VPN Tunnel einmal z.B. ein nslookup www.heise.de ausgeführt wird. Dort wird dann immer der aktiv verwendete DNS Server angezeigt.
Wer keinen internen DNS verwendet muss der benötigt in der Regel auch keinen DNS Eintrag im WG Client Setup!


⚠️ Wer einen Wireguard Server an oder hinter einem Router o. Firewall betreibt der wechselnde IP Internet Adressen hat und dadurch bedingt mit DDNS (Dynamischem DNS, myFritz, dnshome.de etc.) Hostnamen auf der Client Seite arbeiten muss bei der Angabe des Endpoint für die VPN Server Adresse, hat ein Dilemma.

Dies ist darin begründet das Wireguard bekanntlich DNS Namen ausschliesslich nur einmal beim Laden der Wireguard Konfiguration auflöst, nicht aber im laufenden Betrieb!
Sollte sich also bei laufender Verbindung die IP Adresse des Responders (VPN Server) ändern (z.B. mit einer Provider Zwangstrennung, Neustart etc.) funktioniert die Wireguard Verbindung auf den VPN Server (Responder) nicht mehr trotz geändertem DDNS. Ursache ist das der DNS Name eben ohne einen Neustart nicht neu aufgelöst wird! Wireguard selber hat derzeit keine Lösung dafür.
Bei permanent laufenden VPN Clients muss man sich mit einer Scripting Lösung wie z.B. HIER helfen.


Die Konfigurationsschritte gelten sowohl für die offizielle Wireguard App in den entsprechenden App Stores als auch für die alternative Android App WG Tunnel.



Außer der oben schon beschriebenen CLI Konfigdatei unter /etc/wireguard/wg0.conf können alle Linux Clients die mit einem GUI und dem NetworkManager arbeiten wie z.B. alle Debian basierten Distros wie RaspberryOS usw. über das GUI konfiguriert werden.
⚠️ Wichtig ist hier das die IPv4 Konfig am wg0 Interface auf manual gesetzt wird und dort die Wireguard interne Client IP angegeben wird!


Unter Linux installiert man mit apt install qrencode einen einfachen QR Encoder und generiert dann mit:

(-t = Grafikformat, -o = Output Bilddatei, -r = Read, Input Konfig Datei)

einen Wireguard Client QR Code den man dann einfach durch Abfotografieren mit der Kamera in Smartphone oder Tablet importiert.




Die Besonderheiten der nicht Standard konformen Wireguard Implementation auf der AVM Fritzbox beschreibt ein
👉🏽 separates Fritzbox Wireguard Tutorial!
Es beleuchtet alle proprietären AVM Details die bei der FritzBox Wireguard Kopplung zu beachten sind und deren Lösungen. Insbesondere zu Linux vServern, Mikrotik, GL.inet Routern und pfSense / OPNsense Firewalls.



Unter Windows checkt man zuerst die IP Adressierung mit ipconfig und die Routing Tabelle um zu prüfen das alle IP Settings OK sind.
Dann führt man einen Ping ins remote Netz aus über den VPN Tunnel. (Hier im Beispiel auf die gegenüberliegende FritzBox 192.168.188.1)
Ein sehr gutes Tool für Mobilgeräte sind dafür die HE.NET_Network_Tools aus den entsprechenden App Stores.



Ping Check vom remoten Client via VPN auf den Router (FritzBox):


Wer Zweifel an der sicheren Verschlüsselung hat, lässt einmal einen Wireshark Trace auf den Wireguard Server los. Hier im Beispiel einmal der Ping (IP ICMP Traffic) vom remoten VPN Clients auf die FritzBox:


Wie man im Screenshot zweifelsfrei sieht, lassen sich aus dem Sniffer Trace keinerlei Rückschlüsse ziehen welche Daten über den VPN Tunnel übertragen werden.



Das OPNsense Wireguard Setup folgt analog den schon oben beschriebenen Schritten für ein Standard Setup. Die folgenden GUI Screenshots zeigen die korrekte Konfiguration einer OPNsense Firewall als Wireguard Server (VPN Responder).
(Die Konfigurations Schritte können analog auf eine pfSense Firewall übertragen werden. Siehe dazu auch HIER)
Für diejenigen die es einfacher haben möchten mit den Subnetzmasken kann das hier im Beispiel verwendete interne /27er Tunnelnetz natürlich auch mit einer /24 Maske (oder beliebigen anderen) betrieben werden. Das /27er Netz ermöglicht 30 Client Adressen im internen VPN IP Netz (29 VPN Clients plus Server) zu betreiben von .1 bis .30. (Siehe auch Adressierungstips im Eingang dieses Tutorials!)

Zu sehen sind das lokale Setup (Local Configuration) des Wireguard Servers mit dem vom Server verwendeten UDP Port, den Keys und der internen IP Adressierung für den VPN Tunnel.
Der hier konfigurierte UDP Serverport muss mit der WAN Firewall Regel im Screenshot weiter unten korrespondieren.
⚠️ Wichtig ist am Client (Endpoint) auf die Subnetzmaske der Allowed IPs zu achten! Die internen Adressen bekommen hier immer eine /32er Hostmaske! Ein Punkt der leider sehr oft falsch gemacht wird und zu Problemen im Cryptokey Routing führt!
⚠️ Nicht ganz unwichtig ist ebenso der Konfig Punkt "Disable Routes"!
Im Gegensatz zur pfSense ermöglicht die OPNsense hier optional das automatische Hinzufügen der Client bzw. Peer Routen zu deaktivieren (Disable). Das Abschalten kann z.B. sinnvoll sein wenn man in größeren VPN Netzen dynamisch routet mit OSPF, RIP oder BGP. Dann übernimmt der dynamische Routing Prozess das Routing Update. (Siehe Folgekapitel Dynamisches Routing)
In üblichen WG Installationen mit einigen wenigen Clients oder Site-to-Sites belässt man es aber aktiviert (leer, ohne Haken!).

⚠️ Ein ebenfalls häufig vergesser Punkt ist das Wireguard Tunnel Interface dem „Interface Assignment“ hinzuzufügen! Dies geschieht mit exakt der statischen Server Tunnel IP Adresse die man dem Server schon im Grundsetup zugewiesen hat!
❗️(Im aktuellen OPNsense Release gibt es einen Fehler wenn man den Adresstyp auf "Static" setzt. Hier belässt man es dann beim Default "None"!)

Es sind 2 Firewall Regeln zu setzen:

• Die WAN Port Regel, die Wireguard UDP Traffic von außen eingehend auf die WAN Port IP Adresse zulässt
• Die Tunnel Regel, die Wireguard Traffic im VPN Tunnel zulässt. (Hier als Beispiel eine "Scheunentor" Regel die alles zulässt)

⚠️ Bei Letzterer gilt es aufzupassen diese Regel NICHT auf dem (Group) System Tunnel Interface zu konfigurieren, sondern immer auf dem Tunnel Interface, was man im Interface Assignment hinzugefügt hat!! (Das Systeminterface bleibt immer leer!)

Auch hier wieder die interne Tunnel Adresse mit einer /32er Hostmaske!
192.168.2.0 /24 ist das lokale LAN an der OPNsense Firewall.

Bei DS-Lite Anschlüssen ist eine VPN Verbindung von außen mit IPv4 generell nicht möglich. Dies verhindert das interne CG-NAT (IPv4 Adress Translation) auf Providerseite, da die DS-Lite Provider aus IPv4 Adressmangel im internen Kunden IP Netz mit im Internet nicht routebaren IPv4 Adressen arbeiten. Meist aus dem Shared Adress Bereich des RFC 6598.
An solchen Anschlüssen kann ohne zusätzliche Hardware wie z.B. eines externen IPv4 Jumphosts eine Verbindung von Extern ausschliesslich nur per IPv6 erfolgen.
Wegen der wechselnden IPv6 Präfixe an diesen Anschlüssen muss man auch hier mit DDNS Hostnamen wie z.B. myfritz usw. arbeiten. Es ist immer sicherzustellen das in diesen Falle der DDNS Hostname nur auf die IPv6 Adresse auflöst! (dig, host oder auch nslookup)
Die Wireguard Konfig ist im Rest mehr oder minder identisch zur IPv4 Variante.
Idealerweise arbeitet man an der Endpoint Definition mit dem FQDN Hostnamen oder einem DDNS Hostnamen, da der sowohl auf die v6 als auch die v4 Adresse auflöst und v6 immer Priorität hat. Das gilt besonders für Mobilfunknetze die durch die Bank, wie auch die DS-Lite/CGNAT Netze, v6 Netze sind.





Ein interessanter Aspekt ist WireGuard mit dynamischem Routing wie BGP, OSPF oder RIPv2 zu nutzen. Dies macht Sinn wenn man ein voll- oder teilvermaschtes VPN Design benutzt um so eine automatische Routing Redundanz zwischen verschiedenen Standorten zu nutzen. Damit lassen sich hochverfügbare VPN Standortverbindungen realisieren.
Normal verwendet man dazu VPN Router die dynamische Routing Protokolle integriert haben wie z.B. Cisco, pfSense / OPNsense, Mikrotik usw. und in diesem_Forentutorial grundlegend beschrieben ist.
Es lässt sich aber auch mit externen Servern realisieren. Sogar ein Raspberry Pi Scheckkarten Rechner reicht dafür.
Es würde den Rahmen dieses Tutorials sprengen alles im Detail zu beschreiben so das hier nur die wichtigsten ToDo Schritte für so ein Design aufgeführt sind.

Eine OSPF Praxislösung mit Mikrotik Routern findet man HIER
Wer statt OSPF lieber BGP machen möchte wird HIER fündig.

Basis ist die Quagga Routing Software wie sie HIER schon beschreiben wurde. Das Tutorial geht von einer bestehenden Grundinstallation aus und nutzt OSPF als Routing Protokoll Beispiel.

Die entsprechenden Konfig Dateien sehen so aus:
zebra.conf ospfd.conf wg0.conf Wichtig ist hier der beidseitige Eintrag "224.0.0.5/32" (und .6) unter "Allowed IPs" der das lokale Multicast zwischen den OSPF Knoten im VPN Tunnel erlaubt.



Wireguard Download:
wireguard.com/install/

Wireguard Client für Windows Standardbenutzer einrichten:
heise.de/ratgeber/Windows-WireGuard-VPN-fuer-Standardbenutzer-62 ...
heise.de/select/ct/2021/23/2125708303045829586
heise.de/select/ct/2021/23/softlinks/y9zm?wt_mc=pred.red.ct.ct23 ...

"Allowed IPs" Subnetz Rechner:
procustodibus.com/blog/2021/03/wireguard-allowedips-calculator/

Wireguard Performance Vergleich:
wireguard.com/performance/



Fritzbox Wireguard VPN auf Mikrotik, pfSense/OPNsense, Linux und andere Wireguard Router:
Site-to-Site VPN Fritzbox als Wireguard Client auf Mikrotik Server
Dito. aber Fritzbox als Wireguard Server
AVM Besonderheiten:
Wireguard Lan to Lan Fritzbox Raspberry Pi
heise.de/select/ct/2022/23/2225809105962410605
Fritzbox Wireguard und GL.inet Mobilrouter
Fritzbox VPN Wireguard Verbindung zu Beryl Client

Wireguard Tunnel Interface bei pfSense u. OPNsense Firewall korrekt zuweisen!:
Clients hinter Mini Reise router mit openVPN
Wireguard Interfaces bei OPNsense, Teil 1
Wireguard Interfaces bei OPNsense, Teil 2



Wireguard LAN zu LAN VPN mit pfSense / OPNsense (Server, Responder) und Mikrotik (Client, Initiator):
Mikrotik als Wireguard VPN Client auf pfSense/OPNsense Server
Mikrotik als Wireguard VPN Client auf klassischen Server

pfSense als Wireguard Client (Initiator):
pfSense als Wireguard Client an vServer anbinden

Mikrotik als Wireguard Server (Responder):
Wiregard Server mit Mikrotik konfigurieren

BGP Routing über einen Wireguard Tunnel :
Wireguard BGP Routing

OSPF Routing mit Wireguard und Mikrotik
Verständnisfrage zu OSPF-Routing bei MikroTik-Routern (RouterOS)



Praxisbeispiel mit Wireguard Standort Vernetzung und mobilen Clients:
Wireguard Site2Site mit Roadwarrior

WG Client und Server separat im lokalen LAN:
WG Client u. Server im lokalen LAN

DS-Lite Anschluss und VPN: Lösung mit Vermittlungsserver und fester IP:
vServer Jumphost mit Fritzbox Kopplung
Zwei Mobilfunkrouter (TP-Link MR200) per VPN verbinden, ev. per externen VPN-Gateway (VPS-Server)
Feste IPs zu Hause über WireGuard-Tunnel in pfSense einrichten
Feste IPs zu Hause über GRE-Tunnel in pfSense einrichten
Tücken bei remotem Port Forwarding in den WireGuard VPN Tunnel beachten:
Wie Portforwarding über 2 miteinander verbundenen pfSense realisieren

Achtung bei Gateway Redirect Konzepten. Split Tunneling ist oft die bessere Wahl!:
Wireguard Traffic (Gateway redirect)
Wireguard verhält sich "komisch"

Lokalen Webserver über WG und vServer erreichbar machen:
Gesamten Netzwerkverkehr (in und out) über Wireguard und V-Server ins Internet leiten

VPN Tunnel MTUs richtig handhaben:
Langsamer Upload opnsense wireguard zu Ubuntu Server 20.04 (0,26 mb s)

Wireguard Integration in Systemd:


Grafisches Konfig Interface für Wireguard VPN Server:
adminforge.de/linux-allgemein/vpn/wireguard-vpn-server-mit-web-i ...



Linux VPN Server für alle Windows, Apple, Smartphone onboard VPN Clients und Smartphones:
IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi

OpenVPN Installations "Merkzettel":


L2TP VPN Server mit onboard VPN Clients auf pfSense/OPNsense Firewall:


L2TP VPN Server mit onboard VPN Clients auf Mikrotik Router:
Scheitern am IPsec VPN mit MikroTik

IPsec IKEv2 VPN Server für alle onboard VPN Clients auf pfSense/OPNsense Firewall:


Dynamisches VPN Routing mit OSPF oder RIPv2:
Cisco, Mikrotik, pfSense VPN Standort Vernetzung mit dynamischem Routing

Preiswerte Wireguard und OpenVPN Router Hardware:
amazon.de/GL-iNet-GL-MT300N-V2-Repeater-Performance-Compatible/d ...

Raspberry Pi 4 Hardware:
reichelt.de/raspberry-pi-4-b-4x-1-5-ghz-2-gb-ram-wlan-bt-rasp-pi ...
reichelt.de/raspberry-pi-4-b-4x-1-5-ghz-4-gb-ram-wlan-bt-rasp-pi ...
Netzteil:
reichelt.de/raspberry-pi-netzteil-5-1-v-3-0-a-usb-type-c-eu-stec ...
Passendes Gehäuse mit passiver Kühlung:
amazon.de/iuniker-Raspberry-Gehäuse-Kühlkörper-Me ...

HKLM\Software\WireGuard\