aqui
Goto Top

Merkzettel: VPN Installation mit Wireguard

article-picture

back-to-topEinleitung


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.

back-to-topVPN Design Überlegungen


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 aber oft nicht vorhanden oder es fehlt entsprechendes Netzwerk KnowHow o. a. Gründe 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:

wireguardneu

Oder als Site to Site Installation:
wg_neu.

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!

back-to-topNAT/Masquerading (Adress Translation) im VPN Tunnel


⚠️ Im eigenen, internen Netzwerk ist IP Address Translation (NAT) im Tunnel (nftables, iptables) immer kontraproduktiv und führt dazu das kein transparentes Routing mehr möglich ist. Einige Anleitungen im Internet gehen häufig von öffentlichen VPNs aus um Geolocation Grenzen (Streaming usw.) zu überwinden wo dies dann erforderlich ist. So ein Design führt in einem privaten Standort oder Client VPN, wie hier im Tutorial, immer zur Fehlfunktion. Die zahlreichen Foren Threads zu der Thematik belegen dies...
❗️Es gilt also bei privaten VPNs: KEIN NAT/Masquerading am Tunnelinterface aktivieren! (iptables oder nftables)

Ein NAT/Masquerading im Tunnel kann dennoch in einigen, wenigen Designs erforderlich sein. Z.B. ein Firmen VPN wo Clients immer nur zentral auf einen einzigen Server arbeiten. In so einem Fall ist bidirektionales Routing nicht erforderlich und aus Security Sicht oft nicht gewünscht, kann in diesem speziellen Fall also von Vorteil sein. Final also immer eine Frage der eigenen Security Policy und Anforderung.
Los gehts...!


back-to-topEinstellungen an Router bzw. Firewall


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.

back-to-topIP Adressierung des Wireguard Servers


Im obigen Design mit internem Wireguard Server zeigt eine feste, statische IP Route im Internet Router auf die lokale Wireguard Server IP Adresse und sein internes VPN IP Netz. Es ist daher sinnvoll dem Wireguard Server auch 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 gewissermaßen VPN Router und Router bekommen 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), dem 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:

wg1
wg2

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 !

back-to-topInterne Wireguard IP Adressierung


Der VPN Tunnel selber verwendet in Wireguard, analog wie bei OpenVPN, ein eigenes IP Netzwerk und wird mit dem Konfig Kommando (Beispiel) Address = 100.64.64.1/24 in der Server Konfigurations Datei bestimmt. 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 noch zur hier verwendeten internen Wireguard Adressierung:
Der Server bekommt hier die .1 als interne IP und der Client Bereich beginnt bei der .100.
Es macht immer Sinn von der Adressierung mit dem Server bei der .1 anzufangen und die Clients "von oben nach unten" zu vergeben.
Anders herum geht es natürlich auch und ist IP kosmetisch noch viel eleganter.
Bei einem /24er Netz intern fängt man "oben" mit der .254 für den Server an und nummeriert die Clients angefangen mit der .1 aufsteigent "nach oben".
So hat man den Client Block adresskosmetisch getrennt und kann die fortlaufenden Client IP Adressen im Troubleshooting Fall .1xy sehr schnell und übersichtlich sofort identifizieren.
Diese IP Adressierung der Übersicht halber ist rein kosmetischer Natur und kann jeder nach eigenem Ermessen vornehmen.
Ein klein wenig "Struktur" bei der Wireguard IP Adressplanung kann aber generell nie schaden und erleichtert immer späteres Management (Zugangskontrolle etc.) und Troubleshooting! 😉

back-to-topPort Forwarding oder auch Port Weiterleitung bzw. Freigabe im Router


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:

wg4
wg5

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 "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!!

back-to-topStatische Route auf das remote LAN und interne VPN IP Netz konfigurieren


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.
wg3
(siehe dazu auch Netzwerk Skizze oben).

back-to-topWireguard Server und Client Konfiguration


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.
Die folgenden Kapitel erklären die grundlegende Einrichtung von Server und Client.

back-to-topIP Forwarding (Routing) im Wireguard Server aktivieren


Der Wireguard VPN Server ist aus IP Sicht ebenfalls ein Router, denn er routet ja immer zwischen dem lokalen LAN und dem internen Wireguard Tunnel IP Netz (hier im Beispiel 100.64.64.0 /24).
Normalerweise ist das Routing (IP Forwarding) auf Servern, 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 oft vergessen wird und dann zu Frust führt.

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

winipforw

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

 # Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1 

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.

back-to-topKonfiguration Wireguard Server


Am Anfang steht immer die Generierung der Schlüssel für den VPN Server und den VPN Client (Peer). Ein Schlüsselpaar besteht immer aus einem öffentlichen Schlüssel den man 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:

umask 077
wg genkey | tee server_private.key | wg pubkey > server_public.key 
wg genkey | tee peer1_private.key | wg pubkey > peer1_public.key 

Weitere VPN Client (Peer) Schlüssel generiert man dann nur noch mit wg genkey | tee peer2_private.key | wg pubkey > peer2_public.key usw.
Wie man den Schlüssel nennt ist beliebig. Eindeutige Bezeichnungen wie wg genkey | tee HerrMeier_private.key | wg pubkey > HerrMeier_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 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.
wgwinclneu
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.

