Wireguard VPN mit Gl-inet MT300N und Fritzbox

  • Ersteller Ersteller KeinNickFrei
  • Erstellt am Erstellt am
K

KeinNickFrei

Gast
Hallo zusammen,

ich würde mir gerne ein Site-2-Site VPN via Wireguard aufbauen, um meine Wohnung und das Netzwerk bei meinen Eltern zu vernetzen. Leider happert es bei mir und Netzwerkthemen immer wieder...

Ausgangsbasis: Mir wurde empfohlen, 2 Gl Inet MT300N (https://www.gl-inet.com/products/gl-mt300n/) , die auf OpenWrt basieren und Wireguard out-of-the-box unterstützen, zu verwenden.
In Folge WGServer und WGClient genannt. Netzwerk bei mir in der Wohnung ( ServerLAN 192.168.179.xxx /24) und bei meinen Eltern ( ClientLAN)
Momentan teste ich bei mir mittels USB Tethering (Handy) und simuliere das ClientLAN. Das sollte ja dynamisch funktionieren...

In meiner Wohnung habe ich eine Fritzbox 6340 mit public IPv4. In Folge Fritzbox und public IPv4 123.123.123.123 genannt (ist natürlich nicht die richtige)

Bis jetzt findet zwar eine Verbindung zwischen den beiden Geräten statt (laut Webinterface der MT300N), aber
1) ich musste den WGServer als exposed Host angeben. Einzelne Portfreigaben leider bisher nicht funktional
2) Von Site-2-Site kann keine Rede sein... natürlich will ich vom ClientLAN aus auch das ServerLAN erreichen können und umgekehrt... was für mich ja die Idee hinter dem ganzen ist. Das schaffe ich leider nicht.


Konfigs:

Wireguard:

WGServer = 10.0.0.1/32
WGClient = 10.0.0.2/32
ListenPort = 13967
DNS = 64.6.64.6
EndpointHost = PublicIPv4:51820
AllowedIPs: 0.0.0.0/0
KeepAlive 25

An der Fritzbox hätte ich folgendes versucht:

AktivBezeichnungProtokollPortan Computeran Port
WireGuardUDP13967192.168.179.2051820
WireGuard2UDP63535192.168.179.2051820

bzw. auch weitere Variationen...

Kann mir jemand Tipps geben, was ich für die Lösung der beiden Probleme versuchen kann?

Many THX in Advance!!
 
Zuletzt bearbeitet von einem Moderator:
Hast du sicherlich dran gedacht, aber zur Sicherheit frage ich mal: Keiner der beiden Standorte steht hinter einer DSLite Verbindung, oder?

Edit: Ist sicher Quatsch, du hast ja bereits ne Verbindung herstellen können.
 
Hallo, ich verstehe gerade nicht, warum du "Konfigs:" schreibst und dann einen Mischmasch aus der WireGuard-Konfiguration von Server + Client postest.

In diesem Fall hast du js ein Server-Client-Setup, wo der WireGuard-Client (aktiv) eine Verbindung zum WireGuard-Server aufbaut.

Die IP-Adresse + Port des WireGuard-Servers muss dem WireGuard-Client in seiner Konfiguration natürlich mitgeteilt werden. Ansonsten weiß er ja nicht, wohin er eine Verbindung aufbauen soll. Die Angabe des WireGuard-Servers + Port erfolgt mit der Option "EndpointHost".

Wenn deine FritzBox z.B. die (fiktive) öffentliche IP-Adresse "123.123.123.123" hat und du im WireGuard-Client als "EndpointHost" die "123.123.123.123:51820" angegeben hast, dann muss auf deiner FritzBox eine entsprechende Portweiterleitung (DNAT-Regel) erstellt werden, die den UDP-Port 51820 der WAN-IP-Adresse der FritzBox an IP-ADRESSE-DES-WIREGUARD-SERVERS:WIREGUARD-SERVER-PORT weiterleitet.

