Wireguard - Konfiguration "Allowed IPs" bei Clients
Hallo zusammen,
ich nutze seit ein paar Tagen Wireguard um mich von unterwegs von Laptop / Handy ins Heimnetz zu verbinden. Bisher nutzte ich Open VPN.
Nach einiger Konfiguration läuft das grundsätzlich, ABER - leider nicht so wie es in jeder Anleitung steht.
Ich habe übrigens kein anderes Forum gefunden, wo man (gerne auch auf englisch) sich ganz speziell zum Thema wireguard austauschen kann ... (Hat da jemand einen Tipp?)
Zum Verständnis: Ich gehe davon aus, dass wie bei OPENVPN natürlich neben dem eigentlichen privaten Netz zu hause (in meinem Falle 192.168.0.0) natürlich ein weiteres VPN-Transportnetz aufgebaut werden muss (ich habe mich für 10.99.99.0 entschieden). Korrekt?
Was habe ich gemacht:
- wireguard auf Debian 10 installiert (VM)
- Routing zwischen den Netzen netzwerken aktiviert ($ echo "net.ipv4.ip_forward = 1" > /etc/sysctl.d/wg.conf)
- public / private keys für server und clienten erstellt
- wg*.conf auf server erstellt mit public keys der Clienten und einer allowed-IP aus dem VPN-Netz 10.99.99.x/32 und dem Interface für den Server inkl. private key
- wg*.confs für Clienten erstellt inkl. private Keys des Clienten und Publik-Key des Server, Endpoint (DynDNS) inkl. wireguardport . --> zu den Allowed IPs in den Clienten komme ich unten. da steckt das Problem.
- Daheim auf der Fritzbox eine Portweiterleitung des WG-Ports auf den Wireguard Server
- Daheim auf der Fritzbox eine statische Route des Netzes 10.99.99.0 auf die IP des wireguard-server (192.168.0.x)
Alles korrekt bisher?
Nun zu den Allowed IPs bei den Clienten:
- trage ich hier 0.0.0.0/0 ein, funktioniert das ganze - es wird der KOMPLETTE Verkehr über den VPN-Server geleitet. Das will ich allerdings nicht immer.
- trage ich hier die VPN-IP des wireguardservers ein (wie in JEDER Anleitung steht), sehe ich zwar ein Handshake, allerdings werden keine weiteren Daten ausgetauscht. Es klappt einfach nix.
- trage ich hier das komplette "Heimnetz" ein (192.168.0.0/24) klappt wieder alles.
Ich würde gerne verstehen, wieso das ist.
Leider ist das ganze auf dem dem Android Handy nicht 100% stabil, nach paar Stunden scheint nichts mehr zu gehen, erst nach deaktivieren und aktivieren des Tunnels klappts wieder - das kann aber auch ein anderes Thema sein.
Hier mal meine Konfigs:
Server:
Client
ich nutze seit ein paar Tagen Wireguard um mich von unterwegs von Laptop / Handy ins Heimnetz zu verbinden. Bisher nutzte ich Open VPN.
Nach einiger Konfiguration läuft das grundsätzlich, ABER - leider nicht so wie es in jeder Anleitung steht.
Ich habe übrigens kein anderes Forum gefunden, wo man (gerne auch auf englisch) sich ganz speziell zum Thema wireguard austauschen kann ... (Hat da jemand einen Tipp?)
Zum Verständnis: Ich gehe davon aus, dass wie bei OPENVPN natürlich neben dem eigentlichen privaten Netz zu hause (in meinem Falle 192.168.0.0) natürlich ein weiteres VPN-Transportnetz aufgebaut werden muss (ich habe mich für 10.99.99.0 entschieden). Korrekt?
Was habe ich gemacht:
- wireguard auf Debian 10 installiert (VM)
- Routing zwischen den Netzen netzwerken aktiviert ($ echo "net.ipv4.ip_forward = 1" > /etc/sysctl.d/wg.conf)
- public / private keys für server und clienten erstellt
- wg*.conf auf server erstellt mit public keys der Clienten und einer allowed-IP aus dem VPN-Netz 10.99.99.x/32 und dem Interface für den Server inkl. private key
- wg*.confs für Clienten erstellt inkl. private Keys des Clienten und Publik-Key des Server, Endpoint (DynDNS) inkl. wireguardport . --> zu den Allowed IPs in den Clienten komme ich unten. da steckt das Problem.
- Daheim auf der Fritzbox eine Portweiterleitung des WG-Ports auf den Wireguard Server
- Daheim auf der Fritzbox eine statische Route des Netzes 10.99.99.0 auf die IP des wireguard-server (192.168.0.x)
Alles korrekt bisher?
Nun zu den Allowed IPs bei den Clienten:
- trage ich hier 0.0.0.0/0 ein, funktioniert das ganze - es wird der KOMPLETTE Verkehr über den VPN-Server geleitet. Das will ich allerdings nicht immer.
- trage ich hier die VPN-IP des wireguardservers ein (wie in JEDER Anleitung steht), sehe ich zwar ein Handshake, allerdings werden keine weiteren Daten ausgetauscht. Es klappt einfach nix.
- trage ich hier das komplette "Heimnetz" ein (192.168.0.0/24) klappt wieder alles.
Ich würde gerne verstehen, wieso das ist.
Leider ist das ganze auf dem dem Android Handy nicht 100% stabil, nach paar Stunden scheint nichts mehr zu gehen, erst nach deaktivieren und aktivieren des Tunnels klappts wieder - das kann aber auch ein anderes Thema sein.
Hier mal meine Konfigs:
Server:
[Interface]
Address = 10.99.99.1/24
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACC$
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j A$
ListenPort = 51820
PrivateKey = *PrivatkeyServer*
DNS = 192.168.0.241
[Peer]
PublicKey = *PublickeyClient*
AllowedIPs = 10.99.99.2/32
[Peer]
PublicKey = *PublickeyClient*
AllowedIPs = 10.99.99.3/32
Client
[Interface]
PrivateKey = *PrivateKeyClient*
Address = 10.99.99.2/32
DNS = 192.168.0.241
[Peer]
PublicKey = *PublikKeyServer*
AllowedIPs = 10.99.99.1/24
Endpoint = *dyndns*:51820
PersistentKeepalive = 25
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 562886
Url: https://administrator.de/contentid/562886
Ausgedruckt am: 21.11.2024 um 22:11 Uhr
12 Kommentare
Neuester Kommentar
Details zum Wiregueard Setup auch hier: Merkzettel: VPN Installation mit Wireguard
Bei 0.0.0.0/0 wird sämtlicher IP Traffic in den Tunnel geroutet. Das nennt man auch Default gateway redirect was es bei OpenVPN ja auch gibt mit entspr. Konfig.
"192.168.0.0/24" routet dann rein nur Traffic mit den Destination IPs 192.168.0.x in den Tunnel. Split Tunnel deshalb, weil der ganze Rest der NICHT nach 192.168.0.x geht dann lokal geroutet wird. Letzteres ist der Normalfall wenn man nicht z.B. aus Sicherheitsgründen allen Traffic routen will wie z.B. an öffentlichen Hotspots oder anderen öffentlichen WLANs die nicht verschlüsselt sind.
Fazit also: Es ist alles so wie es sein sollte beim VPN.
Grundlegende Erklärungen zum Thema Split Tunneling findest du auch in diesen Threads:
https://www.heise.de/ratgeber/Einen-eigenen-VPN-Server-mit-WireGuard-bau ...
https://www.heise.de/select/ct/2019/5/1551091519824850
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Merkzettel: VPN Installation mit OpenVPN
Übrigens:
Mit einem StrongSwan Server auf deinem Debian könntest du sogar den bordeigenen VPN Client nutzen und müsstest nicht den Umweg über eine extra Software und Client gehen wie Wireguard.
ein weiteres VPN-Transportnetz aufgebaut werden muss
Das ist korrekt !Alles korrekt bisher?
Alles korrekt !Ich würde gerne verstehen, wieso das ist.
Nennt sich Split Tunneling !Bei 0.0.0.0/0 wird sämtlicher IP Traffic in den Tunnel geroutet. Das nennt man auch Default gateway redirect was es bei OpenVPN ja auch gibt mit entspr. Konfig.
"192.168.0.0/24" routet dann rein nur Traffic mit den Destination IPs 192.168.0.x in den Tunnel. Split Tunnel deshalb, weil der ganze Rest der NICHT nach 192.168.0.x geht dann lokal geroutet wird. Letzteres ist der Normalfall wenn man nicht z.B. aus Sicherheitsgründen allen Traffic routen will wie z.B. an öffentlichen Hotspots oder anderen öffentlichen WLANs die nicht verschlüsselt sind.
Fazit also: Es ist alles so wie es sein sollte beim VPN.
Grundlegende Erklärungen zum Thema Split Tunneling findest du auch in diesen Threads:
https://www.heise.de/ratgeber/Einen-eigenen-VPN-Server-mit-WireGuard-bau ...
https://www.heise.de/select/ct/2019/5/1551091519824850
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Merkzettel: VPN Installation mit OpenVPN
Übrigens:
Mit einem StrongSwan Server auf deinem Debian könntest du sogar den bordeigenen VPN Client nutzen und müsstest nicht den Umweg über eine extra Software und Client gehen wie Wireguard.
Salutti Zäma
Beim Client kannst du auch mehrere Subenetze oder nur IP's angeben.
Dort müsstest du einfach dein 192.168.0.0/24 mitgeben.
hier noch der Link zur Anleitung im Arch Wiki
Arch Wiki Wireguard
en graus us em HomeOffice affabanana
Example peer configuration:
/etc/wireguard/wg0.conf
[Interface]
PrivateKey = CLIENT_PRIVATE_KEY
[Peer]
PublicKey = SERVER_PUBLICKEY
@@+++AllowedIPs = 10.0.0.0/24, 10.123.45.0/24, 1234:4567:89ab::/48@@
Endpoint = SERVER_ENDPOINT:51871
PersistentKeepalive = 25
Beim Client kannst du auch mehrere Subenetze oder nur IP's angeben.
Dort müsstest du einfach dein 192.168.0.0/24 mitgeben.
hier noch der Link zur Anleitung im Arch Wiki
Arch Wiki Wireguard
en graus us em HomeOffice affabanana
2.) Mit OVPN konnte ich keine SIP-Sprachverbindung aufbauen
Vermutlich das gleiche Problem wie hier, das du fälschlicherweise im VPN Tunnel NAT (IP Adress Translation, Masquerading) verwendest. Das ist falsch ! Siehe dazu auch:VoIP über VPN - Port Probleme? VoIP kein Audio Input nur bei ausgehendem Anruf
Das ist der typische Anfänger Fehler das überflüssigerweise der Tunnel Traffic geNATet wird und durch die dann aktive NAT Firewall ein transparentes Routing nicht mehr funktioniert. Im Thread oben war es auch mal wieder der Grund !
Bei Wireguard ist das bei dir sehr wahrscheinlich auch der gleiche Fehler !
und weiß nicht, ob ich NAT innerhalb des VPN verwende...
Dann solltest du mal deine iptables Settings ansehen ! Iptables kannst du bei internen VPN komplett deaktivieren. Schadet mehr als das es hilft.
Ob dort masquerading gemacht wird kann man immer sehr einfach mit einem Wireshark sehen !
Lasse den auf einem Client im Netz laufen und pinge den aus dem remoten Netz an. Wenn du den Pinger mit einer "falschen" Absender IP siehst (also einer die NICHT seinem lokalen LAN entspricht), dann machst du NAT/Masquerading was dann falsch wäre.
iptables -L zeigt das gesamte Regelwerk. Dort sollte nirgendwo "Masquerading" zu sehen sein !
Wie bereits gesagt einfach testweise mal die gesamte Firewall deaktivieren mit systemctl. Da geht man dann auf Nummer sicher. Zu 98% sind das immer falsche Firewall Regeln die intern gar nicht sein müssten.
Hi, falls das Problem noch bestehen sollte:
1) hängt möglicherweise mit der Zwangstrennung deines Netzbetreibers und dem zuweisen einer neuen IP zusammen. Dann funktioniert der Tunnel erst wieder nach einem re-connect.
2) das liegt ggf. auch an einem Bug von Loxone. Loxone baut zur Klingel / Intercom eine SIP Verbindung auf. Wenn du nun einen Split Tunnel verwendest, dann übergibt Loxone an die Intercom die falsche IP (nämlich die IP deines Mobilfunkproviders, statt der IP im VPN) für die SIP Verbindung und dann funktioniert die Verbindung nicht.
Ich hab das hier beschrieben:
https://www.loxforum.com/forum/faqs-tutorials-howto-s/282884-wireguard-v ...
Und hier die Lösung, falls das die Ursache für dein Problem ist:
https://www.loxforum.com/forum/faqs-tutorials-howto-s/282884-wireguard-v ...
1) hängt möglicherweise mit der Zwangstrennung deines Netzbetreibers und dem zuweisen einer neuen IP zusammen. Dann funktioniert der Tunnel erst wieder nach einem re-connect.
2) das liegt ggf. auch an einem Bug von Loxone. Loxone baut zur Klingel / Intercom eine SIP Verbindung auf. Wenn du nun einen Split Tunnel verwendest, dann übergibt Loxone an die Intercom die falsche IP (nämlich die IP deines Mobilfunkproviders, statt der IP im VPN) für die SIP Verbindung und dann funktioniert die Verbindung nicht.
Ich hab das hier beschrieben:
https://www.loxforum.com/forum/faqs-tutorials-howto-s/282884-wireguard-v ...
Und hier die Lösung, falls das die Ursache für dein Problem ist:
https://www.loxforum.com/forum/faqs-tutorials-howto-s/282884-wireguard-v ...