Die simple Server/Client Konfigurationslogik ist dann vereinfacht dargestellt für den Server (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>


Analog dann für den Client (Initiator):

[Interface]
Address = <Interne_WG_Client_IP>
PrivateKey = <Privater_Key_Client>
[Peer]
PublicKey = <Öffentlicher_Key_Server>
Endpoint = <Server_IP_FQDN>: <UDP_Tunnelport>
AllowedIPs = <Interne_WG_Server_IP/32>
PersistentkeepAlive = 25


back-to-topServer Konfiguration Linux


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 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.

[Interface]
Address = 100.64.64.1/24
PrivateKey = AB1234P6j2O0PH1838gYnv5p5n27HVmVWJRjZr12345=
ListenPort = 51820

[Peer]
PublicKey = 4321Abc06YX3gA4P0sQzywNX8c1sHSeu+oqsrI84321=
AllowedIPs = 100.64.64.100/32, 192.168.188.0/24 

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).

back-to-topWireguard Server Autostart (Linux)
Den automatischen Start des Wireguard Servers beim Booten erledigt der Befehl:
systemctl enable wg-quick@wg0.service
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 !


back-to-top⚠️ Redirect versus Split Tunneling


Ein wichtiger Punkt der fast immer falsch gemacht wird und entsprechend beachtet werden sollte!
Allowed IPs 0.0.0.0/0 = 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 Clinets auf den VPN Tunnel umgeleitet.
Wenn dies aktiviert wird muss 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 auch systembedingten Traffic wie DNS (Namensauflösung), NTP (Uhrzeit) etc.

Redirect belastet den Tunnel prinzipbedingt performancetechnisch je nach Trafficvolumen deutlich mehr als das schlankere Split Tunneling Verfahren. Das sollte man immer beachten!
Leider ein Konfigurationsfehler der oft aus Routing Unkenntis gemacht wird wenn man lediglich nur relevanten Traffic für das remote Zielnetz ins VPN routen will.
Möchte man keinen Redirect und per Split Tunneling wirklich nur den relevanten Traffic für das remote LAN (oder die LANs) in den Tunnel routen, gibt man hier außer der Server IP mit einer /32er Maske nur noch das bzw. die jeweilige(n) remote(n) IP Netz(e) und Maske an. Summary Subnet Masken sind hier natürlich auch erlaubt um mehrere IP Netze bei intelligentem Subnetting mit einer Maske zu erfassen.
Mit Split Tunneling wird lediglich nur der Traffic für das remote LAN in den Tunnel gesendet. Lokaler Internet Traffic bleibt hier immer lokal und belastet den Tunnel nicht.
❗️Split Tunneling ist also performancetechnisch die deutlich bessere Wahl.

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 drum herum.

Welches dieser beiden Verfahren sinnvoll ist, ist deshalb immer vom Einsatzprofil des VPNs abhängig und muss jeder Netzwerk Admin immer im Einzelfall entscheiden.
In einer Redirect Konfig wird dann ausschliesslich nur 0.0.0.0/0 unter den "AllowedIPs" definiert, NICHT mehr!
⚠️ Es ist also immer entweder nur Split Tunnel oder nur Gateway Redirect erlaubt!
Eine Kombination beider Verfahren 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.

back-to-topServer Konfiguration Windows


back-to-topWindows Firewall
⚠️ 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 Windows Firewall erlauben.

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

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

wgcl4

back-to-topKonfiguration Wireguard Client


Die Client Konfig sieht dann völlig identisch 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 Hostnamen des VPN Servers sowie dessen UDP Port definiert.

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

[Interface]
Address = 100.64.64.101/24
PrivateKey = OMjSCv6e/iXECZwq0ZVL5Ywf/KzZvdsGpYKv1512345=
# DNS = 172.16.2.1

[Peer]
PublicKey = cA+mynt84tVH1gPaUN66E8K0nfzvpsQMohrEbz54321=
# Endpoint = X.Y.Z.H:51820 
Endpoint = router.myfritz.de:51820 
AllowedIPs = 100.64.64.1/32, 192.168.2.0/24
PersistentkeepAlive = 25 
⚠️ 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:

winwg1

back-to-topWireguard Client und DDNS Namen


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

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

back-to-topKonfiguration Smartphone Client


sp1

back-to-topWireguard Client Konfig mit QR Code an mobile Geräte exportieren


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

