thephantom79
Goto Top

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:
[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

Content-ID: 562886

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

Ausgedruckt am: 21.11.2024 um 22:11 Uhr

aqui
aqui 03.04.2020, aktualisiert am 12.03.2021 um 22:42:58 Uhr
Goto Top
Details zum Wiregueard Setup auch hier: Merkzettel: VPN Installation mit 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. face-wink
ThePhantom79
ThePhantom79 03.04.2020 um 10:10:28 Uhr
Goto Top
Vielen dank,

erlaube mir trotzdem bitte eine Frage:

Warum steht in jeder Anleitung, die ich gefunden habe, dass in der Client Konfig unter "Allowed IPs" die VPN-IP des Servers eintragen soll (also in meinem Falle 10.99.99.1/32.
Beispiel (beste Doku für wireguard, wie ich finde, hier eine Beispielkonfig):

https://github.com/pirate/wireguard-docs/blob/master/example-simple-clie ...

Ich will es nur verstehen. warum mein Split-Tunnel scheinbar anders konfiguriert wird, als in den Anleitungen ...
affabanana
affabanana 04.04.2020 um 13:27:25 Uhr
Goto Top
Salutti Zäma

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
aqui
aqui 04.04.2020 um 17:38:25 Uhr
Goto Top
🇨🇭HomeOffice ? face-wink
ThePhantom79
ThePhantom79 07.04.2020 um 16:13:05 Uhr
Goto Top
Also nach einigen Tagen in Benutzung, klappt es schon fast ganz gut.

Zwei Punkte, wo Ihr vlt noch einen Tipp habt:

1) Die Verbindung funktioniert leider nach einigen Stunden nicht mehr. Erst ein Reconnect hilft hier. Dadurch, dass ich jedoch ALLES tunnele, habe ich dadurch dann am Handy gar kein Internet mehr - und bemerke es nicht mal. Warum könnte die Verbindung unterbrochen werden (auch OHNE neue IP an der "Serverseite"?

2) Ich bin von OVPN umgestiegen, da ich per VPN auf meine SIP-Klingel zugreifen wollte. Dies wird durch eine App (Smarthome App --> Loxone) die über die Fritzbox dir Türstation anruft, realisiert. Zu Hause im WLAN klappt das wunderbar. Mit OVPN konnte ich keine SIP-Sprachverbindung aufbauen (die App an sich ging, nur konnte ich keine SIP-Verbindung aufbauen --> kein Audio, auch alles andere ging im VPN). Allerdings habe ich da auch nur den 192* Verkehr getunnelt.

Nun mit wireguard sieht es sehr ähnlich aus: Wenn ich den kompletten Netzwerkverkehr von unterwegs tunnele (Allowed IPs 0.0.0.0/0), klappt alles wunderbar mit der SIP-Verbindung. Tunnele ich nur 192.168.0.0, bekomme ich wieder keine Sprachverbindung. Und daheim sind ALLE Geräte im 192.168.0.0er Netz. Sowohl Fritzbox, SIP-Klingelanlage als natürlich auch der wireguard. Wo könnte hier noch etwas fehlen?


Vielen dank schon mal für die Hilfestellungen bisher.
aqui
aqui 07.04.2020 aktualisiert um 16:18:44 Uhr
Goto Top
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 !
ThePhantom79
ThePhantom79 07.04.2020 aktualisiert um 18:21:20 Uhr
Goto Top
Hmm, dann bin ich gerade mit meinem Wissen am Ende.
Ich habe nur die Konfig eingespielt wie oben beschrieben, und weiß nicht, ob ich NAT innerhalb des VPN verwende...

Muss ich mir wohl erst mal was anlesen...

Edit:
Also meine iptable befehle für das starten von wiregate lauten wie oben angegeben:

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

Ist das nicht korrekt?
ThePhantom79
ThePhantom79 07.04.2020 um 18:40:41 Uhr
Goto Top
Das weglassen der letzten Regel bringt auch nix

PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT
aqui
aqui 08.04.2020 aktualisiert um 11:30:31 Uhr
Goto Top
und weiß nicht, ob ich NAT innerhalb des VPN verwende...
Dann solltest du mal deine iptables Settings ansehen ! face-wink
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.
ThePhantom79
ThePhantom79 09.04.2020 aktualisiert um 08:17:39 Uhr
Goto Top
Also daran liegt es bei mir dann wohl nicht:

root@vpn:/home/xxx# /sbin/iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
aqui
aqui 09.04.2020 um 11:09:23 Uhr
Goto Top
Stimmt, das kann man dann ausschliessen !
realschmide
realschmide 16.01.2021 um 19:23:31 Uhr
Goto Top
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 ...