Der WireGuard-Server-Port ist der UDP-Port, den du über die Option "ListenPort" in der Konfiguration des WireGuard-Servers angegeben hast.

Die beiden Portweiterleitungen, die du gepostet hast, leiten UDP-Port 13967 bzw. UDP-Port 63535 an die 192.168.179.20:51820 weiter. In beiden Fällen wird der WireGuard-Client keine Verbindung zum WireGuard-Server aufbauen können, da er selbst eine Verbindung zu 123.123.123.123:51820 (Angabe des "EndpointHost" in der Konfiguration des WireGuard-Clients) aufbaut.

Du erwähntest, dass das Netzwerk auf der Seite des WireGuard-Servers das Netz "192.168.179.xxx/20" ist.
Bist du dir sicher, dass du auf der Server-Seite dieses Netz hast?
Eine IP-Adresse nach dem Schema 192.168.179.xxx/20 gehört zum Netz 192.168.176.0/20 (Netzadresse + Subnetzmaske des Netzes auf der Server-Seite).
Kann es sein, dass du auf der Server-Seite das Netz 192.168.179.0/24 hast!?

Noch ein Hinweis zu der Angabe "AllowedIPs" auf der Server- sowie auf der Client-Seite:
Diese Angabe gibt an, welche Quell-IP-Adresse über den WireGuard-Tunnel eingehend erlaubt sind bzw. welche IP-Adressen / Netze über den WireGuard-Tunnel geroutet werden.

Eine Angabe von "0.0.0.0/0" würde einen "Full-Tunnel" erzeugen, wodurch nach dem Aufbau des WireGuard-Tunnels sämtlicher IPv4-Traffic durch den WireGuard-Tunnel geroutet würde. Sprich, auch wenn du nach dem Aufbauen des Tunnels Webseiten über deinen Internet-Browser aufrufst ... auch dieser (IPv4)-Traffic würde dann über den Tunnel geroutet werden. Nach den Angaben, die du gemacht hast, ist aber das Routen des Internet-Traffics über den Tunnel gar nicht gewünscht. Es würde also ausreichen, dass ausschließlich das WireGuard-Netz sowie die beiden LAN-Netze der beiden Seiten über den Tunnel geroutet werden.

Dafür müsstest du folgende Angaben bei "AllowedIPs" auf der Seite des Servers bzw. des Clients machen.

Server-Seite:
AllowedIPs=10.0.0.2/32,ClientLAN (welches Netz das "ClientLAN" ist, hast du bisher leider nicht erwähnt)

Client-Seite:
AllowedIPs=10.0.0.1/32,ServerLAN (wie oben erwähnt bitte nochmal prüfen, welches Netz du auf der Server-Seite hast)
 
  • Gefällt mir
Reaktionen: KeinNickFrei und johnyb0y
Hallo zusammen,

danke für die Antworten

@johnyb0y
DSLite ist in Deutschland, soweit ich weiß. Ich bin in Österreich und mir wäre das jetzt nicht bekannt. Aber wie du schon schreibst - eine Verbindung der beiden Wireguard/OpenWRT Geräte besteht bereits

Datax schrieb:
Hallo, ich verstehe gerade nicht, warum du "Konfigs:" schreibst und dann einen Mischmasch aus der WireGuard-Konfiguration von Server + Client postest.

Ja, es ist streng genommen nur bisher 1 Konfig (ohne s) und ich habe erstmal nur ein paar Daten abgetippt und nicht das ganze Konfigscript kopiert.
Beim erstellen des WG Servers macht der MT300N gleich ein paasendes Konfigscript für den Client, das ich 1:1 übernehmen kann und auch so gemacht habe. Von daher stimmt (auch nach Kontrolle) die Angabe von EndpointHost, ...

Der UDP Port ist 51820 und den habe ich an der Fritzbox ja so freigegeben. Leider reicht das so nicht, wie ich eingangs versucht habe zu beschreiben.
Jetzt habe ich mal 51820 an den WGServer weitergeleitet:

AktivBezeichnungProtokollPortan Computeran Port
WireGuardUDP51820PC-192-168-179-2051820