qrencode -t png -o qrbild.png -r wireguard.conf 
(-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.

qrencodeneu


back-to-topAVM Fritzbox Wireguard Konfigurationstücken und ihre Lösung


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


back-to-topWireguard VPN Verbindung checken


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.

C:\User\>ipconfig
Windows-IP-Konfiguration
Adapter wg-win10:

   Verbindungsspezifisches DNS-Suffix:
   IPv4-Adresse  . . . . . . . . . . : 100.64.64.101
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Standardgateway . . . . . . . . . :

Ethernet-Adapter Ethernet:

   Verbindungsspezifisches DNS-Suffix: lan
   IPv4-Adresse  . . . . . . . . . . : 192.168.40.147
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Standardgateway . . . . . . . . . : 192.168.40.1 

C:\User\>route print
IPv4-Routentabelle
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
          0.0.0.0          0.0.0.0      192.168.40.1    192.168.40.147     35
      100.64.64.0    255.255.255.0   Auf Verbindung     100.64.64.101    261
      100.64.64.1  255.255.255.255   Auf Verbindung     100.64.64.101      5
    100.64.64.101  255.255.255.255   Auf Verbindung     100.64.64.101    261
    100.64.64.255  255.255.255.255   Auf Verbindung     100.64.64.101    261
      192.168.40.0    255.255.255.0   Auf Verbindung     192.168.40.147    291
    192.168.40.147  255.255.255.255   Auf Verbindung     192.168.40.147    291
    192.168.40.255  255.255.255.255   Auf Verbindung     192.168.40.147    291
    192.168.188.0    255.255.255.0   Auf Verbindung     100.64.64.101      5
  192.168.188.255  255.255.255.255   Auf Verbindung     100.64.64.101    261
=========================================================================== 

Ping Check vom remoten Client via VPN auf den Router (FritzBox):
C:\User\>ping 192.168.188.1

Ping wird ausgeführt für 192.168.188.1 mit 32 Bytes Daten:
Antwort von 192.168.188.1: Bytes=32 Zeit=218ms TTL=63
Antwort von 192.168.188.1: Bytes=32 Zeit=9ms TTL=63
Antwort von 192.168.188.1: Bytes=32 Zeit=2ms TTL=63

Ping-Statistik für 192.168.188.1:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 2ms, Maximum = 218ms, Mittelwert = 78ms


back-to-topIst das auch wirklich sicher ?


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 vom remoten VPN Clients auf die FritzBox:

shark-wg

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


back-to-topBeispielsetup Wireguard Server auf OPNsense Firewall


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!)

back-to-topServer Setup

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!
opnswgsetup2.
⚠️ 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!).

back-to-topTunnel Interface Assignment

⚠️ 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!
addrassig
❗️(Im aktuellen OPNsense Release gibt es einen Fehler wenn man den Adresstyp auf "Static" setzt. Hier belässt man es dann beim Default "None"!)

back-to-topFirewall Regeln

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!)
rules

back-to-topClient Konfig zum OPNsense Server

Auch hier wieder die interne Tunnel Adresse mit einer /32er Hostmaske!
192.168.2.0 /24 ist das lokale LAN an der OPNsense Firewall.
[Interface]
Address = 100.64.65.30/27
PrivateKey = SLxmZLKxKUh0uiqWU+epIA8Ca263uTv5QYJGtdjE123=

[Peer]
PublicKey = 3Dbuc2uigSRVdjAFh1HEJvI/e530MbeQOQUGOMbCYFg=
Endpoint = 80.1.10.98:57821
AllowedIPs = 100.64.65.1/32, 192.168.2.0/24
PersistentkeepAlive = 25 

back-to-topIPv6 Client Konfig zum OPNsense Server für DS-Lite Anschlüsse

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.
[Interface]
Address = 100.64.65.30/27
PrivateKey = SLxmZLKxKUh0uiqWU+epIA8Ca263uTv5QYJGtdjE123=

[Peer]
PublicKey = 3Dbuc2uigSRVdjAFh1HEJvI/e530MbeQOQUGOMbCYFg=
Endpoint = 2001:cc:724:2580:20d:b9ff:fe5a:49e9:57821
AllowedIPs = 100.64.65.1/32, 192.168.2.0/24
PersistentkeepAlive = 25 

back-to-topPeer und Ping Check

root@client-1:# wg show
interface: wg0
  public key: qCrmg226byI0w9x63hi5Oo17KFU68oQo211n9S3MUwU=
  private key: (hidden)
  listening port: 54733

peer: 3Dbuc2uigSRVdjAFh1HEJvI/e530MbeQOQUGOMbCYFg=
  endpoint: 80.1.10.98:57821
  allowed ips: 100.64.65.1/32, 192.168.2.0/24
  latest handshake: 14 seconds ago
  transfer: 4.14 KiB received, 9.89 KiB sent
  persistent keepalive: every 25 seconds

root@client-1:# ping -c 3 192.168.2.1
PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=1.19 ms
64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=1.31 ms
64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=1.56 ms

--- 192.168.2.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 1.185/1.351/1.556/0.153 ms 

back-to-topStatus Check OPNsense

opnstatus


back-to-topDynamisches Routing mit BGP, OSPF o. RIPv2 über Wireguard


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.

back-to-topKonfig Dateien

Die entsprechenden Konfig Dateien sehen so aus:
zebra.conf
hostname router
password admin
enable password admin
log file /var/log/quagga.log
log stdout
!
interface eth0
!
interface wg0
!
interface wlan0
 shutdown
!
ip forwarding
!
line vty 
ospfd.conf
hostname router
password admin
enable password admin
log file /var/log/quagga.log
!
interface eth0
!
interface wg0
 ip ospf network point-to-multipoint
 ip ospf mtu-ignore
!
interface wlan0
!
router ospf
 log-adjacency-changes
 auto-cost reference-bandwidth 10000
 passive-interface default
 no passive-interface eth0
 no passive-interface wg0
 network 100.64.64.0/24 area 0.0.0.0
 network 192.168.188.0/24 area 0.0.0.0
