Merkzettel: VPN Installation mit Wireguard

Inhaltsverzeichnis
Einleitung
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.
Punkte zum VPN Design:
Netzwerk Admins erkennen das das hier vorgestellte VPN Design mit dem Betrieb des VPN Servers im internen LAN aus Sicherheits Aspekten nicht ideal ist. Der Grund ist, das man von außen ungeschützten (VPN) Traffic ins interne, geschützte LAN lassen muss über die Router Firewall.
Ein Sicherheits Nachteil der 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 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" 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 und einfachen Netzwerken sind diese VPN fähigen Router oder Firewalls aber oft nicht vorhanden oder es fehlt entsprechendes KnowHow vorhandene Hardware zu ersetzen o. a. Gründe.
Das Tutorial versucht mit den folgenden Installations Tips einen Spagat zwischen beiden Optionen. Grundlage ist wieder, wie schon vom hiesigen OpenVPN_"Merkzettel" bekannt, ein VPN Standard Design:
Oder als Site to Site Installation:
Internet Router Einstellungen sind auch hier wieder, stellvertretend für andere Router Hardware, anhand einer FritzBox beschrieben. Solche billigen Consumer Router haben in Firmennetzen mit VPN Installationen generell nichts zu suchen. Hier sollte immer bessere Hardware gewählt werden.
Dennoch gelten die anschaulichen Setups der AVM Router 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 das interne Wireguard Netzwerk mit 100.64.64.0 /24. Der 100.64.0.0 /10 Adress Block wird im Internet nicht geroutet (RFC6598) und sorgt dafür das es nicht zu einer IP Adress Überschneidung mit privaten RFC 1918 IP Adressen kommt. Er ist nicht zwingend und es können auch RFC 1918 IP Adressen verwendet werden wenn sie entsprechend vorausschauend geplant werden. Siehe dazu auch hier.
Noch etwas zum Tunnel NAT/Masquerading am Server (IP Adress Translation im VPN Tunnel):
Im eigenen, internen LAN ist so etwas 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 Geo Location Grenzen (Streaming usw.) zu überwinden wo dies dann erforderlich ist. So ein Design führt in einem privaten Standort oder Client VPN wie hier immer zur Fehlfunktion. Sie zahlreichen Foren Threads dazu belegen dies...
Es gilt also bei privaten VPNs: KEIN NAT/Masquerading am Tunnelinterface aktivieren (iptables) !!
Ein NAT/Maquerading im Tunnel kann dennoch in einigen Designs sinnvoll sein. Z.B. ein Firmen VPN wo Clients immer nur zentral auf einen Server arbeiten. Hier ist bidirektionales Routing nicht erforderlich und aus Security Sicht kann das dann von Vorteil sein. Final also immer eine Frage der Security Policy.
Wichtige Tipps zur VPN Adressierung findet man HIER !
Los gehts...!
Einstellungen 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.
IP Adressierung des Wireguard Servers
Da in dem obigen Design, mit internem VPN Server, eine feste, statische IP Route im vorhandenen Internet Router auf die lokale Wireguard Server IP Adresse zeigt, ist es sinnvoller dem VPN 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 die Route ins Leere und das VPN verliert die Verbindung. Etwas, das es zu vermeiden gilt !
Es ist also immer eine gute Idee dem VPN Server eine statische IP Adresse zu vergeben. Er ist gewissermaßen VPN Router und Router bekommen Prinzip bedingt generell statische IP Adressen an ihren Interfaces.
Das kann natürlich manuell am Server selbst im Netzwerk Setup gemacht werden. Einfacher ist es aber über die Hardware MAC Adresse der verwendeten Server Hardware (Netzwerkkarte), dem DHCP Server im Router (z.B. Fritz Box) 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 Zuweisung dennoch immer eine feste IP Adresse.
Das Screenshot Beispiel zeigt dies 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 !
Interne Wireguard IP Adressierung
Der VPN Tunnel selber ist im 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 Konfigrations 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 privaten_RFC1918_IP_Adressen zu vermeiden die millionenfach auf Consumer Routern überall gleich verwendet werden. Wie eine vorausschauende VPN Adressierung auszusehen hat wurde schon in anderen VPN Tutorials des Forums hinreichend beschrieben wie z.B. HIER.
Port Forwarding oder auch Port Weiterleitung bzw. Freigabe im Router
Damit VPN Clients von außen den 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 erkennt man auch sofort den oben schon angesprochenen Nachteil einer solchen internen VPN Lösung !
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 das VPN Konzept wäre in sich sicherer.
Statische 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.
(siehe dazu auch Netzwerk Skizze oben).
Wireguard 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.
IP Forwarding (Routing) im Wireguard Server aktivieren
Der Wireguard VPN Server ist aus IP Sicht auch 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 aber das Routing (IP Forwarding) auf Servern, egal mit welchem Betriebssystem, immer per Default deaktiviert !
Damit der Server nun IP Pakete vom lokalen LAN ins VPN IP Netz und umgekehrt überhaupt senden 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/
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.
Konfiguration 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.
Unter Windows klickt man "Einen leeren Tunnel hinzufügen" was dann das entsprechende Schlüsselpaar generiert und komplettiert dann das Setup im Textfeld.

