Router Kaskade mit mehreren Hops - Wireguard
Hallo zusammen,
habe hier (aus der Historie heraus) eine etwas blöde Situation und stell mich vermutlich doof an, ich hoffe ihr könnt mir helfen.
Folgende Situation: Es muss eine bestehende Fritzbox mit allen Einstellungen und eigenem DHCP ins Netz übernommen werden. Auf dieser Fritzbox sind Wireguard Tunnel eingerichtet, die auch genutzt werden sollen.
Umgebung:
- Internet via Glasfaser
- Lancom Router mit internem Netz 192.168.0.x
- Cisco Switch mit Routing aktiv + VLAN + ACL (zur Trennung damit sich die Netze untereinander nicht finden)
Die Fritzbox hängt jetzt an einem der VLANs im Cisco Switch, bekommt von diesem eine IP und der Traffic wird entsprechend geroutet.
Internet geht, Speed passt aber den Wireguard Tunnel bekomme ich nicht zur Fritzbox durch.
Im Lancom steht der betroffene UDP Port als PortForwarding an die Fritzbox WAN IP drin. Dort kommen aber keine Daten an. Ich kann vom Lancom aus den die Fritzbox "WAN" IP nicht anpingen. Der erste Hop ist ansprechbar (Lancom an Cisco), Lancom an Fritz wiederum nicht.
Bitte um Hilfe wie man das korrekt macht (ein bestehendes Topic mit mehrfachen Hops habe ich nicht gefunden, aber ggf. natürlich bitte verlinken - dann lese ich mich dort ein).
Danke
Marco
habe hier (aus der Historie heraus) eine etwas blöde Situation und stell mich vermutlich doof an, ich hoffe ihr könnt mir helfen.
Folgende Situation: Es muss eine bestehende Fritzbox mit allen Einstellungen und eigenem DHCP ins Netz übernommen werden. Auf dieser Fritzbox sind Wireguard Tunnel eingerichtet, die auch genutzt werden sollen.
Umgebung:
- Internet via Glasfaser
- Lancom Router mit internem Netz 192.168.0.x
- Cisco Switch mit Routing aktiv + VLAN + ACL (zur Trennung damit sich die Netze untereinander nicht finden)
Die Fritzbox hängt jetzt an einem der VLANs im Cisco Switch, bekommt von diesem eine IP und der Traffic wird entsprechend geroutet.
Internet geht, Speed passt aber den Wireguard Tunnel bekomme ich nicht zur Fritzbox durch.
Im Lancom steht der betroffene UDP Port als PortForwarding an die Fritzbox WAN IP drin. Dort kommen aber keine Daten an. Ich kann vom Lancom aus den die Fritzbox "WAN" IP nicht anpingen. Der erste Hop ist ansprechbar (Lancom an Cisco), Lancom an Fritz wiederum nicht.
Bitte um Hilfe wie man das korrekt macht (ein bestehendes Topic mit mehrfachen Hops habe ich nicht gefunden, aber ggf. natürlich bitte verlinken - dann lese ich mich dort ein).
Danke
Marco
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 671954
Url: https://administrator.de/forum/router-kaskade-mit-mehreren-hops-wireguard-671954.html
Ausgedruckt am: 29.04.2025 um 22:04 Uhr
13 Kommentare
Neuester Kommentar
Mahlzeit.
Warum hängst du die Fritte nicht direkt an den Lancom?
Das Portforwarding vom Lancom auf die Fritzbox wird vermutlich daran scheitern, dass du den Cisco nicht ebenfalls über das NAT informiert hast.
Gibt es statische Routen zwischen Fritzbox, Cisco und dem Lancom?
Ansonsten wird das nichts werden.
VPN durch eine Router Kaskade ist immer ein Kreuz und sollte vermieden werden, wo nur irgend möglich.
Gruß
Marc
Warum hängst du die Fritte nicht direkt an den Lancom?
Das Portforwarding vom Lancom auf die Fritzbox wird vermutlich daran scheitern, dass du den Cisco nicht ebenfalls über das NAT informiert hast.
Gibt es statische Routen zwischen Fritzbox, Cisco und dem Lancom?
Ansonsten wird das nichts werden.
VPN durch eine Router Kaskade ist immer ein Kreuz und sollte vermieden werden, wo nur irgend möglich.
Gruß
Marc
aber den Wireguard Tunnel bekomme ich nicht zur Fritzbox durch.
Sehr wahrscheinlich ist das Glasfaser Netz ein CG-NAT Netz, kann das sein??Falls ja ist damit dann eine eingehende IPv4 Verbindung auf die Fritzbox generell technisch nicht möglich. Egal ob VPN oder Port Forwarding.
Du kannst dann den Tunnel nur per IPv6 betreiben und im Tunnel IPv4 routen. Das bedingt aber das dann auch der VPN Client in einem IPv6 Netz arbeitet. Ist dort nur v4 aktiv scheitert der Tunnelaufbau, wie bereits gesagt, am CG-NAT Gateway des Providers. Multi Hop ist hier sicher nicht das Problem.
Als Lösung bleibt dir dann nur die IPv6 Alternative oder ein vServer als VPN Jumphost. Das Jumphost Kapitel erklärt auch warum VPN Responder (Server) an einem CG-NAT / DS-Lite Provideranschluss scheitern.
Alle relevanten Details zu der Thematik erklärt dir das hiesige Wireguard Tutorial:
Merkzettel: VPN Installation mit Wireguard
Statische Routen auf dem Cisco:
nein, die next hops sind in der IP Routingtabelle korrekt dargestellt (directly connected). Deswegen dachte ich ansich das der Teil korrekt gehandelt wird.
@aqui
Kein CG-NAT, das ist ein glücklicherweise ein Business Anschluss. Das interne Wireguard läuft auf einem separatem Mikrotik bereits erfolgreich, aber ohne den Hop über den Cisco (weil quasi Stammnetz).
Den Anschluss direkt an den Lancom hatte ich mir in dem Zug auch schon überlegt, aber dann wäre die Idee die Netze schön über den Cisco zu trennen dahin und man müsste sich zwei separate Geräte anschauen wenn es um die Netztrennung geht.
Verhält sich die statische Route auf dem Cisco anders als die wohl automatisch erkannte IP-Forwarding Tabelle?
LG
nein, die next hops sind in der IP Routingtabelle korrekt dargestellt (directly connected). Deswegen dachte ich ansich das der Teil korrekt gehandelt wird.
@aqui
Kein CG-NAT, das ist ein glücklicherweise ein Business Anschluss. Das interne Wireguard läuft auf einem separatem Mikrotik bereits erfolgreich, aber ohne den Hop über den Cisco (weil quasi Stammnetz).
Den Anschluss direkt an den Lancom hatte ich mir in dem Zug auch schon überlegt, aber dann wäre die Idee die Netze schön über den Cisco zu trennen dahin und man müsste sich zwei separate Geräte anschauen wenn es um die Netztrennung geht.
Verhält sich die statische Route auf dem Cisco anders als die wohl automatisch erkannte IP-Forwarding Tabelle?
LG
Kein CG-NAT, das ist ein glücklicherweise ein Business Anschluss.
Ein Glück! 😉Was du noch nicht gesagt hast ist ob die Fritzbox überhaupt an ihrem LAN 1 Port pingbar ist oder ob deren Firewall eingehendes ICMP blockiert.
Hier wäre es sinnvoll einmal aus dem VLAN an dem die Fritte mt ihrem LAN 1 Port hängt diese zu pingen um zu checken das sie überhaupt am WAN/LAN1 pingbar ist.
Generell hast du ja ein Layer 3 Konzept umgesetzt wie es HIER beschrieben ist.
Ein neues VLAN für die Fritte erzwingt dann auch immer eine neue statische Route in dieses VLAN auf dem Lancom. Hast du das erstellt?
Wenn ja wäre es wichtig zu wissen ob der Lancom zu mindestens die zum Fritten VLAN korrespondierende Switch IP pingen kann?
Ist das der Fall kann man ein Routing Problem sicher ausschliessen. Sofern der Fritten WAN/LAN1 generell pingbar ist müsste er dann auch vom Lancom pingbar sein. Natürlich nur wenn keine deiner ACLs dies verhindern.
Ist das Obige auch alles soweit sauber dann musst du etwas ins Eingemachte und zuallererst wasserdicht checken ob der Lancom eingehende Wireguard UDP Frames an die Fritten WAN IP forwardet.
Dazu hast du 2 Optionen:
- Mirror Port auf dem Cisco einrichten und einen Wireshark anschliessen
- L3 Switch temorär vom Lancom abstöpseln und einen Wireshark PC mit gleicher IP wie der Switch im Lancom Netz anschliessen. Der Lancom "merkt" nicht das das kein L3 Switch mehr ist und forwardet seine Port geforwardeten Wireguard Frames, sofern seine Routing Tabelle stimmt, dann an den als Switch "getarnten" Wireshark PC. Hier müsstest du dann diese UDP Frames mit dem von dir verwendeten WG Port im Capture sehen können wenn alles so läuft wie es soll.
Viele billige Router supporten oftmals ein Port Forwarding nicht wenn dort keine lokale IP als Forwarding Adresse definiert ist.
Da aber ein Lancom generell nicht zu dieser Art Router gehört kann man das wohl ausschliessen. Anhand seiner Routing Tabelle mit der (hoffentlich) vorhandenen statischen Route auf das Frittennetz "weiss" der Lancom das er den Port geforwardeten WG Traffic an den Cisco routen muss.
Auch ob das der Fall ist kannst du als Crosscheck einmal querchecken indem du die Portforwarding Zieladresse im Lancom auf eine lokale unbenutzte Adresse umstellst anstatt der Fritten IP und...du ahnst es schon...den Wireshark PC mit dieser IP dranhängst.
Kommen die Frames dann an aber mit einer nicht lokalen IP nicht, dann hast du ein Lancom Port Forwarding Problem aber wir wollen mal nicht vorab negativ denken...
Verhält sich die statische Route auf dem Cisco anders
Nein, die sagt dem Router ja nur wo welche IP Zieladressen hingesendet werden die NICHT in seinen lokalen Netzen liegen. Siehe L3 Konzept Tutorial oben.Abgesehen davon hast du auf dem Cisco ja auch keinerlei statische Routen sondern einzig und allein nur eine Einzige, nämlich die Default Route auf den Lancom. Nicht mehr und nicht weniger...
als die wohl automatisch erkannte IP-Forwarding Tabelle?
Automatisch erkannte??? 🤔Hier verwechselst du vermutlich irgendetwas? Die Port Forwarding Tabelle kennt logischerweise einzig und allen NUR der Lancom! Der Cisco (Switch) weiss davon nix. Logisch, denn Port Forwarding gibt es auf einem Switch gar nicht.
Die Fritz!Box hat einen WAN Port in dem Fall - dort steckt quasi der Cisco. Ich kann vom Lancom aus die Fritz!Box nicht anpingen...aber den Cisco im anderen Netz schon (Ping von 192.168.0.1 (lancom) an 192.168.6.2 (Cisco)) geht, aber an 192.168.6.50 (Fritz!Box) geht nicht. Ich ging davon aus das die Fritte da am WAN Port den Ping einfach blockt.
In den ACLs stehen nur zwei Einträge, einmal ein Deny für 192.168.0.0/16 und danach ein allow für ANY fürs Internet. Ich hatte schon mal kurz überlegt ob da vielleicht ein allow Eintrag mit der 192.168.0.1/32 mit dem UDP Port davor gehört, aber das lief auch nicht. Ich glaube ich hatte die ACL auch schonmal gelöscht bevor ich gefragt hab, muss das aber nochmal verifizieren.
VLAN Fritte Route => Ja, steht im Lancom (192.168.99.0, das Netz der Fritz!Box an deren User) via 192.168.0.2 (Cisco).
Wegen IP Forwarding - da ist nicht Port Forwarding gemeint. Es gibt eines Tabelle in dem Cisco die man selbst nicht ändern kann, heißt "IPv4 Forwarding Table", dort ist das Netz 192.168.6.0 vermerkt mit "next hop 192.168.6.2, directly connected".
Testen => ja das sieht mir wohl danach aus, die Wireshark Idee finde ich gut, wird mir wohl morgen mal blühen - wobei ich mich damit nicht besonders gut auskenne, aber les ich mich ggf. ein.
Sonst stecke ich die Fritz!Box an den Lancom, eigenes Interface LAN2 konfiguriert zum trennen der Netze und DHCP Server aktiviert - dann läuft die Weiterleitung vermutlich problemlos.
In den ACLs stehen nur zwei Einträge, einmal ein Deny für 192.168.0.0/16 und danach ein allow für ANY fürs Internet. Ich hatte schon mal kurz überlegt ob da vielleicht ein allow Eintrag mit der 192.168.0.1/32 mit dem UDP Port davor gehört, aber das lief auch nicht. Ich glaube ich hatte die ACL auch schonmal gelöscht bevor ich gefragt hab, muss das aber nochmal verifizieren.
VLAN Fritte Route => Ja, steht im Lancom (192.168.99.0, das Netz der Fritz!Box an deren User) via 192.168.0.2 (Cisco).
Wegen IP Forwarding - da ist nicht Port Forwarding gemeint. Es gibt eines Tabelle in dem Cisco die man selbst nicht ändern kann, heißt "IPv4 Forwarding Table", dort ist das Netz 192.168.6.0 vermerkt mit "next hop 192.168.6.2, directly connected".
Testen => ja das sieht mir wohl danach aus, die Wireshark Idee finde ich gut, wird mir wohl morgen mal blühen - wobei ich mich damit nicht besonders gut auskenne, aber les ich mich ggf. ein.
Sonst stecke ich die Fritz!Box an den Lancom, eigenes Interface LAN2 konfiguriert zum trennen der Netze und DHCP Server aktiviert - dann läuft die Weiterleitung vermutlich problemlos.
Ich ging davon aus das die Fritte da am WAN Port den Ping einfach blockt.
Das ist gut möglich. Müsste ich hier an der Fritte auch mal testen. Üblicherweise blocken Heimrouter ICMP Echo Requests am WAN aus Sicherheitsgründen.In den ACLs stehen nur zwei Einträge, einmal ein Deny für 192.168.0.0/16
An welchem Port??Das ist vermutlich tödlich, denn bedenke das ACLs nicht stateful sind! Return Traffic wird mit der Regel ebenso geblockt!
Normalerweise legt man sich als pfiffiger Admin beim Testen eines solchen Setups niemals schon VORHER Knüppel in den Weg sondern lässt das aus guten Gründen erstmal alles ACLtechnisch offen.
Klappt alles wie gewünscht macht man erst dann die Schotten dicht. So weiss man immer das mögliche Fehler nur noch am Regelwerk liegen können. Besser also nochmal "verifizieren"...
Da kommt man eigentlich auch an einem Freitag mit dem gesunden IT Verstand drauf! 🐟😉
...gibt eines Tabelle in dem Cisco die man selbst nicht ändern kann, heißt "IPv4 Forwarding Table"
Ja ist bekannt...das ist die Routing Tabelle. Hat jeder Router. Die ist in der Tat automatisch zu mindestens was alle lokal angeschlossenen IP Netze anbetrifft.wobei ich mich damit nicht besonders gut auskenne
Einen einfachen Crashkurs gibt es HIER.dann läuft die Weiterleitung vermutlich problemlos.
Kommt drauf an was bei deinem Wireshark Test rauskommt. Wenn ja wäre das ein ziemliches Armutszeugnis für Lancom. Aber warten wir mal ab... 
Hallo,
es wurde ja oben schon erwähnt, wenn eine Fritte nicht direkt am WAN sitzt dann verhalten sich alle Dienste darin etwas "zickig". Z.B. pusht die Fritte dann eine LAN-Adresse an den MyFritz-Dienst(Dyndns).
Viele Funktionen / Assistenten welche mit "Mobiles"(Handy / Tablet und Co) kommunizieren sollen, sind darauf angewiesen dass die Fritte ein echtes WAN "sieht".
Ist diese im LAN, kann man die Dienste vergessen welche z.B. den MyFritz-Dienst nutzen um die Fritte erreichbar zu machen.
Wenn man WG manuell konfiguriert bzw. überhaupt die Möglichkeit dazu hat, ist es idR kein Problem mehrere Router in einer Kaskade zu haben auch wenn es nicht "schön" ist.
Soweit geht es bei dir schon gar nicht da ja schon der Ping nicht durch kommt.
Erst mal nachschauen ob der PING nicht blockiert wird von der Fritte(im Default ist er das nicht).
Dann an den Subnetzgrenzen im Routing NAT einschalten(nur mal Probehalber) und zwar SourceNAT.
So kommen alle Anfragen (auch der Ping) aus dem "eigenen" Netz - die Devices zicken manchmal rum wenn "fremde" Pakete verarbeitet werden sollen.
Mein Vorschlag, wäre übrigens ein günstiges Gerät verwenden welches ein vielfältig einstellbares WG hat.
Wenn die WG-Speed keine Rolle spielt, ein einfaches Mikrotik Kästchen(deutlich weniger als 50 EUR eher Richtung 30). Dieses dann in das Netz packen welches man erreichen will. Auch funktioniert das Mikrotik Dyndns aus geNATeten Netzen heraus prima. Wenn man daür sorgt dass die WG-Ports richtig forwardet werden, ist das eine mögliche Lösung. Vertraut man dem Hersteller, dann könnte man auch BTH(BackToHome) machen, dann dient ein Server von Miktrotik betrieben als WG-Relay und man muss keine Ports von außen hereinlassen.
Dieser Dienst läuft aber nicht mehr auf den ganz kleinen Mikrotiks, da braucht es welche die etwas mehr kosten(z.B. mit ARM / ARM64 soweit ich weiß, aber immer erst nachlesen, bevor man bestellt)
Zurück zur Fritte. Wenn der WG-Tunnel per Assistent erstellt wird, ist im QR-Code für die Apps immer eine WAN Adresse drin, diese Konfig muss man im diesen Fall anpassen da es ja kein echtes WAN für die Fritte gibt.
BTW. Kann der Lancom kein WG? Schließlich sitzt dieser ja direkt am WAN. Ich hatte mit Lancom beruflich zuletzt vor ca.8 jahren zu tun da gab es definitiv (noch?) kein WG für die Lancoms.
Grüße
es wurde ja oben schon erwähnt, wenn eine Fritte nicht direkt am WAN sitzt dann verhalten sich alle Dienste darin etwas "zickig". Z.B. pusht die Fritte dann eine LAN-Adresse an den MyFritz-Dienst(Dyndns).
Viele Funktionen / Assistenten welche mit "Mobiles"(Handy / Tablet und Co) kommunizieren sollen, sind darauf angewiesen dass die Fritte ein echtes WAN "sieht".
Ist diese im LAN, kann man die Dienste vergessen welche z.B. den MyFritz-Dienst nutzen um die Fritte erreichbar zu machen.
Wenn man WG manuell konfiguriert bzw. überhaupt die Möglichkeit dazu hat, ist es idR kein Problem mehrere Router in einer Kaskade zu haben auch wenn es nicht "schön" ist.
Soweit geht es bei dir schon gar nicht da ja schon der Ping nicht durch kommt.
Erst mal nachschauen ob der PING nicht blockiert wird von der Fritte(im Default ist er das nicht).
Dann an den Subnetzgrenzen im Routing NAT einschalten(nur mal Probehalber) und zwar SourceNAT.
So kommen alle Anfragen (auch der Ping) aus dem "eigenen" Netz - die Devices zicken manchmal rum wenn "fremde" Pakete verarbeitet werden sollen.
Mein Vorschlag, wäre übrigens ein günstiges Gerät verwenden welches ein vielfältig einstellbares WG hat.
Wenn die WG-Speed keine Rolle spielt, ein einfaches Mikrotik Kästchen(deutlich weniger als 50 EUR eher Richtung 30). Dieses dann in das Netz packen welches man erreichen will. Auch funktioniert das Mikrotik Dyndns aus geNATeten Netzen heraus prima. Wenn man daür sorgt dass die WG-Ports richtig forwardet werden, ist das eine mögliche Lösung. Vertraut man dem Hersteller, dann könnte man auch BTH(BackToHome) machen, dann dient ein Server von Miktrotik betrieben als WG-Relay und man muss keine Ports von außen hereinlassen.
Dieser Dienst läuft aber nicht mehr auf den ganz kleinen Mikrotiks, da braucht es welche die etwas mehr kosten(z.B. mit ARM / ARM64 soweit ich weiß, aber immer erst nachlesen, bevor man bestellt)
Zurück zur Fritte. Wenn der WG-Tunnel per Assistent erstellt wird, ist im QR-Code für die Apps immer eine WAN Adresse drin, diese Konfig muss man im diesen Fall anpassen da es ja kein echtes WAN für die Fritte gibt.
BTW. Kann der Lancom kein WG? Schließlich sitzt dieser ja direkt am WAN. Ich hatte mit Lancom beruflich zuletzt vor ca.8 jahren zu tun da gab es definitiv (noch?) kein WG für die Lancoms.
Grüße
1
Ich trau es mich fast nicht zu sagen - die Lösung ist ja oftmals viel einfacher und man schaut nur auf die spannenderen Konfigurationsteile....vielen Dank an alle.
Die Fritzbox und ihre Wireguard Config hat auf eine myfritz Adresse gezielt und wie MT-Fan0815 richtig angemerkt hat ist die Fritzbox da etwas zickig und gibt als WAN Adresse etwas falsches raus, entsprechend kam der Tunnel nie am Gateway an.
Das Routing / PortForwarding geht einwandfrei, auch mit der bestehenden ACL im Cisco. Geschwindigkeit passt auch.
Vielen dank nochmal und sorry das ich da nicht als erstes hingeschaut hab...voll konzentriert auf den falschen Teil quasi.
Schönes WE allen.
Die Fritzbox und ihre Wireguard Config hat auf eine myfritz Adresse gezielt und wie MT-Fan0815 richtig angemerkt hat ist die Fritzbox da etwas zickig und gibt als WAN Adresse etwas falsches raus, entsprechend kam der Tunnel nie am Gateway an.
Das Routing / PortForwarding geht einwandfrei, auch mit der bestehenden ACL im Cisco. Geschwindigkeit passt auch.
Vielen dank nochmal und sorry das ich da nicht als erstes hingeschaut hab...voll konzentriert auf den falschen Teil quasi.
Schönes WE allen.
Die Fritzbox und ihre Wireguard Config hat auf eine myfritz Adresse gezielt und wie MT-Fan0815 richtig angemerkt hat ist die Fritzbox da etwas zickig und gibt als WAN Adresse etwas falsches raus, entsprechend kam der Tunnel nie am Gateway an.
Die Fritz!Box ist nicht zickig, sondern macht genau das, was sie soll, sie nimmt ihre WAN-Adresse. Es liegt auf der Hand, dass Du als Zieladresse in der Wireguard Config die Adresse des Perimeters benötigst.1
Zickig war nur der Wortlaut zuvor, nicht explizit auf die Funktionalität bezogen sondern einfach nur das das nicht so geht wie mal angedacht war.
Aber wie gesagt, jetzt gelöst - von daher alles gut.
Aber wie gesagt, jetzt gelöst - von daher alles gut.
Super das es nun geklappt hat.
Ich wollte mit "zickig" auf keinen Fall die Fritten verunglimpfen!
Das sind tolle Router die trotz "DAU-Afinität" sehr viele Möglichkeiten bieten, auch wenn einige "Profifunktionen" tief in den Menüs vergraben sind(z.B. Outband Firewall).
Es wird halt immer zu Problemen kommen wenn man "Plug & Play" Dienste die eigentlich für "DAUs" gemacht sind in Umgebungen einsetzt die kein "Plug & Play" mehr sind
Auch hier ist "DAU" keine Beleidigung an irgendjemanden!
Wenn die Fritte "bestimmungsgemäß" eingesetzt wird, kann selbst "Lieschen Müller" damit einen WG-VPN zu einem Smarten Phone realisieren dazu gibt es von AVM schöne YT-Videos.
Was aber als Frage bleibt: Warum ging der Ping in den eigenen LANs / WANs nicht. Ich gehe davon aus dass hier IP-Adressen gepingt wurden und keine DynDns Domains.
Grüße
Ich wollte mit "zickig" auf keinen Fall die Fritten verunglimpfen!
Das sind tolle Router die trotz "DAU-Afinität" sehr viele Möglichkeiten bieten, auch wenn einige "Profifunktionen" tief in den Menüs vergraben sind(z.B. Outband Firewall).
Es wird halt immer zu Problemen kommen wenn man "Plug & Play" Dienste die eigentlich für "DAUs" gemacht sind in Umgebungen einsetzt die kein "Plug & Play" mehr sind
Auch hier ist "DAU" keine Beleidigung an irgendjemanden!
Wenn die Fritte "bestimmungsgemäß" eingesetzt wird, kann selbst "Lieschen Müller" damit einen WG-VPN zu einem Smarten Phone realisieren dazu gibt es von AVM schöne YT-Videos.
Was aber als Frage bleibt: Warum ging der Ping in den eigenen LANs / WANs nicht. Ich gehe davon aus dass hier IP-Adressen gepingt wurden und keine DynDns Domains.
Grüße
Das ist eben die Frage ob die Box das macht was sie soll?
Es würde für Anwender die ein bisschen mehr in der Materie drin sind, einige Probleme weniger geben, wenn der DynDns-Dienst von AVM die echte WAN-Adresse in der API nehmen würde, was problemlos funktioniert.
Das AVM immer die WAN-Adresse auf der Fritte verwendet statt der "echten" WAN-Adresse ist an sich eine rein "politische" Entscheidung, keine technische.
Noch besser: Die Entscheidung dem Anwender lassen(wäre auch nur ein Haken) aber es gibt sicher nicht sehr viele Szenarien in denen man eine Lokale LAN-Adresse mit einem DynDns-Dienst auflösen müsste.
Grüße
Es würde für Anwender die ein bisschen mehr in der Materie drin sind, einige Probleme weniger geben, wenn der DynDns-Dienst von AVM die echte WAN-Adresse in der API nehmen würde, was problemlos funktioniert.
Das AVM immer die WAN-Adresse auf der Fritte verwendet statt der "echten" WAN-Adresse ist an sich eine rein "politische" Entscheidung, keine technische.
Noch besser: Die Entscheidung dem Anwender lassen(wäre auch nur ein Haken) aber es gibt sicher nicht sehr viele Szenarien in denen man eine Lokale LAN-Adresse mit einem DynDns-Dienst auflösen müsste.
Grüße
eine Lokale LAN-Adresse mit einem DynDns-Dienst auflösen müsste.
Richtig! Das macht man immer besser mit https://nip.io 😉