!
line vty 
wg0.conf
[Interface]
Address = 100.64.64.1/24
PrivateKey = 2GIsoO70....
ListenPort = 51820

[Peer]
# OSPF RasPi
PublicKey = 4ES9Aen....
AllowedIPs = 100.64.64.100/32, 224.0.0.5/32, 224.0.0.6/32, 192.168.40.0/24

[Peer]
PublicKey = HVanaU....
AllowedIPs = 100.64.64.101/32, 192.168.8.0/24 
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.


back-to-topWeiterführende Links


Wireguard Download:
https://www.wireguard.com/install/

Wireguard Client für Windows Standardbenutzer einrichten:
https://www.heise.de/ratgeber/Windows-WireGuard-VPN-fuer-Standardbenutze ...

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

Wireguard Performance Vergleich:
https://www.wireguard.com/performance/


back-to-topWireguard mit Fritzbox


Fritzbox Wireguard VPN auf Mikrotik, pfSense/OPNsense, Linux und andere Wireguard Router:
S2S-Wireguard: AVM zu Mikrotik
AVM Besonderheiten:
Wireguard Lan to Lan Fritzbox Raspberry Pi
https://www.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
OPNsense mehrere Wireguard Interfaces mit Split-Tunnel
OPNsense mehrere Wireguard Interfaces mit Split-Tunnel


back-to-topWireguard mit Mikrotik und OPNsense/pfSense


Wireguard LAN zu LAN VPN mit pfSense / OPNsense und Mikrotik:
Wireguard VPN pfSense auf Mikrotik

BGP Routing über einen Wireguard Tunnel :
Wireguard BGP Routing

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


back-to-topPraxisbeispiele


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 zuhause in pfsense via WireGuard Tunnel
Feste IPs zuhause in pfsense via GRE Tunnel
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)

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


back-to-topAlternative VPN Protokolle:


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":
Merkzettel: VPN Installation mit OpenVPN

L2TP VPN Server mit onboard VPN Clients auf pfSense/OPNsense Firewall:
PfSense VPN mit L2TP (IPsec) Protokoll für mobile Nutzer

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:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten

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

Preiswerte Wireguard und OpenVPN Router Hardware:
https://www.amazon.de/GL-iNet-GL-MT300N-V2-Repeater-Performance-Compatib ...

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

Content-Key: 660620

Url: https://administrator.de/contentid/660620

Ausgedruckt am: 28.03.2024 um 20:03 Uhr

Mitglied: brammer
brammer 11.03.2021 um 14:05:24 Uhr
Goto Top
Hallo,

wer es damit nicht hinbekommt ist, dem ist nicht mehr zu helfen!

brammer
Mitglied: aqui
aqui 11.03.2021 um 14:08:28 Uhr
Goto Top
Hoffentlich ! 🙂
Smartphone Client fehlt noch und wird nachgereicht....
Mitglied: pasu69
pasu69 11.03.2021 um 14:15:03 Uhr
Goto Top
Wenn man zum Beispiel einen Raspi nutzt, kann man den Wireguard Server recht einfach
mit PIVPN (https://www.pivpn.io/) einrichten - inkl. einfacher Generierung eines QR Codes,
den man mit der Wireguard App einfach abfotografieren kann.
Mitglied: Visucius
Visucius 11.03.2021 aktualisiert um 15:24:31 Uhr
Goto Top
Cool, Danke für die Übersicht @aqui. Bin noch am überprüfen meiner Setups um sicherzustellen, dass ich nix übersehen habe face-wink

a) Ein kleiner Vertipperer: Bei der ersten Zeichnung, der “WG-Server” hat die .254 ... das Forwarding im Router läuft aber auf die .50.

b) Hier im Forum wird immer auf VPN OHNE NAT Wert gelegt, alleine schon wegen der Leistung. So wie ich das interpretiere “nattest” Du aber doch hier auch mit dem 100er-IP-Netz?! Oder habe ich das Problem nicht richtig verortet?!

c) Beim Routing hast Du auch eine feste Router 192.168.0.0 ... in die VPN reingeleitet ... ist das gewollt?

d) Evtl. ließe sich diese Anleitung um die Option: “Site2Site” ergänzen. Ich z.B. habe/hatte da Probleme beim Routing.
Mitglied: aqui
aqui 12.03.2021 aktualisiert um 11:12:50 Uhr
Goto Top
Hi Visucius,
a.)
ist korrigiert ! Danke fürs Aufpassen ! face-wink
b.)
Du hast Recht. Das Tutorial geht aber auf dieses nicht optimale VPN Design in der Eingangbeschreibung ein und propagiert generell immer eine direkte VPN Server Installation in der Peripherie auf Router oder Firewall und eher nicht im lokalen LAN. Viele haben aber nicht diese Möglichkeit und deshalb geht das Tutorial mal von klassischen Heimnetz Ansatz aus. Ist ja immer ein Kompromiss den man machen muss bei Anleitungen die mehr oder minder allgemeingültig und für eine breite Masse verständlich sein sollen.
c.)
Jein. Für eine reine Client Anbindung ist das natürlich nicht zwingend nötig. Da hast du Recht. Es zielt vorab schon auf ein optionales Site-to-Site VPN. Auch wieder ein Kompromiss
d.)
Kommt... Ggf. auch noch mit dynamischem Routing (RIPv2, OSPF etc.)
Mitglied: Visucius
Visucius 12.03.2021 aktualisiert um 11:11:33 Uhr
Goto Top
b) Ah ok, “natten” heißt also in dem Fall, die “hinter dem Router” installierte VPN-Appliance. Ehrlich gesagt habe ich - im Wireguard-Umfeld - bisher nur solche Setups und Anleitungen erlebt (Synology, Raspi, Virtualisierungen, ...). Weil ja noch recht neu.

