[Gelöst] VPN zwischen 7490 und TP-Link Archer MR600

[Siggiminator]

Moin,

Ich habe ein VPN zwischen meiner Fritz!Box 7490 (192.168.0.1/24) und einem TP-Link Archer MR600 (192.168.1.1/24) eingerichtet. Die Verbindung wurde beim ersten Versuch hergestellt, und ich kann von meinem Computer (192.168.1.10) auf der Archer Seite alle Geräte über das VPN ansprechen, also http://192.168.0.40 (ein Drucker) zum Beispiel öffnet problemlos.
Nur in die andere Richtung geht es nicht; von einem PC (192.168.0.10), kann ich weder ping'en noch über http etc auf Geräte im 192.168.1.0 Netz zugreifen.

Woran könnte das liegen?

EDIT:
Screenshots der Konfiguration:

EDIT2:
Nicht wirklich eine Lösung, aber das Problem klar eingegrenzt: Die Firewall regeln des Archer (Firmware Version:1.2.0 0.9.1 v0001.0 Build 200511 Rel.44954n) erlauben keinen zugriff von VPN->lokales Netzwerk. Das VPN funktioniert sonst einwandfrei.

Archer:


Fritz!Box:

 

[PeterPawn]

Woran könnte das liegen?

Am ehesten wohl an der Konfiguration.

EDIT:
OK, nachdem das "nachgereicht" wurde in #1, kann man jetzt zumindest mal "gezielt raten" und weiß immerhin schon, daß auf der FRITZ!Box-Seite (korrekterweise) eine LAN-LAN-Kopplung verwendet wurde.

Damit würde bei mir als Nächstes die Konfiguration des benutzten "PC" (192.168.0.10) in den Fokus rücken - anstatt die "gesamte Strecke" von der 192.168.0.10 zu einem Client im LAN des Archer zu prüfen, kann/sollte man erst mal den direkten Endpunkt der VPN-Verbindung (also den Router selbst) versuchen zu erreichen. So kann man das weiter eingrenzen, ob es eher auf der LAN-Seite des Archer liegt oder doch schon an der Strecke bis zum (entfernten) VPN-Peer.

PS: Bilder bitte als "Vorschau" einbinden - sonst macht's (mit entsprechendem Kommentar) ein Moderator (nur sollte man sich nicht darauf "verlassen" und es besser selbst gleich richtig (bzw. wie hier Usus und vorgegeben) machen).

 

[Siggiminator]

Jetzt sind die Screenshot als Vorschau drin, Entschuldigung.
Der Rechner 192.168.0.10 kann auf alle Geräte 192.168.0.X zugreifen, aber nicht auf den Archer unter 192.168.1.1, auch ein PING wird nicht beantwortet.
Ich würde ja vermuten das die Firewall des Archers 192.168.0.0 -> .192.168.1.0 nur bei 'state RELATED,ESTABLISHED' zulässt, oder könnte es noch woanders dran liegen?

 

[PeterPawn]

Verstehe ich das richtig, daß sich #1 weitgehend erledigt hat (für alles, was nicht direkt auf dem VPN-Peer liegt) und "nur" noch das Problem übrig ist, daß das Gateway selbst nicht erreichbar ist?

Das würde dann in der Tat (zumindest auch nach meiner Erfahrung) dafür sprechen, daß das Problem direkt auf dem TP-Link-Router zu suchen ist - der Traffic für die anderen Clients ist halt "FORWARD", der für lokale Ziele auf dem Router ist "INPUT" bzw. "OUTPUT". Ich habe leider keine Ahnung, wie das in der TP-Link-Firmware aussieht und würde hier jetzt meinerseits passen - ich halte es dann für erwiesen, daß die FRITZ!Box-seitige Konfiguration stimmt (es gibt für die FRITZ!Box ja keinen Grund, den Traffic für die .1 auf der anderen Seite anders zu behandeln, als den für alle anderen Clients) und Dein Problem dann zumindest nichts mit dem FRITZ!OS zu tun hat bzw. auf dieser Seite der VPN-Verbindung zu korrigieren wäre.

Ob das auf dem TP-Link dann schon beim Inbound-Traffic nicht klappt oder erst Outbound-Pakete blockiert und/oder nicht geroutet werden, kriegt man sicherlich nur mit dessen Diagnose-Werkzeugen heraus ... und da kenne ich mich nicht (gut genug) aus. Aber auch dort müßtest Du unter "Advanced -> System Tools -> Diagnostic" eigentlich Testmöglichkeiten finden und die Security-Einstellungen in der TP-Link-Firmware sind eigentlich immer sehr umfangreich (wenn auch manchmal für Laien vielleicht verwirrend). Ich weiß ja nicht, welche Dienste auf dem Router Du da erreichen willst (und noch einmal: Ich kenne die Firmware für dieses Modell nicht im Detail.) - aber falls die über VPN erreichbaren Clients auch als "remote" zählen, könnte schon für den Zugriff auf die Verwaltungsfunktionen des GUI von einem VPN-Client aus die Freigabe des "Remote Management" erforderlich sein ... bzw. ich würde da zumindest mal einen Blick und ggf. auch einen Versuch wagen, wenn das noch nicht eingestellt sein sollte.

 

