30.12.2022

5712

Wireguard-Verbindung mit Router Kaskade

Hallo zusammen,
ich bräuchte mal Hilfe von den Netzwerk-Spezialisten. Ich habe leider wie man gleich sieht wenig Ahnung von der Materie, seid daher bitte nicht so streng mit mir

Aufgabenstellung:
An Standort A bei mir zu Hause befindet sich hinter einem Glasfaseranschluss (keine öffentliche IPv4, nur IPv6) eine Fritzbox. An dieser befindet sich ein NAS.
An Standort B hängt am Kabel-Internetzugang ein Speedport smart 3 der Telekom, an dem ich auch Einstellungen vornehmen kann (er beherrscht allerdings keine statischen Routen). Hinter dem Speedport hängt ein weiterer Router von GL.inet, an welchem wiederum ein NAS hängt. Das NAS am GL.inet soll sich aus Sicherheitsgründen nicht im gleichen Netz befinden, wie die weiteren Teilnehmer am Speedport.

Das NAS von Standort A soll seine Daten täglich mittels Rsync auf das NAS an Standort B spiegeln. Mein Plan ist jetzt, eine Wireguard-Verbindung zwischen der Fritzbox 7590 an Standort A und dem GL.inet an Standort B aufzubauen. Die beiden NAS müssen sich für den Datenaustausch mittels Rsync gegenseitig sehen. Leider bin ich für die Konfiguration der Wireguard-Verbindung und der notwendigen Einstellungen an den Routern zu blöd. Der GL.Inet wird zwar grün beim Aufbau der VPN-Verbindung – allerdings sehen sich die beiden NAS nicht.

Folgendes habe ich bisher versucht:

Fritzbox7590 (Wireguard Server)
Ergebnis der Konfiguration / Konfig-Datei für den Import beim GL-inet:

Einstellungsdatei der Fritzbox nach dem Anlegen des neuen Clients:

GL.Inet (Wireguard Client)
Das Ergebnis nach dem Import der Datei der Fritzbox

Einstellung in der Firewall des GL.inet

Speedport Smart 3
Hier habe ich mal, ohne zu wissen was ich tue, die Ports 58224 und 20740 für den GL.Inet freigeschaltet.

Könnte mir bitte jemand helfen, welche Einstellungen ich anpassen muss, damit sich die beiden NAS bei aktiver VPN-Verbindung sehen können?
Danke und viele Grüße

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 5154242918

Url: https://administrator.de/forum/wireguard-verbindung-mit-router-kaskade-5154242918.html

Ausgedruckt am: 05.04.2025 um 14:04 Uhr

21 Kommentare

Neuester Kommentar

Es liegt weniger an dir als an AVM und der nicht ganz Wireguard konformen Konfig der FritzBox. AVM benutze eine "besondere" Konfig die nicht mit der des GL.inet (dahinter werkelt ein Standard OpenWRT mit Standard Wireguard) kompatibel ist. Diese musst du über den Shell Zugang zum OpenWRT (Putty mit SSH) manuell etwas anpassen damit es mit der FritzBox klappt.
Dieser Thread beschreibt die Lösung:
Wireguard Lan to Lan Fritzbox Raspberry Pi

Grundlagen zu der Thematik auch hier:
https://www.heise.de/select/ct/2022/23/2225809105962410605
Merkzettel: VPN Installation mit Wireguard

Wie soll das gehen ohne öffentl. IP?

Danke schon mal für Eure Nachrichten. Ich kam noch nicht dazu, die vorgeschlagene Lösung zu testen. Auf beiden Seiten wird am Router unter Internet eine IPv6 angezeigt, kann man davon ausgehen, dass diese öffentlich ist / funktioniert es damit? Muss ich dann bei den Einstellungen diesbezüglich was anpassen? Die myfritz Adresse zeigt glaube ich auch auf die ipv6. Nur der Gl.Inet hat ja nur eine lokale IP.

Was isn das für nen NAS?

kann man davon ausgehen, dass diese öffentlich ist / funktioniert es damit?

Wie sollen wir dir darauf zielführend antworten können wenn du diese hier nicht mitteilst?!

Du sollest ggf. einmal zum neuen Jahr deine IPv6 Kenntnisse mit etwas kostenloser Literatur zu dem Thema schärfen. Dann kannst du diese Frage kinderleicht auch selber beantworten.
https://danrl.com/ipv6/