Ich vermutete bisher, mit “natten” im VPN-Umfeld sei die “Notwendigkeit” des (eigenen) VPN-internen IP-Bereichs, in Deinem Beispiel der 100.64... gemeint, die man sich irgendwie bei anderen VPNs ersparen könnte. face-wink

c) und d) Da bin ich dann mal gespannt face-wink

Viele Grüße und einen guten Start ins WE an alle Forenteilnehmer!
Mitglied: aqui
aqui 12.03.2021 aktualisiert um 11:17:59 Uhr
Goto Top
Ja, du hast Recht. Im eigenen internen Netzwerk NATet man natürlich nicht, das ist immer Quatsch und schafft Probleme.
Es gilt nur für die "Schlauen" die öffentliche VPN Provider nutzen um ausländische Audio oder Video Inhalte im Internet zu konsumieren und so eine andere GeoIP als Absende IP nutzen um Inhaltefilter zu umgehen. Nur für solchen Usinn benötigt man ein NAT im VPN Tunnel. Niemals aber für ein eigenes VPN.
Mitglied: IceAge
IceAge 12.03.2021 aktualisiert um 14:29:06 Uhr
Goto Top
Vielen Dank für das tolle Tutorial. Unter OpenVPN lasse ich mich bei jedem Verbindungsaufbau eines Clients per Bash-Skript informieren. Besteht bei wireguard auch die Möglichkeit externe Skript bei einem Verbindungsaufbau bzw. abbau auszulösen?

Grüße I.
Mitglied: aqui
aqui 12.03.2021 aktualisiert um 18:31:37 Uhr
Goto Top
Ja, du kannst in der wg0 Konfig Datei mit PostUp und PostDown solche Scripte starten. Hier siehst du das mal am Beispiel von iptables:
https://wiki.alpinelinux.org/wiki/Configure_a_Wireguard_interface_(wg)
Mitglied: IceAge
IceAge 12.03.2021 um 20:35:52 Uhr
Goto Top
perfekt, danke dir.
Mitglied: danber
danber 31.03.2021 um 10:26:41 Uhr
Goto Top
Hallo,
vielen Dank für die tolle Anleitung. Gibt's sowas auch für IPv6? Ich leide unter cgnat 😉
Mitglied: aqui
aqui 31.03.2021 aktualisiert um 11:39:07 Uhr
Goto Top
Ja, natürlich, das klappt auch für IPv6. Du musst dann nur die v4 Adressen durch v6 Adressen ersetzen bzw. hinzufügen.
Wireguard IPv6 im Tunnel verwenden - Verbindung klappt aber keine Daten
https://meet-unix.org/2019-03-21-wireguard-vpn-server.html
Mitglied: danber
danber 31.03.2021 um 12:55:26 Uhr
Goto Top
Vielen Dank, ich werde es mal probieren. Ich hab mich bisher noch nicht mit IPv6 beschäftigt.
Mitglied: aqui
aqui 31.03.2021 um 13:42:37 Uhr
Goto Top
Dann hilft eine sehr gute und kostenfreie IPv6 Praxis Lektüre um da schnell reinzukommen: face-wink
https://danrl.com/ipv6/
Mitglied: Ghosti85
Ghosti85 11.07.2021 um 12:27:11 Uhr
Goto Top
Grüße euch alle!

Ist immer sehr interessant zu lesen von leuten die sich auskennen.
Leider ist hier mein Latein am Ende oder meine grauen Zellen schon abgestorben^^
und hoffe das sich jemand kurz die Zeit nehmen kann mir ein wenig zu helfen?

Was bedeutet Nat'en im Tunnel, was bewirkt es und wofür wird es den überhaupt verwendet?
DIe etlichen Beispiele die ich mir bisher angesehen habe (die ich auch so umgesetzt habe) beinhaltet auf der Server bzw. wg0.conf immer folgenden Part:

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

aber... wie müsste den der Befehl überhaupt abgesetzt werden um nicht zu Natten?

Entschudligt bitte jetzt schon die doofen fragen, aber das Projekt überschreitet ein großes Stück mein wissen..
Um euch gedanklich abzuholen....

