3
Netz hinter Wireguard-Client erreichen
Hallo Zusammen,
ich stehe vor dem Problem dass ich ein an einem WG-Client angeschlossenes Netzwerk von meinem Heimnetzwerk bzw. von anderen WG-Clients erreichen möchte.
Der Wireguard-Server läuft bei mir zu Hause auf einem Mikrotik-Router. Ich kann mich von sämtlichen Clients zu diesem Verbinden und auch die WG-Clients sehen sich untereinander.
Nun möchte ich das Netzwerk welches über eine zweite Netzwerkkarte an einem WG-Client angeschlossen ist erreichen.
Hierzu habe ich mal eine Zeichnung erstellt.
Zur info: Die Bezeichnung "enx000ec68e333e" ist die Netzwerkkarte im 172.16.245.0/24-Netz
Auf dem Mikrotik habe ich eine statische Route zum Netzwerk 172.16.245.0/24 eingerichtet über das Gateway 10.31.5.5
Der WG-Client macht ein "Natting" in das Netz und zeigt sich dort mit der 172.16.245.205. Dadurch kann ich doch auf Rückrouten verzichten, da die Clients im Netzt 172.16.245.0/24 ja nur mit der .205 kommunizieren oder?
Wenn ich ein Traceroute auf einem Client im Netz 10.31.2.0/24 zu einer Adresse im im Netz 172.16.245.0/24 durchführe, bleibt er immer am Mikrotik hängen.
Habe ich irgendwo ein Denkfehler oder funktioniert das auf dem Mikrotik so nicht?
Hier die WG-Config des Clients
(Die Keys und die Public-Adresse des WG-Servers habe ich entfernt)
Schonmal besten Dank!
ich stehe vor dem Problem dass ich ein an einem WG-Client angeschlossenes Netzwerk von meinem Heimnetzwerk bzw. von anderen WG-Clients erreichen möchte.
Der Wireguard-Server läuft bei mir zu Hause auf einem Mikrotik-Router. Ich kann mich von sämtlichen Clients zu diesem Verbinden und auch die WG-Clients sehen sich untereinander.
Nun möchte ich das Netzwerk welches über eine zweite Netzwerkkarte an einem WG-Client angeschlossen ist erreichen.
Hierzu habe ich mal eine Zeichnung erstellt.
Zur info: Die Bezeichnung "enx000ec68e333e" ist die Netzwerkkarte im 172.16.245.0/24-Netz
Auf dem Mikrotik habe ich eine statische Route zum Netzwerk 172.16.245.0/24 eingerichtet über das Gateway 10.31.5.5
Der WG-Client macht ein "Natting" in das Netz und zeigt sich dort mit der 172.16.245.205. Dadurch kann ich doch auf Rückrouten verzichten, da die Clients im Netzt 172.16.245.0/24 ja nur mit der .205 kommunizieren oder?
Wenn ich ein Traceroute auf einem Client im Netz 10.31.2.0/24 zu einer Adresse im im Netz 172.16.245.0/24 durchführe, bleibt er immer am Mikrotik hängen.
Habe ich irgendwo ein Denkfehler oder funktioniert das auf dem Mikrotik so nicht?
Hier die WG-Config des Clients
[Interface]
Address = 10.31.5.5/24
PrivateKey =
DNS = 10.31.2.4
[Peer]
PublicKey =
AllowedIPs = 10.31.0.0/16
Endpoint =
PersistentKeepalive = 25Schonmal besten Dank!
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: 7372169266
Url: https://administrator.de/contentid/7372169266
Ausgedruckt am: 22.11.2024 um 09:11 Uhr
3 Kommentare
Neuester Kommentar
Die Antworten zu deinen Fragen stehen alle im Wireguard Tutorial:
Merkzettel: VPN Installation mit Wireguard
Die Lösung ist sehr einfach, denn du musst das Netzwerk 172.16.245.0/24 der "AllowedIPs" Definition im Server, sprich also deinem Mikrotik hinzufügen!
Erst das bewirkt das VPN Traffic für dieses Zielnetz überhaupt in den WG Tunnel geroutet wird vom Server. (Crypto Routing von Wireguard). Leider fehlt hier der Screenshot vom MT.
Ist aber alles im Tutorial und den weiterführenden Links erklärt. Z.B. an einem ähnlichen Beispiel mit dem MT als WG Server.
Das Masquerading (NAT) im VPN Tunnel ist immer kontraproduktiv und sollte man niemals machen. Es würde nur dann Sinn machen wenn du allein nur mit Clients immer auf ein Zielnetz arbeitest. Bei einer S-2-S Kopplung bekommst du mit Source NAT (Masquerading) immer eine routingtechnische Einbahnstrasse.
Abgesehen von der Verschlechterung der Performance, wird diese Einbahnstrasse im Routing durch ein nicht zu überwindendes Blocking eingehender Sessions im NAT Gateway erzeugt.
Sessions die aus diesem Netzwerk initiiert werden bleiben am NAT Gateway hängen und transparentes Site-to-Site Routing beider IP Netze wird damit unmöglich.
Auch das solltest du auf dem Radar haben!
Zudem ist die Angabe der Subnetzmaske des internen WG Netze in deinen Client AllowedIPs nur dann so richtig wenn du eine Any to Any Kommunikation der Clients wünschst. Andernfalls arbeitet man dort immer mit 32 Bit Host Prefixes. Über den Sinn und Unsinn einer 16 Bit Maske dort jetzt mal nicht zu reden.
Merkzettel: VPN Installation mit Wireguard
Die Lösung ist sehr einfach, denn du musst das Netzwerk 172.16.245.0/24 der "AllowedIPs" Definition im Server, sprich also deinem Mikrotik hinzufügen!
Erst das bewirkt das VPN Traffic für dieses Zielnetz überhaupt in den WG Tunnel geroutet wird vom Server. (Crypto Routing von Wireguard). Leider fehlt hier der Screenshot vom MT.
Ist aber alles im Tutorial und den weiterführenden Links erklärt. Z.B. an einem ähnlichen Beispiel mit dem MT als WG Server.
Das Masquerading (NAT) im VPN Tunnel ist immer kontraproduktiv und sollte man niemals machen. Es würde nur dann Sinn machen wenn du allein nur mit Clients immer auf ein Zielnetz arbeitest. Bei einer S-2-S Kopplung bekommst du mit Source NAT (Masquerading) immer eine routingtechnische Einbahnstrasse.
Abgesehen von der Verschlechterung der Performance, wird diese Einbahnstrasse im Routing durch ein nicht zu überwindendes Blocking eingehender Sessions im NAT Gateway erzeugt.
Sessions die aus diesem Netzwerk initiiert werden bleiben am NAT Gateway hängen und transparentes Site-to-Site Routing beider IP Netze wird damit unmöglich.
Auch das solltest du auf dem Radar haben!
Zudem ist die Angabe der Subnetzmaske des internen WG Netze in deinen Client AllowedIPs nur dann so richtig wenn du eine Any to Any Kommunikation der Clients wünschst. Andernfalls arbeitet man dort immer mit 32 Bit Host Prefixes. Über den Sinn und Unsinn einer 16 Bit Maske dort jetzt mal nicht zu reden.
Mikrotik WG Server Config
Ubuntu WG Client Config
NAT am Ubuntu weg (kontraproduktiv wenn man routen kann) und am Default-GW des Ubuntu-Netzes eine Static-Route für 10.31.2.0/24 mit GW auf den Ubuntu (172.16.245.205) setzen, feddisch.
Natürlich musst du auch das Forwarding in der Firewall des Mikrotik für die eingesetzten Netze freischalten! Genauso die Firewall im Ubuntu muss das Forwarding für die Netze erlauben.
Firewalls der Clients beachten dort müssen unter Windows SMB/ICMP/etc. andere Subnetze als die eigenen zugelassen werden!
Gruß
/interface wireguard add disabled=no listen-port=60123 mtu=1420 name=wg0
/interface wireguard peers add allowed-address=10.31.5.5/32,172.16.245.0/24 disabled=no interface=wg0 public-key="xxxxxxxxxxxxxxxxxxxxx"
/ip address add address=10.31.5.1/24 interface=wg0 network=10.31.5.0
/ip route add dst-address=172.16.254.0/24 gateway=10.31.5.5Ubuntu WG Client Config
[Interface]
PrivateKey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Address = 10.31.5.5/24
[Peer]
PublicKey = xxxxxxxxxxxxxxxxxxxxxxxxxxxx
AllowedIPs = 10.31.5.1/32,10.31.2.0/24
Endpoint = x.x.x.x:60123
PersistentKeepalive = 25NAT am Ubuntu weg (kontraproduktiv wenn man routen kann) und am Default-GW des Ubuntu-Netzes eine Static-Route für 10.31.2.0/24 mit GW auf den Ubuntu (172.16.245.205) setzen, feddisch.
Natürlich musst du auch das Forwarding in der Firewall des Mikrotik für die eingesetzten Netze freischalten! Genauso die Firewall im Ubuntu muss das Forwarding für die Netze erlauben.
Firewalls der Clients beachten dort müssen unter Windows SMB/ICMP/etc. andere Subnetze als die eigenen zugelassen werden!
Gruß
1
Zitat von @aqui:
Die Antworten zu deinen Fragen stehen alle im Wireguard Tutorial:
Merkzettel: VPN Installation mit Wireguard
Die Lösung ist sehr einfach, denn du musst das Netzwerk 172.16.245.0/24 der "AllowedIPs" Definition im Server, sprich also deinem Mikrotik hinzufügen!
Super! Genau das hat gefehlt! Besten DankDie Antworten zu deinen Fragen stehen alle im Wireguard Tutorial:
Merkzettel: VPN Installation mit Wireguard
Die Lösung ist sehr einfach, denn du musst das Netzwerk 172.16.245.0/24 der "AllowedIPs" Definition im Server, sprich also deinem Mikrotik hinzufügen!
Das Masquerading (NAT) im VPN Tunnel ist immer kontraproduktiv und sollte man niemals machen. Es würde nur dann Sinn machen wenn du allein nur mit Clients immer auf ein Zielnetz arbeitest. Bei einer S-2-S Kopplung bekommst du mit Source NAT (Masquerading) immer eine routingtechnische Einbahnstrasse.
Ja das ist so gewünscht, ich greife nur von zu Hause bzw. unterwegs drauf zu. Zugriff vom 172.16.245.0er Netz in mein Heimnetz ist nicht vorgesehen. Ist auch nur ein temporäres Setup.Zudem ist die Angabe der Subnetzmaske des internen WG Netze in deinen Client AllowedIPs nur dann so richtig wenn du eine Any to Any Kommunikation der Clients wünschst. Andernfalls arbeitet man dort immer mit 32 Bit Host Prefixes. Über den Sinn und Unsinn einer 16 Bit Maske dort jetzt mal nicht zu reden.
Vielen Dank für Eure Hilfe!