Wireguard kann natürlich auch problemlos IPv4 Netze über einen IPv6 Tunnel senden.
Es geht aber auch per IPv4, denn für den Tunnelaufbau ist eine öffentliche v4 auch nicht nötig solange dein DS-Lite und CGNAT Glasfaseranschluss immer der VPN Initiator ist, also der der den VPN Tunnel initiiert (VPN Client).
Der Standort B mit einer dynamischen aber öffentlichen IPv4 und vermutlich DynDNS (geraten) ist dann dann immer Responder (VPN Server).
In der Konstellation klappt bei einem stinknormalen Standard VPN wie dem des TO oben der Tunnelaufbau dann auch via IPv4 absolut problemlos. Mit IPv6 dann sowieso. Wenn...man denn die AVM Eigenarten bei Wireguard beachtet.

Wenn ich es richtig verstehe hat er aber auf beiden Seiten nur dynamische IPs, auf keiner Seite eine feste.

Was dann zumindestens auf der (Speedport) VPN Responder Seite immer zwingend einen DynDNS Account erforderlich macht. Auf der Glasfaserseite scheitert ein VPN Responder Betrieb mit IPv4 ja generell am DS-Lite und CGNAT des dortigen Providers. Hier wäre einzig nur v6 möglich. Leider glänzt der TO zu dieser Thematik mit wenig bis keinen Informationen.

Dynamische IPs sind ja zumindestens an Consumer Anschlüssen normal und bekanntlich kein Hinderungsgrund für VPNs, egal ob IPv4 oder v6.

Steht doch so oben in der Zeichnung, bei beiden Routern "keine öffentliche IPv4"

Leider nur in der Zeichnung zu Standort B nicht aber im Text des TOs zum Standort B Setup...
Aber in dem Falle hast du dann natürlich Recht. Wenn beide Seiten ein DS-Lite Anschluss mit Provider CGNAT ist dann wird es dadurch mit IPv4 komplett scheitern.
Scheitern wird es auch weil der TO den FritzBox WG Port auf UDP 58224 gesetzt hat, den GL.inet WG Port aber auf 20740. Ohne Portgleichheit ist das Setup dann ebenso zum Scheitern verurteilt egal welche IP Version.
Dann kann man den Tunnel nur mit IPv6 und DynDNS aufbauen und muss die beiden NAS IPv4 Netze dann über den v6 Tunnel routen.
Mit Wireguard ja ein Kinderspiel...wenn man denn die Eigenarten des AVM Wireguard beachtet!

Zitat von @aqui:
Dann kann man den Tunnel nur mit IPv6 und DynDNS aufbauen und muss die beiden NAS IPv4 Netze dann über den v6 Tunnel routen.

Hast du das auch schon mal irgendwo in deinen Beiträgen erläutert wie man das aufbaut? Interessiert mich auch..

Ist eigentlich kein Hexenwerk. Die Tunnelendpoints sind dann IPv6 und das interne WG IP Netz klassisch IPv4. Ob das dann allerdings in einem gemischten Setup mit der eigenwilligen AVM WG Konfig rennt die kein internes WG IP Netz kennt ist die große Frage. Wohl in dem Falle eher nicht.
In gemischten Setups sind proprietäre Eigenarten eher hinderlich und erfordern Klimmzüge und es wäre besser auf eine einheitlich klassische WG Konfig zu wechseln mit 2 Mikrotik Routern oder Raspberry Pi's oder was auch immer. Idealerweise supporten beide NAS VPN Techniken mit Apps wie z.B. bei QNAP oder Synology. Dann hätte man zwar den gravierenden Nachteil die VPNs direkt auf dem NAS zu terminieren wäre aber von den Routern unabhängig.
Ebenso ist man dann von solchen "Sonderlocken" wie denen von AVM nicht mehr abhängig.
Ignoriert man einmal die schlechtere Performance von OpenVPN geht es damit auch problemlos mit mixed IPv6 und IPv4 Tunneln. Das Prinzip ist immer das gleiche.
https://www.heise.de/select/ct/2018/13/1529374309620058

Was isn das für nen NAS?

Once again

Sorry ich komme mit dem Antworten nicht nach. Standort A ein qnap, Standort B ein Synology. Den VPN auf den NAS laufen zu lassen hatte ich auch überlegt. Wobei mir die Variante auf dem Router eigentlich sympathischer ist. Am Standort A habe ich noch nen Raspberry laufen, da könnte ich auch versuchen, den Wireguard Server laufen zu lassen und am Standort B dann den Gl.inet nutzen.