...was ich auch schon versucht hatte, aber leider fehlschlägt.
Aber grundsätzlich logisch, schließlich wird ja an diesen Port erst an der Fritzbox angedockt, die das dann weiterleiten muss an den selben Port des WGservers. Ich dachte, in der Konfig würde man die Fritzbox transparent behandeln, damit man auch den Quellport angeben kann/muss...



Und ich hatte einen Fehler - es ist natürlich /24 Netz, kein /20. Mein Tippfehler

Im ersten Setup ist es tatsächlich gewünscht, alles über den Tunnel zu routen. Ich würde dafür erstmal nur ein NAS auf der einen Seite (ServerLAN) betreiben und vom ClientLAN aus (ggf. mit umstecken) darauf zugreifen.
Einsatzzweck also zb. von einem Extra Notebook im ClientLAN auf das NAS im ServerLAN zugreifen, ...
Schrittweise dann anpassen, ändern. Aber erst soll mal das funktionieren.

Das meiste hab ich so auf Standard belassen, da man mir sagte, dass das der MT300N schon richtig vorgibt.....

Ansonsten schon mal VIELEN DANK für die umfangreiche Antwort!


Edit:
Ich glaube, da gibt es eher Probleme mit der Fritzbox selbst...

Edit2:
OK, die Portfreigabe geht nun. Irgendwie hatte sie sich wohl aufgehängt...
Punkt 2 steht nun noch aus

Im Setup versuche ich nun als ClientLAN meinen Smartphone Hotspot, welcher ein 192.168.42.xxx/24 ausgibt.
Das NAS kann ich leider nicht erreichen.

Folgende Instanzen:

192.168.9.118 /24 --> dyn. IP Client LAN für den Laptop, mit dem ich Enduser ClientLAN simuliere
192.168.9.1 --> StandardGateway WGClient / MT300N im ClientLAN
192.168.42.17 /24 --> dyn IP vom Tethering für den WGClient
192.168.42.129 --> StandardGateway des Hotspot Tethering
10.0.0.2/32 --> IP laut Wireguard Konfig am WGClient
..... --> irgendwo dazwischen sollte das weite Internet sein...
10.0.0.1/32 --> IP laut Wireguard Konfig am WGServer
192.168.178.1 --> die Fritzbox
192.168.178.32/24 --> IP von der Fritzbox für den WGServer habe jetzt auf das andere Segment geschwenkt. Nicht mehr Gästenetz der Fritzbox
192.168.8.1 --> Standardgateway WGServer im ServerLAN
192.168.8.220 / 24 --> IP des NAS, vom WGServer zugewiesen

.... und eigentlich sollte ich von 192.168.9.118 aus die 192.168.8.220 ja erreichen können, in der Theorie, oder?
 
Zuletzt bearbeitet von einem Moderator:
Also die Endgeräte auf beiden Seiten haben jeweils den GL.inet-Router als Gateway!?

Ob es tatsächlich funktioniert, hängt natürlich von deinen WireGuard-Configs auf beiden Seiten ab.
Diese hast du hier ja nicht gepostet bzw. nur unvollständig.

Wird denn der WireGuard-Tunnel erfolgreich aufgebaut oder wie weit bist du mit der Umsetzung?

Falls du per Ping-Befehl über den WireGuard-Tunnel versuchst einen Windows-PCs auf der anderen Seite anzupingen, dann beachte bitte, dass die "Windows Firewall" standardmäßig ICMP-Traffic aus fremden Subnetzen blockiert. Für die Ping-Tests musst du also temporär die Windows-Firewall abschalten, später bitte wieder einschalten ;).
 
Hallo zusammen,

ich hänge mich einfach mal an den Thread. Ich möchte mich mittels Wiregaurad VPN auf mein Hausnetzwerk zugreifen und kämpfe aktuell mit folgendem Problem:
Der Brume sitzt hinter der FB und soll als Wireguard Server genutzt werden.