Primär hatte ich nach einer Lösung gesucht um zwei Standorte zu vernetzen.
Anfangs machte ich das auch über Zwei Fritzboxen die aber schlicht überfordert waren mit der Datenmenge und Performance.
Hier hatte ich mir auch versucht Professionelle hilfe zu suchen und auch wirklich gegen bezahlung eine Lösung herbei zu schaffen.
Leider ohne Erfolg (kein Scherz die Kohle von mir stinkt wohl oder so..) ... Sprich ich musste das trotz enormen Zeitmangel selbst hinbekommen. Hierzu hatte ich mir zwei RaspPi4 geholt und nach diversen Tutorials auch umgesetzt.
Stand heute ist... Das zusammenschließen der beiden Netze funktioniert endlich was leider etwas mit stolper fallen war da die Tutorials nicht 1:1 immer geklappt hatten (Gab Probleme mit dem DYNDNS Service von My Fritz..).
Jetzt frage ich mich eben wie oben beschrieben was es mit dem Natten auf sich hat.
Das nächste Problem das ich habe ist das die Site to Site steht und auch echt klasse ist
aber ich es nicht gebacken bekomme einen Client hinzuzufügen obwohl alles scheinbar richtig konfiguriert ist (da werde ich demnächst mal einen Eintrag hier im Forum erstellen).

Hoffentlich kann sich hier jemand kurz die Zeit nehmen bezüglich Nat.
Danke euch allen schon mal und wünsche euch einen schönen Sonntag.
Mitglied: aqui
aqui 11.07.2021 um 14:33:01 Uhr
Goto Top
Was bedeutet Nat'en im Tunnel,
Auf dem Tunnel Interface (wg0) wird ein IP Adress Translation gemacht. Was das genau ist kannst du HIER nachlesen. Es ist das was an jedem stinknormalen Internet Router passiert, das im Internet nicht routebare private_IP_Netze auf die öffentliche IP Adresse des Routers umgesetzt werden als Absender IP. Damit "denkt" dann das Internet das dieser Traffic von einer öffentlichen IP kommt und kann es so weltweit routen und bei Antwort auch wieder auf die Ursprungs IP Adresse rückübersetzen. Simple NAT Grundlagen... face-wink
und wofür wird es den überhaupt verwendet?
Eigentlich für gar nix und es ist sinnfrei und kontraproduktiv es zu aktivieren denn es verhindert das bidirektionale Routing in den VPN Netzen und kosttet sinnlos Performance.
Es wird eigentlich nur bei den unwissenden Nutzern gemacht die sich in die Fänge öffentlicher VPN Provider begeben um Geolocation Blockings usw. zu überwinden oder illegale Audio- oder Video Daten konsumieren. So einen traurigen Fall zeigt dieser_Thread.
Ansonsten ist es sinnfrei und sollte man nie machen.
überschreitet ein großes Stück mein wissen..Um euch gedanklich abzuholen....
Ist aber nur einfaches Allgemeinniveau in einem Administrator Forum. face-wink
Zwei Fritzboxen die aber schlicht überfordert waren mit der Datenmenge und Performance.
Die schlechte VPN Performance der FBs ist allgemein bekannt. Ist ja auch nicht eines ihrer Primär Features als einfache Consumer Box !
aber... wie müsste den der Befehl überhaupt abgesetzt werden um nicht zu Natten?
Das ist kinderleicht: Ihn schlicht und einfach weglassen und NICHT konfigurieren ! face-wink
Hierzu hatte ich mir zwei RaspPi4 geholt und nach diversen Tutorials auch umgesetzt.
Da bist du ja schonmal auf dem absolut richtigen Weg !
Im Grunde ist auch das kinderleicht denn es reicht nach dem Booten des Raspberry Pi Lite Images einfach:
  • apt update und apt full-upgrade
  • Danach ein apt install wireguard
  • Schlüssel erzeugen und Wireguard entsprechend der Anleitung oben einrichten
  • Statische Routen und vor allem Port Forwarding im Internet Router (FritzBox etc.) gem. obiger Anleitung einrichten.
  • Fertisch
Das sollte auch ein blutiger Laie nur mit Abtippen problemlos hinbekommen. face-wink
Gab Probleme mit dem DYNDNS Service von My Fritz..
Dafür kann das Tutorial aber nix. Jedenfalls nicht das hiesige Tutorial.
Jetzt frage ich mich eben wie oben beschrieben was es mit dem Natten auf sich hat.
Gar nichts. Es ist schlicht und einfach Unsinn in eigenen privaten Netzen und sollte in keinem Falle konfiguriert werden weill es eine Routing Einbahnstrasse zwischen den VPN Netzen schafft.
aber ich es nicht gebacken bekomme einen Client hinzuzufügen
Einfach ein neues Key Pärchen für den Client erzeugen und den Peer am Server eintragen..fertisch. Eine Sache von max. 5 Minuten.
da werde ich demnächst mal einen Eintrag hier im Forum erstellen
Nur zu denn das hilft sicher auch anderen. Außerdem hilft es das Tutorial hier nicht mit Basisdiskussionen aufzublähen und das auf einen dedizierten Thread zu lenken.
Hoffentlich kann sich hier jemand kurz die Zeit nehmen bezüglich Nat.
Aber immer doch... 😉
und wünsche euch einen schönen Sonntag.
Ebenso !
Mitglied: fnbalu
fnbalu 02.08.2021 um 16:38:23 Uhr
Goto Top
Mahlzeit,
aufgrund der Deutschen Glasfaser CG-Nat Problematik habe ich mir mittlerweile einen VPS zugelegt und dort wie zu Hause pfSense 2.5.2 installiert.

Der VPS hat seine statische IPv4 als WAN Adresse und ich habe von meiner pfSense zu Hause ein Wireguard VPN dorthin aufgebaut.
Das VPN besteht auch soweit und ich kann jeweils die andere Tunnelgegenstelle pingen. Sprich die Routen/Gateways etc funktionieren.