Ich komme aktuell nicht an Standort B und muss mir zwischenzeitlich mal ein Testsetup überlegen. Dann probiere ich mal, wie weit ich mit den Eigenschaften des WG auf der Fritzbox komme. Was müsste ich denn für die Thematik ipv4 über ipv6 machen?

Sobald die Tests losgehen melde ich mich dazu, vielen Dank erstmal für euren Support.

Also: Grundsätzlich ist VPN auf nem NAS natürlich hier des Teufels

Weil Du damit - prinzipiell - ungeschützten Internet-Traffic über die Portweiterleitung direkt an Dein "heiligstes" hängst.

Aber wenn Du mit Deinem ganzen Kram überhaupt nicht weiterkommst, schau Dir mal "zerotier.com" an. Kostet nix, lässt sich sowohl auf qnap als auch auf synology installieren und baut völlig automatisch ne VPN zwischen den beiden auf. Unbeleckt von offenen Ports, Weiterleitung usw. an den jeweiligen Firewalls. Arbeitet im Prinzip wie ein anydesk bzw. teamviewer-setup und dauert max ne halbe Stunde bis es flutscht

Dafür gehört Dir da dann weder die Verschlüsselung (proprietär) noch der Host ... wenn Du ihn nicht selber hostest, was zumindest möglich ist. Gibt aber auch ähnliche Angebote auf z.B. Wireguard-Basis. Ob die dann aber auf Deinem NAS laufen, steht wieder auf nem anderen Blatt.

Viel Erfolg!

Ich wollte mich nochmal generell für die Hilfe und den Tipp mit Zerotier bedanken. Die Variante mit Wireguard erscheint mir sicherer, aber ich muss gestehen, dass ich mir bei meinem aktuellen Kenntnisstand und dem eingeschränkten physischen Zugriff auf Standort B für Tests vermutlich ziemlich einen abgebrochen hätte. Mit Zerotier läuft nun zumindest ein Testsetup, von daher gehe ich davon aus, dass es unter richtigen Bedingungen auch funktioniert. Ich kann allerdings noch nichts zur Übertragungsgeschwindigkeit sagen.

Falls es nochmal jemanden interessiert, hier wie ich es umgesetzt habe:

Standort A: Glasfaser-Inet mit IPv6->Fritzbox7590->NAS QNAP TS128A

Standort B: Kabel-Inet mit dsLite->Speedport Smart 3 ->(WAN-Port) GL.Inet AC1200 ->NAS Synology DS120J

Am Standort A läuft auf dem QNAP die Zerotier-Software, welche anhand folgender Anleitung eingerichtet wurde:
https://docs.zerotier.com/devices/qnap/
Das TS128A taucht in der Prozessoren-Liste nicht auf, das Paket vom Download-Link zerotier_1.10.1_arm_64.qpkg hat aber funktioniert.
Dann nur noch per ssh im NAS einloggen und eintippen: zerotier-cli join xxxNetzwerk-IDxxx

Am Standort B unterstützt die DS120J leider keine Installation von Docker, ich habe es auch über Umwege nicht hinbekommen. Daher läuft Zerotier jetzt auf dem GL-Inet AC1200, welcher netterweise openwrt nutzt. Die Installation war bis auf die IPs im Prinzip 1:1 das hier beschriebene:
https://github.com/mwarning/zerotier-openwrt/wiki

Mit diesem Setup sind alle mit dem AC1200 verbundenen Geräte am Standort B über das Zerotier Netzwerk erreichbar. Die weiteren Geräte im Zerotier-Netzwerk, also z.B. das QNAP NAS, erreichen die Geräte hinter dem AC1200, also das Synology-NAS, über die jeweilige lokale IP vom AC1200, also in meinem Fall 192.168.20.x.
Umgekehrt ist das QNAP-NAS für das Synology-NAS über die im Zerotier-Netzwerk vergebene managed IP erreichbar (in meinem Fall 10.147.18.x).

Glückwunsch und gern geschehen. Wäre natürlich auch tootaaal lieb, wenn Du mit (auch) einen Lösungsbutton gibst 😉

In dem Sinne: Frohes Neues! 🎉

Die Variante mit Wireguard erscheint mir sicherer