[Siggiminator]

Vielen Dank für die Hilfe erstmal.
Nein, #1 ist noch nicht behoben, ich kann von 192.168.0.10 auf weder 192.168.1.1 noch auf irgendein anderes Gerät im Archer netzwerk zugreifen.

Leider hat der Archer MR600 eine 'neue' Art Firmware (Version:1.2.0 0.9.1 v0001.0 Build 200511 Rel.44954n), da ist leider kaum debugging möglich. 'Diagnostics' überprüft nur ob die Internetverbindung geht...
(Es gibt online sogar einen Emulator der Firmware: https://emulator.tp-link.com/mr600-v1-en/index.htm)

Ich habe zwischenzeitlich beim Archer die IPv4 SPI Firewall und 'NAT Boost' ausgestellt, das hat aber auch nicht geholfen.

 

[PeterPawn]

Nein, #1 ist noch nicht behoben, ich kann von 192.168.0.10 auf weder 192.168.1.1 noch auf irgendein anderes Gerät im Archer netzwerk zugreifen.

OK, ich hielt das im zweiten Satz in #3 nur für einen Schreibfehler (die "0" im dritten Tupel anstelle der "1"), weil es - gerade bei einem Windows-PC - nicht wirklich eine Rolle spielt, ob der andere lokale Dienste erreichen kann ... das ist üblicherweise mit so ziemlich jeder Einstellung (gerade auch in der Firewall) schon standardmäßig möglich.

Gibt's denn bei 192.168.1.0/24 nur den einen PC? Wenn nicht, was passiert denn mit anderen Geräten, wenn die auf irgendetwas im Netz 192.168.1.0/24 zugreifen sollen?

Ziel wäre es dann ja doch wieder, erst mal zu ermitteln, ob das nun im LAN der FRITZ!Box schon klemmt oder doch erst im Router beim VPN. Selbst wenn es kein anderes Gerät geben sollte - was sind denn die IP-Einstellungen dieses PC und was läuft da überhaupt drauf? Unter "PC" kann man sich ja alles Mögliche vorstellen, vom Linux-Gerät über Windows bis hin zu einem Gerät mit MacOS (in absteigender Folge der "Nützlichkeit" ). Wenn das Gerät die IP-Einstellungen über DHCP erhält, bitte auch die angeben - interessant ist allerdings in allererster Linie das "Gateway".

Anstelle von "ping" ist auch ein "traceroute" sinnvoller (bei Windows dann "tracert") - da sieht man dann "hop for hop", welchen Weg die Pakete nehmen und bis wohin es noch Antworten gibt.

 

[erik]

Versuch doch mal eine statische Route in der Fritzbox einzurichten. Ich weiß nicht ob das bei der VPN-Einrichtung automatisch passieren sollte, aber offenbar funktioniert das bei Dir nicht.

 

[PeterPawn]

Besser nicht ... wenn die FRITZ!Box tatsächlich das "default gateway" ist und aller Traffic für die Seite des Archer auch bei ihr ankommt, ist das (a) gar nicht erforderlich und (b) auch nicht möglich, weil das FRITZ!OS nur statische Routen zulassen müßte, die über "dev lan" gehen.

Selbst in Konstellation mit einem zweiten "entfernten" IP-Netz wird dann das "Routing" (was letztlich immer noch keines ist, denn es geht nur um die Selektion der Pakete für den VPN-Tunnel) bei AVM in der VPN-Konfiguration realisiert - hier ist JEDE Einstellung zum Routing in der FRITZ!Box falsch und führt im schlechtesten Falle nur dazu, daß der Traffic gar nicht beim AVM-WAN-Stack (also "dev dsl") ankommt ... solange es keinen passenderen Eintrag gibt, wird die "default route" genommen und die geht genau über das erwähnte "dev dsl", wo der Traffic für das VPN auch hin muß.

Solche Eintragungen machen höchstens dann einen Sinn, wenn ein VPN-Gateway eben genau nicht gleichzeitig der Edge-Router (mit der Default-Route) ist - was hier ja offensichtlich nicht der Fall ist.

Welches Gateway sollte man denn auch für so eine statische Route dann eintragen? Die FRITZ!Box selbst? Das macht ja nicht sooo viel Sinn - immerhin müßten die Pakete ja schon in der Box angekommen sein, damit so ein Eintrag in der Routing-Tabelle überhaupt eine Rolle spielen würde.

 

[erik]

Solche Eintragungen machen höchstens dann einen Sinn, wenn ein VPN-Gateway eben genau nicht gleichzeitig der Edge-Router (mit der Default-Route) ist - was hier ja offensichtlich nicht der Fall ist.

Du hast natürlich Recht

Welches Gateway sollte man denn auch für so eine statische Route dann eintragen? Die FRITZ!Box selbst? Das macht ja nicht sooo viel Sinn - immerhin müßten die Pakete ja schon in der Box angekommen sein, damit so ein Eintrag in der Routing-Tabelle überhaupt eine Rolle spielen würde.

Stimmt. Dann war mein Vorschlag für die Tonne.

 

[Siggiminator]

Vielen Dank für die Diskussion. Ich habe mein Netzwerk vereinfacht dagestellt... hier ist es (etwas) vollständiger.
192.168.0.1 Fritzbox hat 2 Windows PCs, 1 Linux PC, 1 Mac, diverse laptops, raspberry PIs, etc... die können alle miteinander kommunizieren. Habs von 2x linux und 1x windows probiert auf 192.168.1.1 und 192.168.1.10 zuzugreifen, weder ping, noch http kommen an. Traceroute siehe unten. Die Fritzbox ist der VDSL router und gateway. Statische public IP.
192.168.1.1 Der Archor router steht im Arbeitszimmer, und hat testsweise einen Rasperry Pi (kabel) und einen Windows rechner dran (wlan). Die können auch miteinander kommunizieren, und beide können http, ssh etc auf das 192.168.0.x netzwerk zugreifen. Der Archor ist ja ein 4G+ router, und mit Vodafone bekomme ich schon seit mehreren Tagen 130/35Mbit down/up, ziemlich konstant... viel besser als mein VDSL... aber darum geht es ja gerade nicht. Das ist Carrier Grade NAT, aber da das VPN ja von einer Richtung aus problemlos geht, kann es daran ja nicht liegen (Packete gehen ja in beide Richtungen, aber eben nur solange der erste Versuch vom Archor netz ausgeht).

(Sollte nicht relevant sein, aber zur vollständigkeit)
192.168.2.1 Weiter Fritzbox mit LAN-LAN koppelung. Hier geht 192.168.0.X <-> 192.168.2.X alles.

[email protected]:~$ traceroute 192.168.1.1
traceroute to 192.168.1.1 (192.168.1.1), 30 hops max, 60 byte packets
1 fritz.box (192.168.0.1) 0.402 ms 0.495 ms 0.651 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *

 

[PeterPawn]

Dann stelle ich mal noch die Frage nach der Firmware-Version der 7490. AVM hat zur 07.19-Labor-Reihe intern einiges umgebaut - allerdings auch wieder nicht so viel, daß das hier irgendwelche Auswirkungen haben sollte.

CGNs sind immer etwas schwierig - das liegt u.a. daran, daß das AVM-VPN immer etwas zickig reagiert (oder zumindest reagiert hat), wenn es sich in der Rolle des Initiators wähnte und dann aber keine Verbindung zustande kam. Daran glaube ich hier zwar auch nicht (auch wenn jede Richtung eine eigene SA hat), aber ich würde es schon zur Vermeidung von (ggf. auch erst künftigen) Problemen verhindern, daß die 7490 hier ihrerseits selbst einen Verbindungsaufbau versuchen KANN.

Leider geht das wohl nur mit "handgemachten" Konfigurationsdateien (wobei ich mir für die 07.21 da nicht so ganz sicher bin, unter diesem Aspekt habe ich das noch nicht getestet und meine Test-Box mit 07.21 rödelt gerade endlos, wenn ich die VPN-Seite aufmachen will) und daher müßte man hier aus der Konfigurationsdatei in der 7490 einfach das "remotehostname" entfernen. Zumindest war das bisher immer die einzige (bzw. die sicherste) Methode, eine FRITZ!Box dazu zu verdammen, ausschließlich in der Rolle des "responders" auf die Kontaktaufnahme des Peers zu warten. Da der TP-Link hier ohnehin auch nicht erreichbar wäre, ist das schon mal eine klare "Empfehlung" meinerseits. Man kann auch die vorhandene VPN-Konfiguration aus einer Export-Datei ziehen, bearbeiten und dann separat wieder (über das VPN-GUI) einspielen.

Allerdings glaube ich auch nicht, daß damit das Problem gelöst ist ... außer ich habe das hier:

Packete gehen ja in beide Richtungen, aber eben nur solange der erste Versuch vom Archor netz ausgeht

dann noch einmal falsch verstanden und Du willst damit eigentlich sagen, daß beim Verbindungsaufbau von der TP-Link-Seite (das ist ja der Einzige, der überhaupt funktionieren kann - keine Ahnung, ob die TP-Link-Firmware da noch etwas wie "always on" bzw. "on demand" unterstützt) der Tunnel aufgebaut wird und dann auch von beiden Seiten her funktioniert - es also letztlich nur dann scheitert, wenn der Archer keine P1 einleitet und von seiten der FRITZ!Box selbst ein Verbindungsaufbau erfolgen müßte.

Dann müßtest Du tatsächlich auf der Archer-Seite irgendetwas suchen, womit regelmäßig Pakete für das LAN der FRITZ!Box erzeugt werden können, damit das zum Tunnelaufbau führt - die FRITZ!Box KANN bei CGN (auf der Archer-Seite) ihrerseits niemals selbst einen Tunnel aufbauen (außer der Provider unterstützt PCP, was der Router dann auch verwenden müßte - m.W. ist aber AVM bisher immer noch der einzige Hersteller, der das in großem Stil umgesetzt hat).

Wenn der Archer das selbst nicht kann, kann das ja auch der RasPi dort übernehmen ... alle 60 Sekunden ein "ping" zur (LAN-)Adresse der 7490 sollte den Verbindungsaufbau auch zuverlässig einleiten - halt mit einer (max.) Latenz von ebendiesen 60 Sekunden (beim Verbindungsaufbau).

 

[Siggiminator]

Dann stelle ich mal noch die Frage nach der Firmware-Version der 7490. AVM hat zur 07.19-Labor-Reihe intern einiges umgebaut - allerdings auch wieder nicht so viel, daß das hier irgendwelche Auswirkungen haben sollte.

FRITZ!OS: 07.21.

CGNs sind immer etwas schwierig - das liegt u.a. daran, daß das AVM-VPN immer etwas zickig reagiert (oder zumindest reagiert hat), wenn es sich in der Rolle des Initiators wähnte und dann aber keine Verbindung zustande kam. Daran glaube ich hier zwar auch nicht (auch wenn jede Richtung eine eigene SA hat), aber ich würde es schon zur Vermeidung von (ggf. auch erst künftigen) Problemen verhindern, daß die 7490 hier ihrerseits selbst einen Verbindungsaufbau versuchen KANN.

Leider geht das wohl nur mit "handgemachten" Konfigurationsdateien (wobei ich mir für die 07.21 da nicht so ganz sicher bin, unter diesem Aspekt habe ich das noch nicht getestet und meine Test-Box mit 07.21 rödelt gerade endlos, wenn ich die VPN-Seite aufmachen will) und daher müßte man hier aus der Konfigurationsdatei in der 7490 einfach das "remotehostname" entfernen. Zumindest war das bisher immer die einzige (bzw. die sicherste) Methode, eine FRITZ!Box dazu zu verdammen, ausschließlich in der Rolle des "responders" auf die Kontaktaufnahme des Peers zu warten. Da der TP-Link hier ohnehin auch nicht erreichbar wäre, ist das schon mal eine klare "Empfehlung" meinerseits. Man kann auch die vorhandene VPN-Konfiguration aus einer Export-Datei ziehen, bearbeiten und dann separat wieder (über das VPN-GUI) einspielen.

Sehr interessant, ich wusste nicht das geht.

dann noch einmal falsch verstanden und Du willst damit eigentlich sagen, daß beim Verbindungsaufbau von der TP-Link-Seite (das ist ja der Einzige, der überhaupt funktionieren kann - keine Ahnung, ob die TP-Link-Firmware da noch etwas wie "always on" bzw. "on demand" unterstützt) der Tunnel aufgebaut wird und dann auch von beiden Seiten her funktioniert - es also letztlich nur dann scheitert, wenn der Archer keine P1 einleitet und von seiten der FRITZ!Box selbst ein Verbindungsaufbau erfolgen müßte.

Nein, leider missverstehen wir uns noch immer. Was ich ausdrücken wollte ist das ssh (und andere protokolle) problemlos funktionieren über das VPN, aber eben nur wenn die session von der archer seite initiert wird. also [email protected]:~$ ssh 192.168.0.20 funktioniert (.1.x is archer, .0.x is fritzbox), [email protected]:~$ ssh 192.168.1.10 aber nicht, timeout. Also die IPSec verbindung funktioniert.

Ich habe heute morgen mal Remote Management bei dem Archer eingestellt (also das webinterface des Archer ist von außen aus erreichbar), und nun kann ich das Webinterfaces des Archer von dem Netz der Fritzbox übers VPN unter http://192.168.1.1 abrufen. Also liegt es an den Firewall regeln des Archer. Leider gibt es in der UI gar keine Optionen das zu verändern. Und openwrt etc gibt es (noch) nicht für das Teil . Mal sehen ob der offizielle Support von tp-link antwortet!

Vielen Dank für die Hilfe!