Server 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.
[Interface]
Address = 100.64.64.1/24
PrivateKey = AB1234P6j2O0PH1838gYnv5p5n27HVmVWJRjZr12345=
ListenPort = 51820
[Peer]
PublicKey = 4321Abc06YX3gA4P0sQzywNX8c1sHSeu+oqsrI84321=
AllowedIPs = 100.64.64.100/32, 192.168.40.0/24
Mit wg-quick up wg0 startet man den Wireguard Server. Entsprechend stoppt wg-quick down wg0 ihn. Macht man Änderungen an der Konfig muss anschliessend auch der Wireguard Server mit systemctl restart wg-quick@wg0.service neu gestartet werden !
Ob der Tunnel aufgebaut wurde überprüft man mit wg show (unixoide OS).
Redirect versus Split Tunneling
Allowed IPs 0.0.0.0/0 = Schickt statt nur den Traffic des remoten lokalen LANs den gesamten Client Traffic in den VPN Tunnel ! Wenn dies aktiviert wird muss kein weiteres IP Netz mehr definiert werden! Warum auch, denn 0.0.0.0 bedeutet "route ALLEN Client Traffic in den Tunnel".Redirect belastet den Tunnel prinzipbedingt performancetechnisch je nach Trafficvolumen deutlich mehr als das schlankere Split Tunneling Verfahren. Ein Konfigfehler der oft aus Routing Unkenntiss gemacht wird wenn man nur relevanten Traffic ins VPN routen will.
Möchte man keinen Redirect und per Split Tunneling nur den relevanten Traffic für das remote LAN in den Tunnel routen, gibt man hier außer der Server IP mit einer /32er Maske noch das jeweilige remote IP Netz und Maske an. Summary Masken sind hier auch erlaubt.
Es geht entweder nur Split Tunnel oder Gateway Redirect! Eine Kombination beider Verfahren ist nicht möglich und routingtechnisch auch unsinnig, da ein Gateway Redirect, wie der Name schon sagt, sämtlichen Traffic routet.
Server Konfiguration Windows
Entsprechend sieht die Server Konfig dann im Windows Setup aus:
Hier startet man den Wireguard Server mit einem Klick auf "Aktivieren".
Konfiguration 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 dies bei einer Installation des VPN Servers im lokalen Netz immer der DynDNS Hostname des Routers oder dessen öffentliche IP Adresse ist. Nur diese ist aus dem Internet ansprechbar und leitet ja, wie oben bereits beschrieben, diesen VPN Verkehr per Port Forwarding 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 in der Peripherie auf Router oder Firewall direkt, entfällt das natürlich und man gibt dort dann direkt deren öffentliche IP an.
[Interface]
Address = 100.64.64.101/24
PrivateKey = OMjSCv6e/iXECZwq0ZVL5Ywf/KzZvdsGpYKv1512345=
# DNS = 172.16.7.254
[Peer]
PublicKey = cA+mynt84tVH1gPaUN66E8K0nfzvpsQMohrEbz54321=
# Endpoint = X.Y.Z.H:51820
Endpoint = router.myfritz.de:51820
AllowedIPs = 100.64.64.1/32, 192.168.188.0/24
# PersistentkeepAlive = 25
Entsprechend sieht die Konfig dann wieder im Windows Setup aus:
Konfiguration Smartphone Client
Wireguard 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:
cat /etc/wireguard/peer1.conf | qrencode -t ansiutf8
einen Wireguard Client QR Code den man dann einfach durch Abfotografieren mit der Kamera in Smartphone oder Tablet importiert.
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
Ist 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:
Wie man im Screenshot zweifelsfrei sieht, lassen sich aus den Daten keinerlei Rückschlüsse ziehen welche Daten über den VPN Tunnel übertragen werden.
Dynamisches OSPF o. RIPv2 Routing mit Wireguard
Ein interessanter Aspekt ist WireGuard mit dynamischem Routing wie 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.
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.
Konfig 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
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
[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
Eine OSPF Praxislösung mit Mikrotik Routern findet man HIER
Router oder Firewall als Wireguard Server
Viele handelsübliche Router oder Firewalls bieten heute ein onboard Wireguard VPN. Offene Router Betriebssysteme wie OpenWRT gehören natürlich dazu. Als Auszug seien hier 2 Beispiele genannt:
pfSense oder OPNsense Firewall:
Achtung ! beim pfSense Package und dem Erstellen von automatischen Routen. Siehe dazu HIER !!
GL.inet Routermodelle:
Weiterführende Links
Praxisbeispiel mit Standort Vernetzung und mobilen Clients:
https://administrator.de/forum/wireguard-site2site-mit-roadwarrior-31334 ...
AVM Besonderheiten beachten. FritzBox Wireguard zu "normalem" Wireguard (RasPi etc.):
https://administrator.de/forum/wireguard-lan-to-lan-fritzbox-raspberry-p ...
https://www.heise.de/select/ct/2022/23/2225809105962410605
Wireguard Bug in pfSense und OPNsense Package:
https://administrator.de/knowledge/pfsense-2-5-2-wireguard-package-und-d ...
Wireguard Download:
https://www.wireguard.com/install/
Wireguard Performance Vergleich:
https://www.wireguard.com/performance/
Achtung bei Gateway Redirect Konzepten. Split Tunneling ist oft die bessere Wahl!:
https://administrator.de/forum/wireguard-traffic-gateway-redirect-332863 ...
https://administrator.de/forum/wireguard-verhaelt-sich-komisch-342206204 ...
VPN Tunnel MTUs richtig handhaben:
https://administrator.de/forum/langsamer-upload-opnsense-wireguard-zu-ub ...
DS-Lite Anschluss und VPN: Lösung mit Vermittlungsserver und fester IP:
https://administrator.de/forum/zwei-mobilfunkrouter-tp-link-mr200-vpn-ve ...
https://administrator.de/tutorial/feste-ips-zuhause-in-pfsense-via-wireg ...
https://administrator.de/tutorial/feste-ips-zuhause-pfsense-tunnel-56761 ...
Tücken bei remotem Port Forwarding in den WireGuard VPN Tunnel beachten:
https://administrator.de/contentid/1161214871#comment-1280687176
WireGuard Site-2-Site VPN mit OPNsense/pfSense und Mikrotik:
https://administrator.de/forum/ros-7-richtige-wireguard-config-666701.ht ...
OSPF Routing mit Wireguard und Mikrotik
https://administrator.de/forum/verstaendnisfrage-zu-ospf-routing-bei-mik ...
Lokalen Webserver über WG und vServer erreichbar machen:
https://administrator.de/contentid/2596285514
Alternative VPN Protokolle und ihre Umsetzung:
OpenVPN "Merkzettel":
Merkzettel: VPN Installation mit OpenVPN
L2TP VPN mit onboard VPN Clients auf pfSense/OPNsense Firewall:
PfSense VPN mit L2TP (IPsec) Protokoll für mobile Nutzer
L2TP VPN mit onboard VPN Clients auf Mikrotik Router:
https://administrator.de/content/detail.php?id=562927&token=111#comm ...
IPsec VPN mit onboard VPN Clients auf pfSense/OPNsense Firewall:
IPsec VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Dynamisches VPN Routing mit OSPF oder RIPv2:
https://administrator.de/tutorial/cisco-mikrotik-pfsense-vpn-standort-ve ...
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 ...
Please also mark the comments that contributed to the solution of the article
Content-Key: 660620
Url: https://administrator.de/contentid/660620
Printed on: January 30, 2023 at 08:01 o'clock
21 Comments
Latest comment
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.
mit PIVPN (https://www.pivpn.io/) einrichten - inkl. einfacher Generierung eines QR Codes,
den man mit der Wireguard App einfach abfotografieren kann.
Cool, Danke für die Übersicht @aqui. Bin noch am überprüfen meiner Setups um sicherzustellen, dass ich nix übersehen habe
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.
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.
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.
c) und d) Da bin ich dann mal gespannt
Viele Grüße und einen guten Start ins WE an alle Forenteilnehmer!
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.
c) und d) Da bin ich dann mal gespannt
Viele Grüße und einen guten Start ins WE an alle Forenteilnehmer!
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.
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.
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
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
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)
So ist gerade die Regel dazu
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.
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)
So ist gerade die Regel dazu
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.

Wäre es möglich, dein Problem in einem eigenen Beitrag zu diskutieren?

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:
Gruß
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ß