21.06.2022, aktualisiert am 21.08.2022

6782

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

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

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

Ausgedruckt am: 25.04.2024 um 13:04 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...

Hallo aqui, danke für deine Antwort.

Also ich sehe das wirklich nur als Lern- und Spielprojekt weil ich die Pi`s liegen habe und ich mich gerne mal damit beschäftigen wollte in Kombination mit Wireguard. Ich verbinde ja nur "nur" den Kleingarten mit Zuhause

.
Das der Unifi einen VPN Server hat ist bekannt, aber wie oben schon geschrieben ... Lern- und Spielprojekt.

Ich habe deinen Rat angenommen und habe auf beiden Seiten die Zeilen in den .conf entfernt und natürlich auch das Tutorial von oben gelesen. Also das mit dem NAT habe ich in so vielen Anleitungen dazu gelesen, daher habe ich es auch aktiviert. War dann ein Fehler von mir. Warum auf dem Pi Zuhause zwei wg Interface sind, ist auch aus googlen entstanden. Dort hieß es, es sei sinnvoll die site2site und die Roadwarrior zu trennen und dafür ein wg1 erzeugen.
Werde das auch anpassen wenn die Site2Seite wieder richtig läuft, dazu komme ich jetzt.

Die Konfig bei den beiden Pi`s für die site2site sieht jetzt so aus:

Pi Zuhause (192.168.15.1)
wg0

[Interface]
Address = 172.31.0.1/24
ListenPort = 51820
PrivateKey = MEIN KEY

[Peer]
PublicKey = MEIN KEY
AllowedIPs = 192.168.50.0/24, 172.31.0.0/24
PersistentKeepalive = 25

Pi Garten (192.168.50.1)
wg0

[Interface] 
PrivateKey = MEIN KEY 
Address = 172.31.0.2/24 

[Peer] 
PublicKey = MEIN KEY 
Endpoint = wireguard.xxxxx-xxxxx.net:51820 
AllowedIPs = 192.168.10.0/24, 192.168.15.0/24, 172.31.0.0/24
PersistentKeepalive = 25

Ich habe auf der UBQT Routergurke statische Routen eingetragen:

192.168.50.0/24 | 192.168.15.1
172.31.0.0/24 | 192.168.15.1

Auf der Kiste im Garten auch

168.10.0/24 | 192.168.50.1
168.15.0/24 | 192.168.50.1
31.0.0/24 | 192.168.50.1

Ich erreiche jetzt von 192.168.10.0/24 & 192.168.15.0/24 per Ping ohne Probleme 192.168.50.10 (GW Garten) & 192.168.50.1 (Pi Garten). Den NAS und die Kameras im Garten erreiche ich per ping manchmal ja, manchmal nein. (EDIT: Gerade nochmal getestet, geht nicht)

Umgekehrt ist es auch so, ich erreiche von 192.168.50.0/24 per ping 192.168.10.10 & 192.168.15.10 & 192.168.15.1, den Rest in den Netzwerken allerdings auch nur sporadisch. (EDIT: Gerade nochmal getestet, geht scheinbar doch, aber erst nach x Ping-Versuchen)

Stelle ich die Pi`s wieder auf NAT, dann erreiche ich wieder alle, aber mit dem NAT ist es ja falsch. Wo ist da der Fehler?

Hier die Kommunikation von beiden Seiten, da läuft was falsch.

Site2Site Verbindung im Tunnel

Verbindung zur GW der Gegenseite

Verbindung zum NAS auf der Gegenseite

Verbindung von Pi zu Pi

iptables

ip r

Besten Dank

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.

Danke nochmal, dass du dir die Zeit nimmst zu helfen.

So, ich habe das mal genau so gebaut, wie du gesagt hast (hoffe ich).
Ich kann aus dem Zuhause den Garten nicht wirklich erreichen, der Tunnel steht aber, die Tunnel IPs gehen, daher komme ich über die Tunnel IP vonm PI im Garten auch noch via SSH drauf von Zuhause aus.

Das Notebook kann von extern auf Zuhause, kommt aber nicht in den Garten.

Route Zuhause auf UBQT Gurke
168.50.0/24 | 192.168.15.1
31.0.0/24 | 192.168.15.1

Route auf LTE Router im Garten
168.10.0/24 | 192.168.50.1
168.15.0/24 | 192.168.50.1
31.0.0/24 | 192.168.50.1

wg0.conf von beiden Seiten (letzten zwei Zeichen von den Key`s sind unkenntlich gemacht)

ip r

mtr