Das ist in der Tat auch so. Zerotier ist KEIN eigenes VPN, das darfst du nie vergessen. Der Anbieter nutzt eine eigene Infrastruktur mit Vermittlungsserver. Da sollte man sich immer fragen warum jemand umsonst so eine Infrastruktur bereitstellt die ihn täglich Geld kostet...?! Ein Schelm wer Böses dabei denkt.
Wirklich schutzbedürftige Daten solltest du darüber niemals übertragen. In Firmennetzen wäre es eh ein NoGo.

Zitat von @aqui:

Die Variante mit Wireguard erscheint mir sicherer

Hallo zusammen,
das Setup mit Zerotier hätte ich ja wie oben geschrieben am Laufen, aber irgendwie habe ich dabei kein 100% gutes Gefühl und es wurmt mich auch, dass ich das mit Wireguard nicht hinbekomme. Weil ich nur sporadisch zu Standort B komme, habe ich versucht, die Verhältnisse (Standort A und Standort B ohne öffentliche IPv4 und die Routerkaskade an Standort B) über ein Testsetup bei mir zuhause hinzubekommen.

Testsetup

Standort A: Glasfaser ohne öffentliche IPv4. Fritzbox mit dem Wireguard Server, dahinter ein NAS, was seine Daten auf Standort B spiegeln soll.
Standort B: Smartphone mit mobilen Daten (ohne öffentliche IPv4) und Hotspot für Internetzugang des TP-Link -> TP-Link mit OpenWrt -> (Wan-Port) GL.inet mit OpenWRT und dem Wireguard-Client -> NAS.

Einstellung Wireguard-Server auf Fritzbox

[Interface]
PrivateKey = xxxxxxxxxxxxxx
ListenPort = 58224
Address = 192.168.50.1/24
DNS = 192.168.50.1,192.168.30.1
DNS = fritz.box

[Peer]
PublicKey = xxxxxxxxxx
PresharedKey = xxxxxxxxxx
AllowedIPs = 192.168.30.0/24
PersistentKeepalive = 25

Einstellung Wireguard-Client auf GL-Inet

[Interface]
PrivateKey = xxxxxxxxxxxxxx
ListenPort = 58224
Address = 192.168.30.1/24
DNS = 192.168.50.1, 8.8.8.8

[Peer]
PublicKey = xxxxxxxxxx
Endpoint = xxxxx.myfritz.net:58224
AllowedIPs = 192.168.50.0/24
PersistentKeepalive = 25
PresharedKey = xxxxxxxxxx

Problem
Wenn ich den TP-Link Router weglasse und den GL.Inet Router über den Hotspot des Smartphones verbinde, kommt die Wireguard-Verbindung zustande und die Geräte hinter der Fritzbox sehen die Geräte hinter dem GL.Inet. Sobald ich aber die Router kaskadiere, kommt es zu keiner Verbindung.

Firewall-Einstellung GL.Inet
Die Zone „VPN“ habe ich für Zerotier angelegt. Die Zone „Wireguard“ mit den Einstellungen wie man sie sieht, wird von der überlagerten GL.Inet Oberfläche erzeugt, sobald ich den Wireguard-Client starte. Ist denn diese Einstellung so korrekt – ich meine irgendwo gelesen zu haben, dass „Forward“ auf accept muss und „Masquerading“ ausgeschaltet werden muss (habe ich natürlich versucht aber hat auch nicht geklappt).

Frage
Muss ich noch irgendwelche Einstellungen an dem vorgelagerten Router (TP-Link) vornehmen?
- Irgendwas an der Firewall? Portforwarding?
- Statische Routen eintragen?
Muss ich der Wireguard-Verbindung bei Server / Client in der Konfig irgendwas von der Kaskade mitteilen?

Vielen Dank für eure Hilfe!

Sobald ich aber die Router kaskadiere, kommt es zu keiner Verbindung.

Das ist schon komisch, denn B ist ja der Initiator, also der der die WG Verbindung aufbaut mit dem GL.inet. Port Forwardung usw. spielt da also keinerlei Rolle.
Die Kardinalsfarge ist WIE der davor kaskadierte TP-Link mit OpenWRT betrieben wird??

Als einfacher, stinknormaler Layer 2 Accesspoint wie HIER beschrieben.
Als Router wie es HIER beschrieben ist.