Mein vorgehen war bisher wie gehabt:
WAN-Port des Brume in den Swicht, LAN-Port des Brume in meinen PC.
Nach dem ich den Brume über die Oberfläche eingerichtet habe, wurde ihm eine fest IP in der FitzBox vergeben und der UDP-Port 51820 freigegeben.
Nun habe ich mein Iphone über den QR-Code eingerichtet, und die Ziel-IP gegen meine DynDNS Adresse getauscht.

IP der FB 192.168.178.1
Zugewiesene IP des Brume in Heimnetz 192.168.178.2
Netz des Brume 192.168.8.1
VPN Netz 10.0.0.1

Mein Problem ist nun, dass ich zwar mich per VPN auf den Brume komme, aber in meinem Hausnetz auf nichts zugreifen kann. Internetseiten werden problemlos aufgelöst. Mir ist klar, dass ich durch den Brume doppeltes NAT habe, ebenfalls bin ich mir bewusst, dass ich mich im "VPN-Netz" befinde.

Ich habe mit Iphone, Ipad, und den GL-i.Net Slate alles eingerichtet bei allen 3 Clients das selbe Problem.

Hier beispielhaft das JSON-File für den Slate

{
"address": "10.0.0.5/32",
"allowed_ips": "0.0.0.0/0",
"end_point": "XXX.XX:51820",
"dns": "64.6.64.6",
"listen_port": "57736",
"persistent_keepalive": "25",
"private_key": "XXX",
"public_key": "XXX"
}

Wer kennt die Problematik und kann mit weiterhelfen?
 
Ich kenne mich mit Wireguard und dessen Konfiguration nicht aus, aber das Routing muss stimmen.

a) Der VPN-Client benötigt eine Route ins Subnetz des Heimnetzwerks 192.168.178.0/24 via VPN-Server
b) Die Geräte im Heimnetzwerk benötigen eine Route ins Subnetz des VPNs 10.0.0.0/24 via LAN-IP des VPN-Servers

Ersteres wird in der Regel dadurch erreicht, dass der VPN-Server als Standardgateway verwendet wird (über die VPN-Konfiguration einstellbar). Letzteres wiederum dadurch, dass im Router des Heimnetzwerks eine statische Route ins VPN eingerichtet wird. Du kannst prüfen ob das Routing in Ordnung ist, wenn du unter Windows in der Eingabeaufforderung "tracert 10.0.0.x" oder andersherum eben "tracert 192.168.178.x" eingibst. Das x natürlich entsprechend nach einer gültigen IP wählen.
 
@ Rajin: vielen Dank für dein Feedback! Mein Problem scheint gelöst.

Ich habe in JSON-File sowie auf IPhone und IPad den DNS 64.6.64.6 auf 192.168.178.1 (IP der FritzBox) geändert. Nun klappt der Zugriff aufs Heimnetz.

Statische Route ins Subnetz 10.0.0.0/24 ist doch überflüssig, oder? Der Brume macht NAT am WAN Port. Er setzt Das gesamte 10.0.0.0 /24er Netz wird auf seine WAN Port IP 192.168.178.2 umgesetzt . Die FritzBox hat also gar keine Ahnung das dort Clitens aus dem 10er Netz sind, da diese alle mit der IP des Brume in ihrem Netz auftauchen.
 
Zuletzt bearbeitet:
Wenn man VPN mit NAT konfiguriert, braucht man keine Routen im Remote-Netz, das ist korrekt. Allerdings ist das nicht empfehlenswert, weil man durch das NAT ein Stück Kontrolle über das Netzwerk aufgibt. Einem Zielgerät im Remote-Netz ist es somit nicht möglich, zwischen Anfragen aus dem lokalen Subnetz oder aus dem VPN zu unterscheiden.

Bezüglich "kein Zugriff" und "ich habe den DNS geändert": Das hat nichts miteinander zu tun. DNS ist die Namensauflösung und der Zugriff definiert sich durch die Funktionalität von IP-Verbindungen.
 
Zurück
Oben