Stationary
Well-known member
Klingt auch falsch. Bei uns laufen vier Fritzboxen mit WG alle untereinander site-to-site verbunden.
Ich denke die Probleme treten eher im Zusammenspiel mit manchen anderen Routern auf.
WireGuard Verbindung Site2Site zwischen Fritzbox 7690 und Cudy LT500E
- Ersteller firechumper
- Erstellt am
Ich denke die Probleme treten eher im Zusammenspiel mit manchen anderen Routern auf.
Riewekooche
New member
Ich hahe man die "zweite Variante" ausprobiert. Das funktioniert auch.
Nur brauche ich es genau andersherum. D.h. ich möchte von meiner Fritzbox aus auf alle Geräte an dem Cudy zugreifen...
>>Die Fritzbox antwortet auch, aber nicht mit der IP die man angesprochen hat sondern mit einer anderen und damit kann der fragende nichts anfangen.
Da Site2Site zwischen Fritzboxen (z.B. 6591 und 7490) offensichtlich funktioniert, kann das wohl nicht an SourceNAT liegen.
Ich glaube eher, dass das Cudy noch irgendeine Hilfe braucht...
Nur brauche ich es genau andersherum. D.h. ich möchte von meiner Fritzbox aus auf alle Geräte an dem Cudy zugreifen...
>>Die Fritzbox antwortet auch, aber nicht mit der IP die man angesprochen hat sondern mit einer anderen und damit kann der fragende nichts anfangen.
Da Site2Site zwischen Fritzboxen (z.B. 6591 und 7490) offensichtlich funktioniert, kann das wohl nicht an SourceNAT liegen.
Ich glaube eher, dass das Cudy noch irgendeine Hilfe braucht...
DonnerGunther
New member
Naja, das Video ist eigentlich ziemlich eindeutig. Also zwischen Fritzboxen funktioniert Site-to-Site auf jeden Fall. Das habe ich auch schon ewig am Laufen. Also seit es WG für die Fritzbox gibt. Das wird in dem Video auch nicht verneint.
Im Video wird mit Wireshark genau dargestellt, was passiert. Und es gibt auch noch Folgevideos, die beschreiben, wie man das Ganze wieder brauchbar macht. Ihr müsst euch echt einfach das Video anschauen. Es liegt wirklich nur an der Antwort der Fritzbox.
Die Fritzbox antwortet einfach mit ihrer, ich denke, Public-IP oder der IP, die sie im Fremdnetz hat. Wenn ich das richtig verstanden habe, müsste man, sobald die Antwort von der Fritzbox mit der falschen IP am Cudy ankommt, wiederum ein IP-NAT machen, also die falsche IP wieder mit der richtigen austauschen. Dann sollte es meiner Meinung nach gehen. Aber ich bin kein Netzwerk-Pro …
Ich denke, wenn du jetzt z. B. aus dem Fritznetz an das Cudy-Netz Anfragen sendest, kann es auch gut sein, dass die Fritzbox die Anfragen dann mit ihrer falschen IP raus schickt. Damit weiß der Cudy dann nichts anzufangen. Wenn man dem Cudy aber sagt, dass er die falsche IP durch die richtige ersetzen soll, dann sollte es gehen. Es gibt auf jeden Fall in den Einstellungen im Cudy Möglichkeiten, die das Problem lösen könnten.
Im Video wird mit Wireshark genau dargestellt, was passiert. Und es gibt auch noch Folgevideos, die beschreiben, wie man das Ganze wieder brauchbar macht. Ihr müsst euch echt einfach das Video anschauen. Es liegt wirklich nur an der Antwort der Fritzbox.
Die Fritzbox antwortet einfach mit ihrer, ich denke, Public-IP oder der IP, die sie im Fremdnetz hat. Wenn ich das richtig verstanden habe, müsste man, sobald die Antwort von der Fritzbox mit der falschen IP am Cudy ankommt, wiederum ein IP-NAT machen, also die falsche IP wieder mit der richtigen austauschen. Dann sollte es meiner Meinung nach gehen. Aber ich bin kein Netzwerk-Pro …
Ich denke, wenn du jetzt z. B. aus dem Fritznetz an das Cudy-Netz Anfragen sendest, kann es auch gut sein, dass die Fritzbox die Anfragen dann mit ihrer falschen IP raus schickt. Damit weiß der Cudy dann nichts anzufangen. Wenn man dem Cudy aber sagt, dass er die falsche IP durch die richtige ersetzen soll, dann sollte es gehen. Es gibt auf jeden Fall in den Einstellungen im Cudy Möglichkeiten, die das Problem lösen könnten.
Riewekooche
New member
Ich hatte ja geschrieben, dass das Cudy LT300 abstürzt, wenn ich die Lan2Lan/Side2Side-Config der Fritzbox 6591 einlese und dann abspeichere.
Das Cudy kann ich dann nur mit einem Factory-Reset wiederbeleben (und muss dann alle Einstellungen neu configurieren...)
Kennt ihr das auch?
Wenn nicht, schreibt doch bitte man Eure Config hier zum Vergleichen rein.
(Lese ich eine Router-Single_Device-config ein, geht das ohne Absturz.)
Das Cudy kann ich dann nur mit einem Factory-Reset wiederbeleben (und muss dann alle Einstellungen neu configurieren...)
Kennt ihr das auch?
Wenn nicht, schreibt doch bitte man Eure Config hier zum Vergleichen rein.
(Lese ich eine Router-Single_Device-config ein, geht das ohne Absturz.)
DonnerGunther
New member
Das war bei mir genau das selbe. Also ich weiß nicht ob der Cudy wirklich abstürzt. Ich denke er schickt dann einfach alles an die Fritzbox was irgendwie zu ihm geschickt wird. D. H. wenn man versucht auf sein Web-Interface zu kommen, wird die Anfrage direkt zur Fritzbox getunnelt. Und von dort kommt sie nicht wieder zurück, weil eben die Fritzbox mit der falschen IP antwortet. Also so meine Vermutung.
Riewekooche
New member
Aber warum sollte das Cudy Zugriffe auf sein Web-Interface zur Fritzbox schicken?
Das Cudy erinnert mich stark an das Gewurschtel mit Wireguard und OpenWRT, wo man zig Einstellmöglichkeiten hatte, aber auch alles irgendwo klemmte.
Das Cudy erinnert mich stark an das Gewurschtel mit Wireguard und OpenWRT, wo man zig Einstellmöglichkeiten hatte, aber auch alles irgendwo klemmte.
blurrrr
Well-known member
Die Vermutung ist so wohl eher nicht richtig. Dazu sollte man ggf. nicht irgendwelche Videos gucken, sondern sich einfach mal mit Routing und NAT beschäftigen.
Grundsätzlich ist es normalerweise so, dass man....
a) 2 Standorte hat
b) jeder dieser Standorte hat einen Router
c) jeder dieser Router hat (mindestens) ein internes LAN
d) jeder dieser Router hat (mindestens) eine öffentliche IP (über welche die VPN-Verbindung initiiert wird)
Netz A -> Router A -> public IP A <---Internet---> public IP B <- Router B <- Netz B
Sobald die VPN-Verbindung aufgebaut wird... besteht neben o.g. noch folgendes:
f) gibt es ein weiteres Netz (das Tunnel-Netz)
g) hat jeder Router eine IP aus dem Tunnel-Netz
Netz A -> Router A -> private VPN-IP A <---VPN-Netz---> private VPN-IP B <- Router B <- Netz B
Bis zu diesem Zeitpunkt ist in Sachen VPN erstmal "garnichts" mit "NAT". NAT bzw. konkreter SNAT (Source-NAT/Quell-NAT) braucht man "nur" zwingend, wenn den externen Teilnehmern die IP eines z.B. Clients nicht bekannt ist bzw. konkreter die "Route" zum Ziel nicht bekannt ist.
Das ist bei internen Netzen bei Anfragen ins Internet z.B. so (bei IPv4). Üblicherweise hat man ein internes LAN aus dem Netzbereich 192.168.0.0/16 (z.B. Fritz!Box-Standard = 192.168.178.0/24). Die Clients bekommen eine IP aus diesem Netz (z.B. 192.168.178.100). Das "Problem" ist, dass wenn ein Client nun z.B. eine Website im Internet aufruft, die Antwort nicht wieder zurück kommen kann, denn der Webserver kennt die IP 192.168.178.100 nicht bzw. weiss nicht, wohin er seine Pakete schicken muss. Dazu kommt der Umstand, dass IP-Adressen privater Natur nicht im Internet weitergeleitet werden. Deswegen werden Pakete von privaten IP-Adressen i.d.R. vom Router umgeschrieben, wenn sie aus dem eigenen Netz kommen. Daher auch das Source-NAT, Source ist hier das eigene LAN, sobald die Pakete über das WAN-Interface rausgehen, wird die interne private IP mit der öffentlichen IP des Routers überschrieben. Da diese IP dann "öffentlich erreichbar" ist, kann das vorher angefragte Ziel (eben z.B. ein Webserver) die Antwort auch wieder zurück schicken (da die WAN-IP des Routers öffentlich erreichbar ist).
Beim Site2Site-VPN bekommen die Router (A+B) allerdings noch eine private IP aus dem VPN-Netz zugewiesen. Die Pakete gehen somit "nicht" über das WAN-Interface, sondern über ein virtuelles Tunnel-Interface, welches eine eigene (private) IP aus dem Tunnel-Netzwerk hat.
Nebst diesem VPN-Tunnel-Netz werden zudem auch Informationen darüber ausgetauscht, welche Netze das jeweils gegenüberliegende Netz zur Verfügung stellt. Das fliesst dann mit in die Routing-Tabelle ein (die Tabelle mit den Informationen darüber, über welches Interface welche Netze zu erreichen sind).
Ab diesem Punkt entscheidet dann der Router, welche Pakete über welches Interface gehen. Als Beispiel mal 3 Netze:
Standort A: 192.168.1.0/24
Standort B: 192.168.2.0/24
VPN-Tunnel: 172.16.1.0/24
Die Router-Konfiguration könnte dann wie folgt aussehen:
Router A:
IP-Adresse: 192.168.1.1/24
Öffentliche IP: a.b.c.d
VPN-IP: 172.16.1.1/24
Router B:
IP-Adresse: 192.168.2.0/24
Öffentliche IP: f.g.h.j
VPN-IP: 172.16.1.2/24
Bezüglich des Routings könnte es dann (ganz grob und unvollständig) bei den Routern wie folgt aussehen:
Router A:
192.168.1.0/24 -> LAN-Interface
0.0.0.0/0 -> WAN-Interface (SNAT!)
172.16.1.0/24 -> VPN-Interface
192.168.2.0/24 -> VPN-Interface (via 172.16.1.2)
Router B:
192.168.2.0/24 -> LAN-Interface
0.0.0.0/0 -> WAN-Interface (SNAT!)
172.16.1.0/24 -> VPN-Interface
192.168.1.0/24 -> VPN-Interface (via 172.16.1.1)
Das wäre ein einfaches Setup, wobei nur der Traffic durch den Tunnel geht, welcher für das Remote-Netz bestimmt ist, alles andere geht weiterhin über das Standard-Gateway ins Internet.
Es gibt natürlich auch die Möglichkeit, dass "alles" durch den Tunnel geschickt wird (0.0.0.0/0), das macht aber i.d.R. nie wirklich Sinn, ausser man nutzt irgendwelche Anonymisierungs-VPN-Anbieter, oder will den Traffic komplett über das Remote-Netz schicken, was auch nur in manchen Szenarien bedingt Sinn macht (egal wie groß die eigene Downloadbandbreite am aktuellen Standort ist, tunnelt man alles via VPN, ist man auf die maximalen Uploadbandbreite des Remote-Netzes beschränkt - schneller kann es einem die Daten halt nicht schicken).
Dröseln wir das einfach mal auf - ich hab zwar keine Erfahrung mit dem Cudy-Ding, aber mal sehen.... Ich gehe mal davon aus, dass das Setup wie folgt aussieht: Fritzbox <-VPN-> Cudy
Du sagst nun, dass wenn Du das Webinterface vom Cudy aufrufen willst, dass dann das Webinterface der Fritz!Box aufgerufen wird, oder wie ist das zu verstehen? Grundsätzlich ist es schon sinnvoll, wenn man einfach mal via Traceroute (unter Windows "tracert") den Weg der Pakete verfolgt:
Von einem Client aus dem Fritz!Box-Netzwerk:
tracert <IP eines Gerätes im Cudy-Netzwerk>Von einem Client aus dem Cudy-Netzwerk:
tracert <IP eines Gerätes im Fritz!Box-Netzwerk>Da sollte sich das Problem eigentlich schon zeigen. Irgendeine Form von NAT hat bei der Verbindung der beiden Netze durch den VPN-Tunnel (standardmässig) nichts verloren. Theoretisch sollte es wie folgt aussehen:
Von Standort A:
1. LAN-IP Router A (z.B. 192.168.1.1)
2. VPN-IP Router B (z.B. 172.31.1.2)
3. Ziel-IP in Netz B (z.B. 192.168.2.100)
Von Standort B:
1. LAN-IP Router B (z.B. 192.168.2.1)
2. VPN-IP Router A (z.B. 172.31.1.1)
3. Ziel-IP Netz B (z.B. 192.168.1.100)
Schau Dir erstmal die Traceroute-Ergebnisse von beiden Standorten an, vielleicht wird das Problem dann etwas klarer