In ersterer Variante sollte es keinerlei Probleme geben. Ein einfacher AP arbeitet als simple Layer 2 Bridge im gleichen IP Netz wie das Smartphone.
Bei der zweiten Variante im Router Mode sieht das deutlich anders aus.
Hier gibt es wieder 2 Szenarien:

Der OpenWRT arbeitet im Router Mode, routet also transparent zwischen beiden IP Netzen WLAN und LAN
Der OpenWRT arbeitet im Gateway Mode und macht NAT (Adress Translation) zwischen beiden IP Netzen WLAN und LAN

Beim Router Mode hättest du das Problem das das dann zwingend eine statische Route auf dem Smartphone erfordert. Siehe auch Routing Tutorial.
Smartphones lassen solche Konfiguration in der Regel nicht zu so das zu vermuten ist (geraten) der Router arbeitet im Gateway Mode.
Im Gateway Mode wo der Router mit NAT arbeitet wäre einen statische Route zwar nicht erforderlich aber ggf. können die WG Pakete nicht passieren.
Hier ist es also hilfreich wenn du in deiner o.a. Skizze sehr genau angibst wo WAN und LAN Ports und wo NAT, Adress Translation aktiv ist und wo nicht.
Damit wüsste man WO ggf. die WG Pakete im Standort B hängen bleiben.

Einfacher Troubleshooting Tip:
Um überhaupt zu checken das deine Wireguard Pakete durch die Router Kaskade am Smartphone ankommen solltest du testweise einen Rechner mit Wireshark Sniffer ins Smartphone WLAN verbinden. (Siehe zu Wireshark auch hier)
Damit kannst du dann den Traffic im WLAN überwachen.
Im GL.inet WG Router setzt du dann den Parameter "Endpoint =" auf die IP Adresse des Wireshark Rechners. (Endpoint = <ip_wireshark_wlan>:58224)
Der GL.inet als WG Initiator sendet die WG Frames nun testweise an den Wireshark als Peer und dann siehst dir einmal an ob dort überhaupt UDP 58224 Pakete vom Wireguard ankommen.
Ist das der Fall werden sie korrekt vom TP-Link OpenWRT weitergeleitet. Wenn nicht hast du dort ein Problem mit dem Setup.
Als 2ten Test solltest du vom Wireshark Rechner einen Ping auf xxxxx.myfritz.net ausführen. Der muss klappen was dann die Connectivity aus dem WLAN zur FB verifiziert.

Dieses einfachen Tests (auf die man eigentlich auch leicht selber kommt...) solltest du einmal durchführen um überhaupt erstmal zu lokalisieren WO der Fehler liegt.
Es muss irgendwo ein Konfigfehler im TP-Link sein. Das zeigt das es ohne ihn klappt.

Beim Router Mode hättest du das Problem das das dann zwingend eine statische Route auf dem Smartphone > erfordert. Siehe auch Routing Tutorial.
Smartphones lassen solche Konfiguration in der Regel nicht zu so das zu vermuten ist (geraten) der Router arbeitet > im Gateway Mode.
Im Gateway Mode wo der Router mit NAT arbeitet wäre einen statische Route zwar nicht erforderlich aber ggf. > können die WG Pakete nicht passieren.

-> Ja der Router macht NAT.

Ich habe mal die von dir vorgeschlagenen Tests gemacht:

Rechner mit Wireshark ins Smartphone WLAN. Endpoint des WG-Client auf den Rechner gesetzt.
-> Im Wireshark sehe ich, dass auf Port 58224 was ankommt, "Handshake initiation".

Rechner ist noch mit Smartphone verbunden. Ping auf xxxxx.myfritz.net.
-> Das Ziel wird erfolgreich erreicht.

Was ich auch noch probiert habe und nicht verstehe:
- In Luci gibt es unter Network->Diagnostics auch die Möglichkeit, einen Ping auf eine Adresse zu machen

Folgende Konstellationen habe ich probiert:
TP-Link bekommt Internet vom Smartphone.
-> Auf dem TP-Link in der Diagnose einen Ping auf xxxxx.myfritz.net funktioniert
-> Ein am Lan-Port angeschlossene Rechner kann sämtliche IPv4 Adressen im Inet anpingen. IPv6 Adressen kann er aber nicht erreichen. Unter IP-config sehe ich, dass der Rechner vom DHCP sowohl eine IPv4 als auch eine IPv6 zugewiesen bekommen hat. Ein IPv6 Standardgateway wird nicht angezeigt.