ping zwischen pi`s

Ping zum Roadwarrior

Roadwarrior Konfig

Ping vom Roadwarrior

route print vom Roadwarrior

Besten Dank

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:

die interne WG Server IP 172.31.0.1
die interne WG Garten IP 172.31.0.101
die lokale Garten IP .50.1

pingen ?

Damit das Drama hier mal ein Ende hat...

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 ! 👍 😉

Zitat von @aqui:

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.

Ist korrigiert

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??

Jap, war die erste Amtshandlung bei der Erstinstallation

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

pingen ?

Ich erreiche
172.31.0.1
172.31.0.101

.50.1 erreiche ich nicht

von 50.0
erreiche ich
172.31.0.1
172.31.0.101
192.168.15.1
192.168.15.10

Wenn sonst nichts hilft, werde ich am Wochenende alles nochmal neu machen müssen.

Mit der o.a. Anleitung dürfte dann sicher garantiert nix mehr schiefgehen...

Ich werde berichten, Danke

...und wir sind gespannt!

..ich glaube ich schmeiß es hin...

Ich habe deine Anleitung 3x auf frischen Pi`s auf beiden Seiten installiert und bekomme immer das gleiche Ergebnis.

Garten kann Zuhause komplett erreichen
Roadwarrior kann Zuhause komplett erreichen

Roadwarrior kann im Garten nur den Pi und die Gateway (LTE Router) erreichen, keine Clients im restlichen Netz
Zuhause kann im Garten nur den Pi und die Gateway (LTE Router) erreichen, keine Clients im restlichen Netz

Pi Zuhause -> Ping Pi Garten - OK
Pi Zuhause -> Ping Router Garten - OK (WebGUI geht auch)
Pi Zuhause -> Ping NAS Garten - Nicht OK
Pi Zuhause -> Ping Kamera Garten - Nicht OK
Pi Zuhause -> Ping Rest aus "Netz Garten" - Nicht OK (außer Pi & Router Garten)  

Pi Garten -> Ping Pi Zuhause - OK
Pi Garten -> Ping Unifi Zuhause - OK
Pi Garten -> Ping NAS Zuhause - OK
Pi Garten -> Ping Rest aus "Netz Zuhause" - OK  

Client Garten -> Ping Pi Zuhause - OK
Client Garten -> Ping Unifi Zuhause - OK
Client Garten -> Ping NAS Zuhause - OK
Client Garten -> Ping Rest aus "Netz Zuhause" - OK  

Client Zuhause -> Ping Pi Garten - OK
Client Zuhause -> Ping Router Garten - OK (WebGUI geht auch)
Client Zuhause -> Ping NAS Garten - Nicht OK
Client Zuhause -> Ping Kamera Garten - Nicht OK
Client Zuhause -> Ping Rest aus "Netz Garten" - Nicht OK (außer Pi & Router Garten)  

Roadwarrior -> Ping Pi Garten - OK
Roadwarrior -> Ping Router Garten - OK (WebGUI geht auch)
Roadwarrior -> Ping NAS Garten - Nicht OK
Roadwarrior -> Ping Kamera Garten - Nicht OK
Roadwarrior -> Ping Rest aus "Netz Garten" - Nicht OK (außer Pi & Router Garten)  
Roadwarrior -> Ping Pi Zuhause - OK
Roadwarrior -> Ping Unifi Zuhause - OK
Roadwarrior -> Ping NAS Zuhause - OK
Roadwarrior -> Ping Rest aus "Netz Zuhause" - OK  

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

Der Roadwarrior taucht im Gegensatz zum Zuhause Netz an den Garten Geräten dort mit einer internen VPN Absender IP auf (172.31.0.x).
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.

Mit Clients sind eigentlich meist nur Kameras, NAS oder IoT Geräte gemeint, welche ich PINGE und auf die dortigen Dienste zugreife, meiste die WebGUI. Daher fällt die Windows Firewall aus.

Hier nochmal die jetzige Konfig

Pi Garten

[Interface]
Address = 100.64.64.101/24
PrivateKey = AGa3+4cpuCLogvjvSzL2R18G9B4hfO3maazmQKONUVXX

[Peer]
PublicKey = n2Mj20Vg6637pg4hvItXr/6JQl1KiLviMPaml8OiiBXX
Endpoint = wireguard.xxxxx-xxxxx.net:51820
AllowedIPs = 100.64.64.1/32, 100.64.64.102/32, 100.64.64.103/32, 100.64.64.104/32, 192.168.15.0/24, 192.168.10.0/24
PersistentkeepAlive = 25

Route auf LTE im Garten

Pi Zuhause

[Interface]
Address = 100.64.64.1/24
PrivateKey = ULy78Gun6VuqVW6X97G1qkPgf5nyHSxbq7pxJt7jeFXX
ListenPort = 51820