VPS pfSense
IPv4 111.222.333.444
Tunnel IP 10.0.0.1
Erlaubte Gegenstelle 192.168.1.0/24; 10.0.0.0/24

private pfSense
Tunnel IP 10.0.0.2
Erlaubte Gegenstelle 0.0.0.0/24; 10.0.0.0/24 (aktuell doppelt gemoppelt)


Ich möchte nicht von innen nach außen, aber ich möchte Ports durchreichen wie früher.

Gedachte habe ich es mir wie früher. IP:Port.
In dem Fall ein Beispiel 111.222.333.444:55555 das soll dann direkt über den Tunnel geschickt werden und dann 192.168.1.50:80 zugewiesen werden.
Das ist jetzt beispielhaft. Versucht habe ich es bisher nur auf die pfSense selbst mit Port 443 da die Clients noch nicht über die neue Hardware laufen solange ich keinen Erfolg habe.

Wireguard hat Beidseitig ein Scheunentor vorerst. Any Any Any

Nun habe ich beim VPS mich an NAT versucht.
Source * Port * Destination "Tunnel Adress" Port 55555
Das blockt er dann zumindest schonmal nicht in der Firewall.

Aber es kommt nicht drüben an.
Was und wie viele Regeln muss man denn erstellen, damit der Traffic rüber geht? Oder gehört da noch was an Routen zusätzlich dazu?
Wie gesagt ich kann gegenseitig die 10.0.0.X pingen
Mitglied: aqui
aqui 02.08.2021 um 21:37:14 Uhr
Goto Top
Das grundlegende HowTo zu dem Thema hast du gelese .
Zwei Mobilfunkrouter (TP-Link MR200) per VPN verbinden, ev. per externen VPN-Gateway (VPS-Server)
Das was dort steht giltanalog auch für Wireguard.
Mitglied: fnbalu
fnbalu 04.08.2021 aktualisiert um 18:49:20 Uhr
Goto Top
Sodele, ich habe mir das auch genau angesehen und weiter getestet.

Da das die noch nicht produltive pfSense ist, habe ich testweise mal einen Shelly als Client eingehängt und die pfSense als Router definiert (vereinfacht gesagt). Der Shelly hat die 192.168.1.45 und lauscht auf Port 80

Nun kann ich von der entfernten pfSense die 192.168.1.45 pingen.
Ich gehe also mal davon aus, dass der Tunnel soweit steht.


Ziel soll jetzt ja sein den Port 80 über die IP des VPS zu erreichen.

Der VPS hat eine NIC. Dieser habe ich statisch die IPv4/22 zugewiesen und den Gateway eingetragen. Bei IPv6 analog.
Das Wireguard Interface hat die 10.0.0.1 zugewiesen. Routen und Gateways sind eingetragen, sonst würde denke ich auch der Ping nicht gehen.


Nach meinem Geschmack könnte ich mit NAT arbeiten um nur spezielle Ports rüber zu lassen.
Die VPS-pfSense soll also Port 80 über WAN annehmen und über den Tunnel schicken. (80 erstmal testweise)

nat
So ist gerade die Regel dazu

fwlog
Das schmeißt das LOG dazu.

Testen tue ich mit meinem Server der versucht die IPv4 des VPS anzusprechen. Der Server hängt noch an der alten pfSense, die auch die Telekom Leitung nutzt.

Die Gegenstelle vom VPS ist wie schon erwähnt die neue pfSense welche Deutsche Glasfaser nutzt. Aufgebaut wird der Tunnel von mir zum VPS wegen DG-Nat


Habe ich da einen Denkfehler?


Edit: Sobald ich einseitig den WireguardVPN stoppe und wieder starte, geht anschließend der Ping nicht.
Mitglied: 148656
148656 04.08.2021 um 16:57:19 Uhr
Goto Top
Wäre es möglich, dein Problem in einem eigenen Beitrag zu diskutieren?
Mitglied: 90948
90948 03.10.2021 aktualisiert um 15:32:11 Uhr
Goto Top
Hi,

erstmal super Anleitung für Wireguard!

falls es hilfreich ist bei dem Wireguard Client für Windows ist seit der Version 0.3.1 auch möglich ohne Administrationsrechte die GUI zu verwenden. Dazu müssen zwei Bedingungen am Client eingestellt werden:

  • Der Benutzer muss in der lokalen Computergruppe "Netzwerkkonfigurations-Operatoren" sein
  • Es muss ein neuer Schlüssel angelegt werden
HKLM\Software\WireGuard\
  • Unter diesem Schlüssel muss ein ein neuer Wert vom Typ DWORD mit dem Namen "LimitedOperatorUI" und dem Wert "1" angelegt werden

Gruß
Mitglied: danielgm
danielgm 29.07.2023 um 23:45:59 Uhr
Goto Top
Hallo zusammen, ich habe einen Hetzner WireGuard Server aufgesetzt. Die Verbindung ist aktiv, jedoch bekomme ich keine Remote-Desktop-Verbindung.

Ich nutze das interne Netzwerk von Hetzner.

Dort habe ich einen zweiten Windows Server 2019. Komplett konfiguriert für das interne Netzwerk.

