23
Wireguard Verbindung erstellen mit Ubuntu und Windows
Hallo zusammen,
ich versuche eine Wireguard Verbindung mit einem Ubuntu 22.04 Server und einem Windows-Clienten zu erstellen.
Die Server Config sieht so aus:
Client sieht so aus:
enp2s0 ist der physische LAN-Anschluss am Server. ufw ist bei mir nicht aktiv. Der Server hängt hinter einem Router.
Wenn ich den Clienten ins LAN einhänge und mich mit der lokalen IP des Servers 192.168.0.2, genauso wenn ich mich extern über eine DynDNS-Adresse verbinden möchte, sind Pings für
nicht erfolgreich.
Bedeutet für mich, dass ich an das IPv4 Forwarding nicht mal denken muss ... Es werden auf dem Client auch keine empfangenen Pakete angezeigt, Verbindung ist aber angeblich aktiv. Es kann auch nicht die Portweiterleitung im Router sein, da es ja auch nicht funktioniert, wenn alle im LAN sind.
Wo kann der Fehler liegen? Ich muss ja zumindest die VPN-IP des Servers anpingen können.
ich versuche eine Wireguard Verbindung mit einem Ubuntu 22.04 Server und einem Windows-Clienten zu erstellen.
Die Server Config sieht so aus:
# Server configuration
[Interface]
PrivateKey = 1234 # The server_private.key value.
Address = 10.5.5.1/24 # Internal IP address of the VPN server.
ListenPort = 51820 # Previously, we opened this port to listen for incoming connections in the firewall.
# Change "enp0s5" to the name of your network interface in the following two settings. This commands configures ipta>
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o enp2s0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o enp2s0 -j MASQUERADE
# Configurations for the clients. You need to add a [Peer] section for each VPN client.
[Peer]
PublicKey = 9876 # client_public.key value.
AllowedIPs = 10.5.5.2/32 # Internal IP address of the VPN client.Client sieht so aus:
[Interface]
PrivateKey = 5678
Address = 10.5.5.2/24
DNS = 8.8.8.8
[Peer]
PublicKey = 9876
AllowedIPs = 0.0.0.0/0
Endpoint = server.server.de:51820
PersistentKeepalive = 25enp2s0 ist der physische LAN-Anschluss am Server. ufw ist bei mir nicht aktiv. Der Server hängt hinter einem Router.
Wenn ich den Clienten ins LAN einhänge und mich mit der lokalen IP des Servers 192.168.0.2, genauso wenn ich mich extern über eine DynDNS-Adresse verbinden möchte, sind Pings für
ping 10.5.5.1Bedeutet für mich, dass ich an das IPv4 Forwarding nicht mal denken muss ... Es werden auf dem Client auch keine empfangenen Pakete angezeigt, Verbindung ist aber angeblich aktiv. Es kann auch nicht die Portweiterleitung im Router sein, da es ja auch nicht funktioniert, wenn alle im LAN sind.
Wo kann der Fehler liegen? Ich muss ja zumindest die VPN-IP des Servers anpingen können.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 42976083824
Url: https://administrator.de/contentid/42976083824
Ausgedruckt am: 06.10.2024 um 06:10 Uhr
23 Kommentare
Neuester Kommentar
Das hiesige Wireguard Tutorial hast du gelesen und alle dort beschriebenen Schritte entsprechend richtig umgesetzt?! 🤔
Klassische Anfänger Fehler die du gemacht hast:
Klassische Anfänger Fehler die du gemacht hast:
- NAT (IP Adress Translation) unnötigerweise im Tunnel gemacht. Sollte entfernt werden!
- Google DNS verwenden heute auch keine Dummies mehr! (Datensicherheit!). DNS Parameter benötigst du nur dann, wenn du einen internen DNS betreibst ansonsten immer weglassen!
- Der Client macht ein Gateway Redirect was performancetechnisch kontraproduktiv ist, es sei denn es ist gewollt allen Client Traffic in den Tunnel zu routen. Besser ist immer ein Split Tunneling zu realisieren. (Siehe Tutorial)
- Port Forwarding für den WG UDP Port im davor kaskadierten Router auf den Server ist eingerichtet? Ebenso eine statische Route auf das interne Wireguard IP Netz? (Siehe Tutorial und auch HIER für Router Kaskaden allgemein!)
- Bedenke das du aus einem IP Fremdnetz kommst und ICMP (Ping) in der Winblows Firewall immer freischalten musst. ICMP (Ping) ist in der Winblows Firewall grundsätzlich deaktiviert im Default! Siehe: https://www.windowspro.de/wolfgang-sommergut/ping-windows-10-erlauben-gu ...
Bedeutet für mich, dass ich an das IPv4 Forwarding nicht mal denken mus
Nein, daran musst du denken! IPv4 Forwarding zu aktivieren auf dem Server ist dann zwingend erforderlich!Verbindung ist aber angeblich aktiv.
Angeblich? Raten ist immer schlecht in der IT. ☹️ Was sagt ein wg show auf dem Server?!
wg show sagt mir:
IPv4 Forwarding ist auf dem Server schon längst aktiv, da parralel / vorher ein OpenVPn drauf läuft/lief. Das hat auch funktioniert, Wireguard will irgendwie nicht. Openvpn auch in der selben Konstellation ...
kann man irgendwie einen Log aufrufen, um zu wissen ob es überhaupt Anmeldeversuche auf dem Server gab?
interface: wg0
public key: 9876
private key: (hidden)
listening port: 51820IPv4 Forwarding ist auf dem Server schon längst aktiv, da parralel / vorher ein OpenVPn drauf läuft/lief. Das hat auch funktioniert, Wireguard will irgendwie nicht. Openvpn auch in der selben Konstellation ...
kann man irgendwie einen Log aufrufen, um zu wissen ob es überhaupt Anmeldeversuche auf dem Server gab?
ich habe jetzt auch nochmal die Konfiguration aus dem Tutorial reinkopiert, es geht einfach nicht.
NAT (IP Adress Translation) unnötigerweise im Tunnel gemacht. Sollte entfernt werden!
Durch die Übernahme der Config aus dem Tutorial erledigt.Google DNS verwenden heute auch keine Dummies mehr! (Datensicherheit!). DNS Parameter benötigst du nur dann, wenn du einen internen DNS betreibst ansonsten immer weglassen!
Durch die Übernahme der Config aus dem Tutorial erledigt.Der Client macht ein Gateway Redirect was performancetechnisch kontraproduktiv ist, es sei denn es ist gewollt allen Client Traffic in den Tunnel zu routen. Besser ist immer ein Split Tunneling zu realisieren. (Siehe Tutorial)
Es soll kein Gateway Redirect durchgeführt werden. Wenn aber Client und Server gleichzeitig im LAN sind und keine Ping oder Webserver unter 100.64.64.1 erreichbar ist, dann denke ich nicht, dass dieses der Fehler ist.Port Forwarding für den WG UDP Port im davor kaskadierten Router auf den Server ist eingerichtet? Ebenso eine statische Route auf das interne Wireguard IP Netz? (Siehe Tutorial und auch HIER für Router Kaskaden allgemein!)
Ist klar, im LAN aber nicht relevant.Bedenke das du aus einem IP Fremdnetz kommst und ICMP (Ping) in der Winblows Firewall immer freischalten musst. ICMP (Ping) ist in der Winblows Firewall grundsätzlich deaktiviert im Default! Siehe: https://www.windowspro.de/wolfgang-sommergut/ping-windows-10-erlauben-gu ...
Bei OpenVPN konnte ich vom Windows Client auf den Ubuntu Server auch immer pingen, ohne die Konfiguration der Windows Firewall anzupassen. Daher schließe ich das hier aus.wg show sagt mir:
Das zeigt das dein Tunnel nicht aktiv ist! 
So sollte das aussehen...
root@server:/home/admin# wg show
interface: wg0
public key: 56G8labcdefg=
private key: (hidden)
listening port: 51820
peer: 0FAcGxb01eABCDefg=
endpoint: 88.1.2.3:40713
allowed ips: 10.5.5.2/32
latest handshake: 2 days, 4 hours, 5 minutes, 6 seconds ago
transfer: 2.89 MiB received, 41.03 MiB sent Da kommt also gar kein WG Traffic an beim Server!
Vermutung: Falsches oder fehlerhaftes Port Forwarding im davor kaskadierten Router!!
Tip:
Installiere dir mit apt get tcpdump einen kleinen Sniffer auf dem Server und checke überhaupt erstmal ob dort eingehender, geforwardeter Traffic vom Router ankommt mit:
tcpdump -i enp2s0 -n port 51820
Das schafft dir dann Gewissheit!
Na super, und was ist jetzt falsch an diesem?
Ich teste das gerade ja im LAN aus, also nicht über das Internet. Geht trotzdem nicht.
[Interface]
Address = 100.64.64.1/24
PrivateKey = 1234
ListenPort = 51820
[Peer]
PublicKey = 9876
AllowedIPs = 100.64.64.100/32, 192.168.0.0/24Da kommt also gar kein WG Traffic an beim Server! face-sad
Vermutung: Falsches oder fehlerhaftes Port Forwarding im davor kaskadierten Router!!
Vermutung: Falsches oder fehlerhaftes Port Forwarding im davor kaskadierten Router!!
Ich teste das gerade ja im LAN aus, also nicht über das Internet. Geht trotzdem nicht.
Geht trotzdem nicht.
tcpdump aktiv um dir das mal anzusehen ob da überhaupt was mit UDP 51820 ankommt?? Wenn da nix kommt ist eine Firewall am Server aktiv!
da ist keine Firewall aktiv. Es kommt auf dem Server auch was an:
listening on enp2s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
17:48:41.193297 IP notebook.fritz.box.53439 > server.fritz.box.51820: UDP, length 148
17:48:46.249932 IP notebook.fritz.box.53439 > server.fritz.box.51820: UDP, length 148
17:49:31.775267 IP notebook.fritz.box.59119 > server.fritz.box.51820: UDP, length 148
17:49:36.841264 IP notebook.fritz.box.59119 > server.fritz.box.51820: UDP, length 148ich habe jetzt auch nochmal die Konfiguration aus dem Tutorial reinkopiert
Interne IP Adressierung entsprechend auch am Client angepasst?!Es kommt auf dem Server auch was an:
OK, das sieht gut aus...Dann bleibt nur noch das du falsche Keys verwendest auf Server oder Client oder beiden bzw. diese verwechselt hast!!
Guckst du dazu auch hier zur richtigen Verteilung der Keys.
Die Keys habe ich jetzt alle neu erstellt.
Client Config ist diese hier:
und geht immer noch nicht ...
Client Config ist diese hier:
[Interface]
PrivateKey = xyz
Address = 100.64.64.101/24
[Peer]
PublicKey = 9876
AllowedIPs = 100.64.64.1/32, 192.168.0.0/24
Endpoint = 192.168.0.2:51820
PersistentKeepalive = 25und geht immer noch nicht ...
Zitat von @ferdrt:
Die Keys habe ich jetzt alle neu erstellt.
Client Config ist diese hier:
und geht immer noch nicht ...
Die Keys habe ich jetzt alle neu erstellt.
Client Config ist diese hier:
[Interface]
PrivateKey = xyz
Address = 100.64.64.101/24
[Peer]
PublicKey = 9876
AllowedIPs = 100.64.64.1/32, 192.168.0.0/24
Endpoint = 192.168.0.2:51820
PersistentKeepalive = 25und geht immer noch nicht ...
Nicht verwunderlich denn..
Am Server steht für den Peer
AllowedIPs = 100.64.64.100/32
Und du schreibst am Client in die Config
100.64.64.101/24
Passt also nicht zusammen.... Deswegen kann da nix durch kommen da das Cryptokey Routing dann verständlicherweise nicht passt.
Ergo => PEBKAC
Btw. 192.168.0.0/24 macht in den Allowed IPs am Client keinen Sinn wenn du intern connectest.
Gruß wrk
1
das ist es leider auch nicht, habe die 101 mal durch die 100 ersetzt und im Client 192.168.0.0. entfernt.
Dann erstellst du wohl die Keys schon falsch oder setzt sie falsch ein.
1
möglich, aber Keys habe ich genau hiermit erstellt und halt nur nicht peer1_public.key verwendet.
ich habe das 1:1 ins Terminal kopiert ...
umask 077
wg genkey | tee server_private.key | wg pubkey > server_public.key
wg genkey | tee peer1_private.key | wg pubkey > peer1_public.key ich habe das 1:1 ins Terminal kopiert ...
halt nur nicht peer1_public.key verwendet.
Der gehört aber in die Server-Config für den Peer.Denke du hast die nicht an die richtige Stelle gesetzt bzw. verwechselt.
Also, SERVER muss so aussehen
[Interface]
Address = 100.64.64.1/24
PrivateKey = <PRIVATE KEY SERVER>
ListenPort = 51820
[Peer]
PublicKey = <PUBLIC KEY CLIENT>
AllowedIPs = 100.64.64.100/32und CLIENT Config so
[Interface]
PrivateKey = <PIVATE KEY CLIENT>
Address = 100.64.64.100/24
[Peer]
PublicKey = <PUBLIC KEY SERVER>
AllowedIPs = 100.64.64.1/32, 192.168.0.0/24
Endpoint = xxxxxxxxx:51820
PersistentKeepalive = 25
genau das war es. Ich dachte es gäbe nur einen einheitlichen PublicKey ...
die Verbindung geht jetzt auch. Ping geht zwar nicht, aber ich komme mit 10.64.64.1 auf den Webserver. Das dürfte dann wohl doch das Problem mit der Firewall sein.
Danke!
die Verbindung geht jetzt auch. Ping geht zwar nicht, aber ich komme mit 10.64.64.1 auf den Webserver. Das dürfte dann wohl doch das Problem mit der Firewall sein.
Danke!
Leider kann ich mein Heimnetz noch nicht erreichen.
Die Verbindung geht jetzt, wenn ich mich über extern zum Server verbinde. Ich bekomme eine Rückmeldung, wenn ich
vom externen Client über den VPN-Server zur Fritzbox mache. Also scheint der VPN-Server die Verbindung ja weiterzureichen.
Und das ist in sysctl.conf aktiviert und funktioniert unter OpenVpn auch
Jetzt kann ich aber mit dem Browser nicht auf den Server mit 100.64.64.1 oder 192.168.0.2 gehen. Die Fritzbox erreiche ich per Browser über die 192.168.0.1 auch nicht, Ping geht.
Server ist:
Client ist:
LAN IP des Servers ist 192.168.0.2
Ich habe in der Fritzbox als 192.168.0.1 diese statische IPv4 Route eingetragen.
Wobei das eigentlich nicht sein müsste oder? Der Client kann über den Server per Ping ja 192.168.0.1 erreichen, aber alles andere nicht. Müsste das dann nicht die Firewall auf dem Windows-Client sein, die angepasst werden müsste?
Auf meinem Android Smartphone kann ich alles im Heimnetz erreichen, auf dem Windows Client nicht. Eine deaktivierte Windows-Firewall brachte keine Besserung. Ich komme vom externen Windows Client auch nicht auf die Dateifreigaben, welche mit \\192.168.0.2\Freigabe eingebunden sind, drauf.
Ich habe mal versucht eine IP-Kamera per IP-Adresse im Browser aufzurufen. Es kommt die übliche Abfrage der Zugangsdaten mittels htaccess, eine Website baut sich aber nicht auf.
Woran kann das Problem liegen?
Die Verbindung geht jetzt, wenn ich mich über extern zum Server verbinde. Ich bekomme eine Rückmeldung, wenn ich
ping 192.168.0.1Und das ist in sysctl.conf aktiviert und funktioniert unter OpenVpn auch
net.ipv4.ip_forward=1Server ist:
[Interface]
Address = 100.64.64.1/24
PrivateKey = 1234
ListenPort = 51820
[Peer]
PublicKey = xyz
AllowedIPs = 100.64.64.100/32[Interface]
PrivateKey = abc
Address = 100.64.64.100/24
[Peer]
PublicKey = def
AllowedIPs = 100.64.64.1/32, 192.168.0.0/24
Endpoint = xxxxxxxxx:51820
PersistentKeepalive = 25Ich habe in der Fritzbox als 192.168.0.1 diese statische IPv4 Route eingetragen.
Netzwerk: 100.64.64.0
Subnetzmaske: 255.255.255.0
Gateway: 192.168.0.2Auf meinem Android Smartphone kann ich alles im Heimnetz erreichen, auf dem Windows Client nicht. Eine deaktivierte Windows-Firewall brachte keine Besserung. Ich komme vom externen Windows Client auch nicht auf die Dateifreigaben, welche mit \\192.168.0.2\Freigabe eingebunden sind, drauf.
Ich habe mal versucht eine IP-Kamera per IP-Adresse im Browser aufzurufen. Es kommt die übliche Abfrage der Zugangsdaten mittels htaccess, eine Website baut sich aber nicht auf.
Woran kann das Problem liegen?
Ich kam jetzt doch noch auf die Lösung.
Ich habe in der Server Config die MTU anpassen müssen. Die "alten" OpenVPN und enp2s0 hatten 1500.
Unter Interface in der Server Config konnte ich es dann so beheben:
Ich habe in der Server Config die MTU anpassen müssen. Die "alten" OpenVPN und enp2s0 hatten 1500.
Unter Interface in der Server Config konnte ich es dann so beheben:
MTU = 1500Zitat von @ferdrt:
Ich kam jetzt doch noch auf die Lösung.
Ich habe in der Server Config die MTU anpassen müssen. Die "alten" OpenVPN und enp2s0 hatten 1500.
Unter Interface in der Server Config konnte ich es dann so beheben:
Ich kam jetzt doch noch auf die Lösung.
Ich habe in der Server Config die MTU anpassen müssen. Die "alten" OpenVPN und enp2s0 hatten 1500.
Unter Interface in der Server Config konnte ich es dann so beheben:
MTU = 1500Das ist leider Bullshit, die OpenVPN Angaben der MTU und die Wireguard MTU haben nichts gemeinsam, und damit wirst du auch höchst wahrscheinlich herbe Paket-Fragmentierung erleiden. Das maximal mögliche der Gefühle bei Wireguard ist wegen des Protokoll Overheads eine MTU von 1440 wenn man im Tunnel nur IPv4 verwendet, ansonsten ist wegen des größeren IPv6-Headers von 40 bytes sogar nur 1420 drin.
Diese Werte sind aber ohne evt. PPPoE (8bytes) &Co. am Client gerechnet und fallen dort je nachdem noch geringer aus, denn Clients haben ebenfalls diese Einstellung für den Fall das die PMTU fehlschlägt.
Das Hauptproblem ist auch das Windows Firewalls per Default ICMP aus fremden Subnetzen blocken und somit auch die automatische PMTU Ermittlung fehlschlägt und es zu diesem Problem der Fragmentierung kommt wenn die MTU nicht korrekt hinterlegt ist.
Gruß wrk.
1
ich hatte mich vor Ewigkeiten mit der WG MTU beschäftigt und bin bei 1412 gelandet, ohne Angabe gab es Probleme mit Fragmentierung, da default WireGuard MTU 1420 Bytes.
Zitat von @Avenga:
ich hatte mich vor Ewigkeiten mit der WG MTU beschäftigt und bin bei 1412 gelandet, ohne Angabe gab es Probleme mit Fragmentierung, da default WireGuard MTU 1420 Bytes.
Das sind ja genau die genannten 8 Bytes für den gängigen PPPoE Overhead der Internet-Provider bei der Einwahl ich hatte mich vor Ewigkeiten mit der WG MTU beschäftigt und bin bei 1412 gelandet, ohne Angabe gab es Probleme mit Fragmentierung, da default WireGuard MTU 1420 Bytes.
.Wie immer zeigt einem ein Ping mit gesetztem "do not fragment" Flag das maximal mögliche ...
Ping-Test zur Ermittlung der optimalen MTU-Größe auf dem Router
1Zitat von @13676056485:
.
Wie immer zeigt einem ein Ping mit gesetztem "do not fragment" Flag das maximal mögliche ...
Ping-Test zur Ermittlung der optimalen MTU-Größe auf dem Router
Zitat von @Avenga:
ich hatte mich vor Ewigkeiten mit der WG MTU beschäftigt und bin bei 1412 gelandet, ohne Angabe gab es Probleme mit Fragmentierung, da default WireGuard MTU 1420 Bytes.
Das sind ja genau die genannten 8 Bytes für den gängigen PPPoE Overhead der Internet-Provider bei der Einwahl ich hatte mich vor Ewigkeiten mit der WG MTU beschäftigt und bin bei 1412 gelandet, ohne Angabe gab es Probleme mit Fragmentierung, da default WireGuard MTU 1420 Bytes.
.Wie immer zeigt einem ein Ping mit gesetztem "do not fragment" Flag das maximal mögliche ...
Ping-Test zur Ermittlung der optimalen MTU-Größe auf dem Router
Bei MTU 1420: Die Firewall kann ich deaktivieren oder aktivieren, ich kann auch nur die ICMP-Regeln aktivieren oder deaktivieren. Ich kann immer nur von Extern nach Intern anpingen, die Websiten aber nicht erreichen.
Ich musste wirklich die MTU einstellen. Mittels des Links von Netgear konnte ich einen maximalen Wert von 1464 ermitteln. Das eingestellt, oder auch 1440 und ich kann von extern die Webserver im Heimnetz über IPv4 aufrufen, keine Probleme.
Jetzt will ich die Konfiguration gleichzeitig über IPv6 und IPv4 erreichbar machen.
Aktuell ist die Konfiguration so:
Server:
[Interface]
Address = 10.0.2.1/24, fd8f:d4dc:9de9::1/64
PrivateKey = ...
ListenPort = 51820
MTU = 1464
[Peer]
PublicKey = ...
AllowedIPs = 10.0.2.2/32, fd8f:d4dc:9de9::2/128Client:
[Interface]
PrivateKey = ...
Address = 10.0.2.2/24, fd8f:d4dc:9de9::2/64
[Peer]
PublicKey = ...
AllowedIPs = 10.0.2.1/32, 192.168.0.0/24, fd8f:d4dc:9de9::/128
Endpoint = ....de:51820
PersistentKeepalive = 25Die IPv6 Adressen für die VPN-Verbindung hatte ich von hier: https://www.hosting.de/helpdesk/anleitungen/server/wireguard_server/ Sonst habe ich davon nichts eingestellt.
net.ipv6.conf.all.forwarding = 1 war wegen OpenVPN bereits aktiviert.
Auf dem externen Windows Client deaktiviere ich bei der Interverbindung bewusst das IPv4 Protokoll, damit es auf alle Fälle über IPv6 geht. Das IPv4 Protokoll ist bei der VPN Verbindung weiterhin aktiv.
Um den Router 192.168.0.1 per Browser zu erreichen musste ich sogar die MTU auf 1392 stellen.
Jetzt will ich die Konfiguration gleichzeitig über IPv6 und IPv4 erreichbar machen.
Extern per IPv6 auf deinen Router oder nur Wireguard intern IPv6 oder beides?AllowedIPs = 10.0.2.1/32, 192.168.0.0/24, fd8f:d4dc:9de9::/128
Der IPv6 Host ist falsch so erreichst du nämlich nur einen einzelnen Host im Wireguard Netz nämlich diesen fd8f:d4dc:9de9:0:0:0:0:0Wenn du andere IPv6 Netze im Ziel erreichen willst müssen die natürlich auch hinzugefügt werden damit Routen gesetzt werden. Wenn du dann Internet über IPv6 (Gateway Redirect) machen willst sind zusätzliche Maßnahmen erforderlich wenn du kein festes global routbares Pv6 Netz zuhause hast. Dann musst du auf dem Wireguard Router ausgehend IPv6 Traffic SRCNATen (masquerading).
Grundlagen zu IPv6 bitte erst einmal hier einlesen bevor du damit hantierst dann bist du für alle Fälle gewappnet und kannst auf jeden Fall richtig reagieren.
https://danrl.com/ipv6/
Gruß.
1