[Peer]
PublicKey = m9w9wtqf0hFNI0EpW7egrI84r5JfD5wlfCBlgJEyRiXX
AllowedIPs = 100.64.64.101/32, 192.168.50.0/24

[Peer]
PublicKey = AaZoWzUzJ4YQ/7ANSxGsCeXC6dxHiyHknilLrYxbpHXX
AllowedIPs = 100.64.64.102/32

[Peer]
PublicKey = FIjjeJO5C6lk31E3tjF6uWNGsOdHCm1R8iNLMlVPvVXX
AllowedIPs = 100.64.64.103/32

[Peer]
PublicKey = NJs/mSwC/AnY0Z6Yq+pZaJyu7DnKlZbTg4sZRryR/mXX
AllowedIPs = 100.64.64.104/32

Route auf Unifi Zuhause

Roadwarrior

[Interface]
PrivateKey = SHtC1K9pe3rDaQCWt988a/GM9jwLgphn3TGPDKMkQkXX
Address = 100.64.64.104/24

[Peer]
PublicKey = n2Mj20Vg6637pg4hvItXr/6JQl1KiLviMPaml8OiiBXX
AllowedIPs = 100.64.64.1/32, 192.168.10.0/24, 192.168.15.0/24, 192.168.50.0/24
Endpoint = wireguard.xxxxx-xxxxx.net:51820

Wenn du auf Basis der Daten jetzt keinen Fehler siehst, dann ignoriere ich Wireguard jetzt 3 Tage und geh entspannt wieder dran mit tcmpdump & Co.

Habe auch beim NAS im Garten oder dem Kameras geschaut, ob die ein Ping aus einem fremden Netz misstrauen, aber die GUI`s gehen halt leider auch nicht.

Danke dir aber trotzdem sehr für deine Geduld, ich hoffe ich war nicht zu akribisch und habe dadurch einen Fehler übersehen.

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 

Da warst du wohl schon etwas betriebsblind vor lauter Verzweiflung, oder?!

Sorry, mein Fehler, da ist beim Copy & Paste ins Forum was falsch gelaufen

Die Konfiguration vom Pi Garten sieht die ganze Zeit so aus, die IPs sind bzw. waren drin und es klappt nicht.

[Interface]
Address = 100.64.64.101/24
PrivateKey = AGa3+4cpuCLogvjvSzL2R18G9B4hfO3maazmQKONUVXX

[Peer]
PublicKey = n2Mj20Vg6637pg4hvItXr/6JQl1KiLviMPaml8OiiBXX
Endpoint = wireguard.xxxxx-xxxxx.net:51820
AllowedIPs = 100.64.64.1/32, 100.64.64.102/32, 100.64.64.103/32, 100.64.64.104/32, 192.168.15.0/24, 192.168.10.0/24
PersistentkeepAlive = 25

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:

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.

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?!

Sorry, aber was meinst du? Im Garten auf dem Pi ist in der wg0.conf die ganze Zeit das:

AllowedIPs = 100.64.64.1/32, 100.64.64.102/32, 100.64.64.103/32, 100.64.64.104/32, 192.168.15.0/24, 192.168.10.0/24

Ich habe oben ausversehen aus Putty falsch kopiert...es aber korrigiert im Post. Im Pi wars immer so.

Du kannst das alternativ wasserdicht checken indem du eines der Gartenendgeräte (Kamera, etc) einmal das Default Gateway testweise direkt auf den Pi setzt.

Wenn ich dem NAS als GW die IP vom PI Garten gebe, dann kann ich diesen von Zuhause erreichen.

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

Ich vermute auch den LTE Router, alles andere kann ich jetzt echt ausschließen denke ich. Ich stehe auch kurz davor auf den LTE Router OpenWRT zu installieren (lese aber vorher noch ein wenig darüber), dann habe ich vielleicht Ruhe. Eine neue FW gibt es leider nicht für die billige LTE Kiste. Ich habe zumindest bei dem ganzen viel über WG gelernt dank deiner Geduld. Dafür besten Dank

Oder das NAS hat einen fehlenden oder falschen Gateway Eintrag gehabt.

Passt aber, die Kameras verhalten sich auch so, ändere ich die GW auf den PI, habe ich Ping von Zuhause in den Garten, stell ich es zurück, geht der Ping nicht mehr.

Du kannst den Gateway Eintrag der Gartengeräte auch allesamt auf den Pi umstellen.
Der hat ja selber wiederum eine Default Route auf den LTE so das es dann wieder passt.
So kannst du zumindestens ohne großen Aufwand das Problem umschiffen.

Ich habe auf den LTE Router jetzt OpenWRT installiert und bumm, es geht.
Der verdammte LTE Router hat das Routing mit der Stock FW nicht korrekt gemacht.