Ohne WireGuard mit kurzfristig unbeschränkter öffentlicher IP kann ich eine RDV aufbauen.

Bitte meldet euch, wenn ihr mir helfen könntet.

LG
Daniel
Mitglied: aqui
aqui 30.07.2023 um 10:21:01 Uhr
Goto Top
Läuft auf dem Server noch eine Firewall iptables oder nftables? Wenn du sagst das der Tunnel aufgebaut wird kannst du dann vom Client das interne Wireguard Server Interface pingen? Oder den Server über das interne WG Interface per SSH ansprechen?
Ist das der Fall aber du kannst andere Interfaces nicht pingen, hast du vermutlich vergessen das IPv4 Forwarding (Routing) auf dem Server zu aktivieren sofern du eine Firewall ausschliessen kannst.
Wenn dein Server OS Linux ist dann musst du die /etc/sysctl.conf editieren und dort die Zeile net.ipv4.ip_forward=1 entkommentieren und den Server neu booten. Bei Windows ist es ein Registry Eintrag s.o.
Hilfreich wäre, wie immer, deine WG Konfig von Server und Client und ein wg show (Linux).

Eine Bitte:
Eröffne einen neuen, separaten Thread für das Thema mit einem hiesigen Verweis auf den Link um das Tutorial hier nicht unnötig mit langen Troubleshooting Threads zu belasten und unübersichtlich werden zu lassen! Danke!
Mitglied: servusli1
servusli1 20.08.2023 um 19:55:04 Uhr
Goto Top
Hallo zusammen

Ich habe nach dieser Anleitung von @aqui WireGuard erfolgreich auf meiner opnsense mit mehreren Clients eingerichtet. Funktioniert soweit tadellos.

In der WireGuard-Interface Firewall Rule habe ich folgende Regel erstellt:

Protokol: IPv4 UDP
Source: 10.11.0.0./24
Port: Any
Destination: DNS Net (VLAN in welchem sich meine PiHole's befinden)
Port: 53 (DNS)


Mit dieser Regel sollte der Traffic über die PiHole's geleitet werden, was auch soweit zu funktionieren scheint. Ich habe keinerlei Werbung wenn ich unterwegs surfe.

Soweit so gut. Mit meiner Konfiguration habe ich jedoch Zugriff auf das ganze Netzwerk, auf jedes VLAN etc.

Ich will nun einen zweiten Tunnel erstellen mit weniger Zugriff. Ziel ist es, dass die Clients nur noch auf die DNS-Server (PiHole) zugreifen aber nicht mehr in andere VLANs können.
Ich möchte ein "MASTER-VPN"- für den Zugriff sollte es ein Problem geben und ein "Client-VPN"-Tunnel.
Muss ich hierzu eine entsprechende Rule erstellen oder muss ich da grundlegende Einstellungen anders konfigurieren?

Ich benötige keine Anleitung auf dem Silbertablett serviert aber über einen kleinen Input was ich in etwa machen muss wäre ich dankbar.
Mitglied: aqui
aqui 20.08.2023 um 20:09:31 Uhr
Goto Top
Du hast aber einen Fehler gemacht, denn DNS nutzt bekanntlich TCP und UDP. Das solltest du unbedingt ändern, ansonsten bekommst du Probleme mit DNS!
https://de.wikipedia.org/wiki/Domain_Name_System
Mit meiner Konfiguration habe ich jedoch Zugriff auf das ganze Netzwerk, auf jedes VLAN etc.
Das ist mit der o.a. Regel unmöglich, denn diese lässt ja einzig und allein nur UDP 53 im Tunnel passieren. In deinem VPN dürfte nichts anderes als DNS laufen.
Um IP Traffic im VPN zu regeln hast du 2 Optionen:
  • Traffic anhand der AllowedIPs steuern für die Zielnetze
  • Entsprechende Filterregeln im Tunnel Interface wenn man alles passieren lässt.
Du solltest sinnvollerweise nur eins von beiden verwenden und besser nicht kombinieren um sich nicht zu verzetteln.
Ein 2ter Tunnel wäre überflüssig.
Mitglied: servusli1
servusli1 21.08.2023 um 12:25:39 Uhr
Goto Top
Danke @aqui. Habe die Rukes auf TCP/UDP geändert.

Ich habe opnsense auf einer Sophos XG105 Rev. 3 installiert und es laufen mehrere VLAN inkl. DHCP-Server darauf.
Ist es möglich, dass opnsense insgesamt langsamer läuft wenn mehrere VLAN laufen?
Mitglied: aqui
aqui 21.08.2023 aktualisiert um 12:48:30 Uhr
Goto Top
Nein, sollte eigentlich nicht wenn entspr. potente Netzwerkkarten und CPU in der Hardware sind.
Möglich aber das du die entsprechenden NIC Settings fürs HW Offloading falsch gesetzt hast?!
Das wäre aber ein Thema eines separaten Threads und gehört hier nicht zur Thematik Wireguard Tutorial.
https://teklager.se/en/knowledge-base/opnsense-performance-optimization/
https://binaryimpulse.com/2022/11/opnsense-performance-tuning-for-multi- ...
https://docs.opnsense.org/troubleshooting/performance.html