GL.Inet (wireguard ausgeschaltet) hängt mit seinem WAN-Port am TP-Link (der über das Smartphone Internet hat). NAT aktiv.
-> Auf dem GL.Inet in der Diagnose einen Ping auf xxxxx.myfritz.net funktioniert nicht.
-> Auf dem GL.Inet in der Diagnose einen Ping auf eine IPv4 funktioniert
-> Ein am Lan-Port angeschlossene Rechner kann sämtliche IPv4 Adressen im Inet anpingen. IPv6 Adressen kann er aber nicht erreichen.

TP-Link rausgenommen. GL.Inet hängt über WLAN->Smartphone im Inet (Wireguard ausgeschaltet).
-> In der Diagnose können sowohl IPv4 als auch IPv6 Adressen erreicht werden
-> Ein angeschlossener Rechner kann sowohl IPv4 als auch IPv6 Adressen erreichen. Der Rechner bekommt eine IPv4 und eine IPv6 als auch ein IPv4 und IPv6 Standardgateway.

Ich habe zugegeben noch nicht deine vorgeschlagene IPv6 Literatur gelesen... aber für mich sah es so aus, dass irgendwas auf dem TP-Link falsch konfiguriert ist, dass keine IPv6 Pakete aus dem Lan ins Inet kommen. Ich hab dann ewig rum gemacht und in einem letzten Akt der Verzweiflung einfach mal versucht, die funktionierende Konfiguration vom Gl.Inet zu exportieren und in den TP-Link reinzuspielen. Ich hatte bei Inkompatibilität auf eine Fehlermeldung mit Abbruch gehofft... habe allerdings wie es aussieht Elektroschrott produziert, der TP-Link will nicht mehr booten. Bekommt man das noch irgendwie wieder hingebogen?

Mein letzter Versuch wird jetzt sein, den Gl.Inet mal zu meinem Nachbarn zu bringen und dort anzuschließen. Vielleicht klappt ja dann gleich alles und es lag wirklich nur am TP-Link.

IPv6 Adressen kann er aber nicht erreichen.

Dann rennt dort ggf. kein IPv6?! Was sagt denn ein ipconfig (sofern es Winblows ist)?

dass der Rechner vom DHCP sowohl eine IPv4 als auch eine IPv6 zugewiesen bekommen hat.

Hoffentlich dann auch eine Unique Local Adressse (ULA) und keine Link-Local-Address (LLA) bzw. verbindungslokale Adresse mit dem Präfix "fe80::/64"??
Letztere gelten nur lokal und sind unroutebar. (Siehe auch HIER!)
Ohne hilfreiche Infos von dir dazu kann man nur Kristallkugeln.

Ein IPv6 Standardgateway wird nicht angezeigt.

Dann macht oder kann der TP-Link kein IPv6 oder du hast ihn für v6 falsch konfiguriert. Ist ja aber auch kein Hinterungsgrund solange v4 sauber rennt.

In der Diagnose können sowohl IPv4 als auch IPv6 Adressen erreicht werden

Dann gibt der TP-Link die per Prefix Delegation gelernten v6 Netze nicht an sein LAN weiter. Vermutlich eine Fehlkonfiguration.
Wenn der GL.inet das kann was vergibt der denn für ein v6 Adresse im LAN? Ist das was mit 20xx::....?

dass irgendwas auf dem TP-Link falsch konfiguriert ist, dass keine IPv6 Pakete

Das ist ganz sicher der Fall. Fazit: Das obige Buch lesen und verstehen...

Aber v6 ist ja für dein Setup auch nicht kriegsentscheidend wenn v4 fehlerfrei rennt.

der TP-Link will nicht mehr booten. Bekommt man das noch irgendwie wieder hingebogen?

Ja, Reset Taste drücken bzw. eine Factory Reset Prozedur ausführen, dann kommt der mit den Defaults wieder hoch.
War aber auch ziemlich dumm, denn deren Konfig Files unterscheiden sich ja fundamental, da 2 völlig unterschiedliche Hersteller. Du tankst ja auch kein Benzin in ein Diesel KFZ...ohne Worte!
Kauf dir einen 25 Euro Mikrotik Router, da hast du deutlich weniger Stress mit als den GL.inets.

gelöst Frage Netzwerke VPN

Heiß diskutiert