Wireguard Site2Site mit Roadwarrior
Hallo zusammen,
ich hoffe es geht euch gut? Ich bin sicher, es gibt hier ein paar Leute, welche mir einen Tipp geben könnten.
Ich taste mich gerade in der Freizeit ein wenig an Wireguard heran. Habe auch schon ein paar "Teilerfolge" verbuchen können, hänge aber seit Tagen an einer kleinen, aber für mich wichtigen Sache.
Ich bin auf die "total tolle Idee" gekommen meinen Kleingarten (welcher via LTE angebunden ist) mit meinem Zuhause zu verbinden (DSL dyn IP).
Dafür hatte ich schön zwei Pi`s liegen, welche ich direkt mit WG betankt habe. Nachdem das auch geklappt hat, dachte ich mir, du kannst ja jetzt dein Notebook/Smartphone auch direkt mit WG anbinden und hast dann Zugriff nach Hause und in den Garten.
Doch da ist jetzt mein Problem, ich erreiche auf beiden Seiten alle Geräte in den Netzwerken, leider erreiche ich via Notebook/Smartphone von extern nur das Netzwerk zuhause.
Bilder sagen mehr als tausend Worte, hier mal ein grober Aufbau:
Anbei noch die Konfig-Dateien von allen Seiten:
Pi Zuhause (192.168.15.1)
wg0
Pi Zuhause (192.168.15.1)
wg1
Pi Garten (192.168.50.1)
wg0
Roadwarrior (172.31.10.4)
Ich kann vom Garten ohne Probleme Richtung zuhause und umgekehrt.
Vom Smartphone via LTE komme ich per ping auf die IPs 192.168.10.0/24 + 192.168.15.1 + 172.31.0.1 + 172.31.10.1
Auf die 172.31.0.2 komme ich hingegen nicht, genau wie auf die 192.168.50.0/24 welche ich gerne hätte.
Ich habe schon unzählige Seiten auf Google mit verschiedenen Ideen angefasst, ich schaffe es einfach nicht die Daten vom Smartphone durch den Tunnel nach Hause und dann direkt weiter durch den Tunnel in Garten zu schieben. Ich habe sicher nur einen kleinen Denkfehler, aber dieser hält sich hart.
Wäre super, wenn einer einen Anstoß zur Lösung geben könnte.
Vielen Dank und einen sonnigen Tag wünsche ich.
ich hoffe es geht euch gut? Ich bin sicher, es gibt hier ein paar Leute, welche mir einen Tipp geben könnten.
Ich taste mich gerade in der Freizeit ein wenig an Wireguard heran. Habe auch schon ein paar "Teilerfolge" verbuchen können, hänge aber seit Tagen an einer kleinen, aber für mich wichtigen Sache.
Ich bin auf die "total tolle Idee" gekommen meinen Kleingarten (welcher via LTE angebunden ist) mit meinem Zuhause zu verbinden (DSL dyn IP).
Dafür hatte ich schön zwei Pi`s liegen, welche ich direkt mit WG betankt habe. Nachdem das auch geklappt hat, dachte ich mir, du kannst ja jetzt dein Notebook/Smartphone auch direkt mit WG anbinden und hast dann Zugriff nach Hause und in den Garten.
Doch da ist jetzt mein Problem, ich erreiche auf beiden Seiten alle Geräte in den Netzwerken, leider erreiche ich via Notebook/Smartphone von extern nur das Netzwerk zuhause.
Bilder sagen mehr als tausend Worte, hier mal ein grober Aufbau:
Anbei noch die Konfig-Dateien von allen Seiten:
Pi Zuhause (192.168.15.1)
wg0
[Interface]
Address = 172.31.0.1/24
SaveConfig = true
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
ListenPort = 51820
PrivateKey = MEIN KEY
[Peer]
PublicKey = MEIN KEY
AllowedIPs = 192.168.50.0/24, 172.31.0.0/24, 172.31.10.0/24
PersistentKeepalive = 25
Pi Zuhause (192.168.15.1)
wg1
[Interface]
PrivateKey = MEIN KEY
Address = 172.31.10.1/24
PostUp = iptables -A FORWARD -i wg1 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg1 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
ListenPort = 51821
[Peer]
PublicKey = MEIN KEY
AllowedIPs = 172.31.10.2/32
PersistentKeepalive = 25
[Peer]
PublicKey = MEIN KEY
AllowedIPs = 172.31.10.3/32
PersistentKeepalive = 25
[Peer]
PublicKey = MEIN KEY
AllowedIPs = 172.31.10.4/32
PersistentKeepalive = 25
Pi Garten (192.168.50.1)
wg0
[Interface]
PrivateKey = MEIN KEY
Address = 172.31.0.2/24
SaveConfig = true
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
[Peer]
PublicKey = MEIN KEY
Endpoint = wireguard.xxxxxx-xxxxxxx.net:51820
AllowedIPs = 192.168.10.0/24, 192.168.15.0/24, 172.31.0.0/24, 172.31.10.0/24
PersistentKeepalive = 25
Roadwarrior (172.31.10.4)
[Interface]
PrivateKey = MEIN KEY
Address = 172.31.10.4/32
[Peer]
PublicKey = MEIN KEY
AllowedIPs = 192.168.10.0/24, 192.168.15.0/24, 192.168.50.0/24, 172.31.0.0/24, 172.31.10.0/24
Endpoint = wireguard.xxxxxx-xxxxxxx.net:51821
PersistentKeepalive = 25
Ich kann vom Garten ohne Probleme Richtung zuhause und umgekehrt.
Vom Smartphone via LTE komme ich per ping auf die IPs 192.168.10.0/24 + 192.168.15.1 + 172.31.0.1 + 172.31.10.1
Auf die 172.31.0.2 komme ich hingegen nicht, genau wie auf die 192.168.50.0/24 welche ich gerne hätte.
Ich habe schon unzählige Seiten auf Google mit verschiedenen Ideen angefasst, ich schaffe es einfach nicht die Daten vom Smartphone durch den Tunnel nach Hause und dann direkt weiter durch den Tunnel in Garten zu schieben. Ich habe sicher nur einen kleinen Denkfehler, aber dieser hält sich hart.
Wäre super, wenn einer einen Anstoß zur Lösung geben könnte.
Vielen Dank und einen sonnigen Tag wünsche ich.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 3133493086
Url: https://administrator.de/forum/wireguard-site2site-mit-roadwarrior-3133493086.html
Ausgedruckt am: 22.12.2024 um 02:12 Uhr
23 Kommentare
Neuester Kommentar
Du machst wie so häufig leider auch den fatalen Fehler innerhalb des Tunnels NAT/Masquerading (IP Adress Translation) zu machen, was völlig sinnfrei und auch kontraproduktiv (Performance) ist bei eigenen Netzen.
Damit hast du dann innerhalb des Tunnels eine routingtechnische Einbahnstrasse mit genau dem Problem was du oben schilderst weil du die dann damit laufende NAT Firewall wegen der fehlenden Sessiontable nicht überwinden kannst mit dem Resultat von oben.
Fazit: Lasse den Unsinn mit dem NAT und entferne das komplett dann kommt dein Wireguard VPN auch sofort zum Fliegen.
Alles Weitere erklärt dir im Detail, wie immer, das hiesige Wireguard Tutorial. 😉
Was übrigens auch eindringlich auf den NAT Fehler hinweist! Sofern man es denn einmal liest...
Ein weiterer Fehler ist im "Zuhause Pi" der ja als Server agiert. Warum sind dort ein wg0 und ein wg1 Interface? Das ist falsch. Es sollte nur ein wg0 geben mit den Peers auf den "Garten Pi" und das mobile oder die mobilen Endgeräte.
Gesamt gesehen auch ein eigentlich überflüssiges VPN Konzept, den die UBQT Routergurke bei dir ist VPN fähig und du hättest alles zentral damit lösen können ohne weiteren Hardware Overhead. Es sei denn du siehst das als Lern- und Spielprojekt um RasPis zu recyceln...
Damit hast du dann innerhalb des Tunnels eine routingtechnische Einbahnstrasse mit genau dem Problem was du oben schilderst weil du die dann damit laufende NAT Firewall wegen der fehlenden Sessiontable nicht überwinden kannst mit dem Resultat von oben.
Fazit: Lasse den Unsinn mit dem NAT und entferne das komplett dann kommt dein Wireguard VPN auch sofort zum Fliegen.
Alles Weitere erklärt dir im Detail, wie immer, das hiesige Wireguard Tutorial. 😉
Was übrigens auch eindringlich auf den NAT Fehler hinweist! Sofern man es denn einmal liest...
Ein weiterer Fehler ist im "Zuhause Pi" der ja als Server agiert. Warum sind dort ein wg0 und ein wg1 Interface? Das ist falsch. Es sollte nur ein wg0 geben mit den Peers auf den "Garten Pi" und das mobile oder die mobilen Endgeräte.
Gesamt gesehen auch ein eigentlich überflüssiges VPN Konzept, den die UBQT Routergurke bei dir ist VPN fähig und du hättest alles zentral damit lösen können ohne weiteren Hardware Overhead. Es sei denn du siehst das als Lern- und Spielprojekt um RasPis zu recyceln...
Also das mit dem NAT habe ich in so vielen Anleitungen dazu gelesen, daher habe ich es auch aktiviert.
Bedeutet aber nicht das das immer richtig ist!Dort hieß es, es sei sinnvoll die site2site und die Roadwarrior zu trennen
Warum sollte das sinnvoller sein und wo genau läge da der Vorteil? Wireguard unterscheidet konfigtechnisch da ja gar nicht zwischen Client VPN und S2S.Irgendwo fehlt da etwas in deiner Konfig. Richtig wäre:
Pi Zuhause (Server):
Server intern=.1 WG Client IPs dann ab .100. .101=1ter Client=Garten, .102=2ter Client=Mobilgerät
[Interface]
Address = 172.31.0.1/24
ListenPort = 51820
PrivateKey = Privater Server Key
[Peer]
PublicKey = Öffentlicher Garten Key
AllowedIPs = 172.31.0.101/32, 172.31.0.102/32, 192.168.50.0/24
PersistentKeepalive = 25
[Peer]
PublicKey = Öffentlicher Client Key
AllowedIPs = 172.31.0.102/32, 192.168.50.0/24
2 Peers einmal der Garten und einmal der mobile Client
Pi Garten:
[Interface]
PrivateKey = Privater Garten Key
Address = 172.31.0.101/24
[Peer]
PublicKey = Öffentlicher Server Key
Endpoint = wireguard.xxxxx-xxxxx.net:51820
AllowedIPs = 172.31.0.1/32, 172.31.0.102/32, 192.168.15.0/24
Mobiler Client:
[Interface]
PrivateKey = Privater Client Key
Address = 172.31.0.102/24
[Peer]
PublicKey = Öffentlicher Server Key
Endpoint = wireguard.xxxxx-xxxxx.net:51820
AllowedIPs = 172.31.0.1/32, 192.168.15.0/24, 192.168.50.0/24
Dein Fehler ist einmal die falsche IP Adresse .10.0/24 auf dem Garten Pi (das IP Netz existiert nirgendwo) und vermutlich deine Key Verteilung. Letzteres ist aber unklar weil du alles fälschlicherweise mit "Mein Key" bezeichnest was den Verdacht nahelegt das das überall der gleiche ist und es dann natürlich in die Hose geht.
Route auf der UBQT Gurke ist richtig. Bedenke das du zusätzlich am Gartenrouter ebenso eine statische Route ins Zuhause Netz .15.0/24 via Pi eingeben musst ansonsten geht der Traffic fürs Zuhause Netz logischerweise ins LTE Nirwana! Steht auch im Tutorial.
Die wg Adresse deines Roadwarriors ist falsch!! Als eigene Adresse gibt man immer die Maske des verwendeten IP Netzes an also /24! Das gilt auch für die Pi Clients.
Nur in den "Allowed" IP bestimmst du mit der Maske welcher Traffic in den Tunnel geroutet wird. Eine /32 ist eine Hostmaske und lässt dann explizit nur diesen Traffic durch. /24 dann z.B. das gesamte Netz.
Das solltest du also korrigieren.
Nur nochmal nebenbei gefragt: Das Aktivieren IPv4 Forwarding in den Raspberries mit Auskommentieren von net.ipv4.ip_forward=1 in der /etc/sysctl.conf und einem anschliessenden Reboot hast du gemacht??
Wenn du mit einem Client im lokalen Server Netz .15.0 bist kannst du dann:
Nur in den "Allowed" IP bestimmst du mit der Maske welcher Traffic in den Tunnel geroutet wird. Eine /32 ist eine Hostmaske und lässt dann explizit nur diesen Traffic durch. /24 dann z.B. das gesamte Netz.
Das solltest du also korrigieren.
Nur nochmal nebenbei gefragt: Das Aktivieren IPv4 Forwarding in den Raspberries mit Auskommentieren von net.ipv4.ip_forward=1 in der /etc/sysctl.conf und einem anschliessenden Reboot hast du gemacht??
Wenn du mit einem Client im lokalen Server Netz .15.0 bist kannst du dann:
- die interne WG Server IP 172.31.0.1
- die interne WG Garten IP 172.31.0.101
- die lokale Garten IP .50.1
Damit das Drama hier mal ein Ende hat...
Mikrotik simuliert hier LTE Router (Garten)
Testsetup
Server Setup "Zuhause"
root@wgserver:~# cat /etc/wireguard/wg0.conf
[Interface]
Address = 100.64.64.1/24
PrivateKey = aMQJplPxjNmYs9Ovi8my5N3Q7gOefTFgEhd9vc3PaHI=
ListenPort = 51820
[Peer]
PublicKey = IeWEMJqQng8AJoX7jwXFf6He7aqaRR3VI3EZ+/Dju0w=
AllowedIPs = 100.64.64.101/32, 192.168.88.0/24
[Peer]
PublicKey = r+REuxk9R4U9Jbub7zMB1RA2ki/LH/j4fnrSRRHIu2w=
AllowedIPs = 100.64.64.102/32
Client Setup "Garten"
root@wgclient:# cat /etc/wireguard/wg0.conf
[Interface]
Address = 100.64.64.101/24
PrivateKey = 4BDJ8uJnnzB3a6RqevYaGJ67xLMVHh5mq6aeMFltDVs=
[Peer]
PublicKey = RrGL5FfK5JBrBphqDLJd2LZ7driKX4kq89CBW9tAVAo=
Endpoint = 10.99.1.143:51820
AllowedIPs = 100.64.64.1/32, 100.64.64.102/32, 192.168.188.0/24
PersistentkeepAlive = 25
Setup mobiler Windows Client
[Interface]
Address = 100.64.64.102/24
PrivateKey = +KEP9nzDpEdjR5rC3LxvE4xU3Ppe/VSxapMhvwpTWks=
[Peer]
PublicKey = RrGL5FfK5JBrBphqDLJd2LZ7driKX4kq89CBW9tAVAo=
Endpoint = 10.99.1.143:51820
AllowedIPs = 100.64.64.1/32, 192.168.88.0/24, 192.168.188.0/24
PersistentkeepAlive = 25
Statische Routen
FritzBox simuliert hier deine UBQT Gurke (Zuhause)Mikrotik simuliert hier LTE Router (Garten)
WG und Ping Checks Server (Zuhause)
root@wgserver:~# wg show
interface: wg0
public key: RrGL5FfK5JBrBphqDLJd2LZ7driKX4kq89CBW9tAVAo=
private key: (hidden)
listening port: 51820
peer: IeWEMJqQng8AJoX7jwXFf6He7aqaRR3VI3EZ+/Dju0w=
endpoint: 10.99.1.149:47674
allowed ips: 100.64.64.101/32, 192.168.88.0/24
latest handshake: 1 minute, 6 seconds ago
transfer: 2.07 KiB received, 2.02 KiB sent
peer: r+REuxk9R4U9Jbub7zMB1RA2ki/LH/j4fnrSRRHIu2w=
endpoint: 10.1.1.100:62058
allowed ips: 100.64.64.102/32
latest handshake: 2 minutes, 25 seconds ago
transfer: 1.30 KiB received, 1.21 KiB sent
root@wgserver:~# ping -c 3 192.168.88.1
PING 192.168.88.1 (192.168.88.1) 56(84) bytes of data.
64 bytes from 192.168.88.1: icmp_seq=1 ttl=63 time=4.46 ms
64 bytes from 192.168.88.1: icmp_seq=2 ttl=63 time=3.68 ms
64 bytes from 192.168.88.1: icmp_seq=3 ttl=63 time=3.78 ms
--- 192.168.88.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 3.678/3.969/4.455/0.345 ms
WG und Ping Checks Client (Garten)
root@wgclient:# wg show
interface: wg0
public key: IeWEMJqQng8AJoX7jwXFf6He7aqaRR3VI3EZ+/Dju0w=
private key: (hidden)
listening port: 47674
peer: RrGL5FfK5JBrBphqDLJd2LZ7driKX4kq89CBW9tAVAo=
endpoint: 10.99.1.143:51820
allowed ips: 100.64.64.1/32, 100.64.64.102/32, 192.168.188.0/24
latest handshake: 1 minute, 10 seconds ago
transfer: 56.38 KiB received, 56.52 KiB sent
persistent keepalive: every 25 seconds
root@wgclient:/# ping -c 3 192.168.188.1
PING 192.168.188.1 (192.168.188.1) 56(84) bytes of data.
64 bytes from 192.168.188.1: icmp_seq=1 ttl=63 time=2.92 ms
64 bytes from 192.168.188.1: icmp_seq=2 ttl=63 time=3.30 ms
64 bytes from 192.168.188.1: icmp_seq=3 ttl=63 time=3.23 ms
--- 192.168.188.1 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5009ms
rtt min/avg/max/mdev = 2.840/3.066/3.296/0.182 ms
WG und Ping Checks mobiler Client (Windows)
Fazit
Works as designed ! 👍 😉Roadwarrior kann im Garten nur den Pi und die Gateway (LTE Router) erreichen, keine Clients im restlichen Netz
Sind das Windows Rechner?? Und...was meinst du genau mit "Erreichen". Ping??Wenn das Windows Rechner sind bedenke 2 Dinge:
- Die lokale Win Firewall blockt generell den Zugang aus fremden IP Netzen. Das ist bei dir ja der Fall wenn du von Roadwarrior oder Zuhause Netz zugreifst. Ggf. musst du also die Firewall anpassen. (Firewall mit erweiterter Sicherheit)
- Ping nutzt ICMP als Protokoll. Die Windows Firewall blockt generell ICMP im Default. Siehe HIER. Also auch hier ggf. anpassen
Es ist möglich das du am LTE Router dort die statische Route in das 172.31.0.0 /24 Netz mit Gateway=Pi IP vergessen hast und/oder diese Route nicht greift wegen Tippfehler, falscher Maske usw.
Den Symptomen nach spricht vieles dafür.
Im Zweifel immer strategisch vorgehen und mit apt install tcpdump einen Paket Sniffer auf dem Pi installieren und einmal an dessen LAN Port checken ob dort die vom VPN kommenden Pakete an die Endgeräte im Garten rausgehen.
Dann auch auf einem der Endgeräte die nicht erreichbar sind mit einem Wireshark oder tcpdump checken ob die Roadwarrior Pakete dort eingehen und auch beantwortet werden.
Ist das der Fall kann es nur noch an der fehlerhaften statischen Route auf dem LTE Router liegen oder eben der lokalen Firewall an diesen Geräten.
Pi Garten
Da fehlen ja deine Zuhause IP Netze in den Allowed IPs des Garten Pis!! Das lokale .10er VLAN dort hattest du ja auch erlaubt. Zumindestens also der .15er mit dem Server fehlt und dann ist klar warum es scheitert weil der Server ja dein zentraler Zugangspunkt ist und er OHNE diese Einträge diese IP Netze unereichbar macht fürs Gartennetz!Richtig im Garten Pi ist also:
AllowedIPs = 100.64.64.1/32, 100.64.64.102/32, 100.64.64.103/32, 100.64.64.104, 192.168.15.0/24, 192.168.10.0/24
Sie sind schon wieder NICHT drin oder welchen tieferen Sinn hat es das du hier immer und immer wieder sinnfrei die FALSCHE Konfig für den Garten postest?!
Wie gesagt:
Du kannst das alternativ wasserdicht checken indem du eines der Gartenendgeräte (Kamera, etc) einmal das Default Gateway testweise direkt auf den Pi setzt. Dann müssen diese nicht über die statische Route geroutet werden.
Wenn es dann immer noch nicht gehen sollte hast du ein generelles Problem irgendwo, denn das Setup rennt ja nachweislich fehlerlos wie du oben selber sehen kannst.
Wie gesagt:
- Allowed IPs (Garten) zwingend korrigieren
- Statische Route (Garten) checken
- Pakete im Gartennetz sniffern
Du kannst das alternativ wasserdicht checken indem du eines der Gartenendgeräte (Kamera, etc) einmal das Default Gateway testweise direkt auf den Pi setzt. Dann müssen diese nicht über die statische Route geroutet werden.
Wenn es dann immer noch nicht gehen sollte hast du ein generelles Problem irgendwo, denn das Setup rennt ja nachweislich fehlerlos wie du oben selber sehen kannst.
Dann hast du doch deinen phösen Buhmann!!
Es ist dann entweder der LTE Router der nicht richtig routet oder wo die Zuhause und WG Routen falsch eingetragen sind. Letzteres kann man aber ausschliessen wenn der Screenshot von oben noch stimmt, denn da ist es korrekt.
Oder das NAS hat einen fehlenden oder falschen Gateway Eintrag gehabt.
Eins von beiden muss es ja sein?!
Es ist dann entweder der LTE Router der nicht richtig routet oder wo die Zuhause und WG Routen falsch eingetragen sind. Letzteres kann man aber ausschliessen wenn der Screenshot von oben noch stimmt, denn da ist es korrekt.
Oder das NAS hat einen fehlenden oder falschen Gateway Eintrag gehabt.
Eins von beiden muss es ja sein?!