[Problem] VPN Fritzbox zu Fritzbox an LAN4

[jogi2573]

Hallo zusammen,
ich bin z.Zt. am Verzweifeln, da ich meiner Meinung nach alles so eingestellt habe, wie es auf der AVM Seite beschrieben wird. Die Boxen verbinden sich, aber es passiert nichts.

Aufgabe:
Ich möchte zwei entfernte Fritzboxen übers Internet via VPN verbinden, wobei die eine Fritzbox alles was an LAN4 angeschlossen ist zur anderen Fritzbox tunneln soll.

Hardware A: (ich nenne sie "Slave")
Fritzbox 5490
Adresse: ***FRITZBOX A 5490***.myfritz.net
Interne IP: 192.168.20.1
(siehe VPN_A.jpg)


Hardware B: (ich nenne sie "Master")
Fritzbox 7490
Adresse: ***FRITZBOX B 7490***.myfritz.net
Interne IP: 192.168.10.1
(siehe VPN_B.jpg)


Eine Verbindung kommt auch zustande, auf der Weboberfläche von beiden Boxen erscheint die Vebindung grün, jedoch wird nichts getunnelt. Ebenfalls erhält das Gerät welches ich an Fritz_A (Slave) am LAN4 anschließe eine IP 192.168.21.XX zugewiesen, jedoch, es ist nicht möglich darüber eine Internetseite aufzubauen. Auch ein anpingen geht nicht.
Noch ergänzend ist zu sagen, dass wenn ich auf Fritz_A (Slave) den Haken "VPN-Tunnel ist nur an den ausgewählten LAN-Anschlüssen der Fritz!Box verfügbar" herausnehme, wird eine besehende VPN Verbindung auf beiden Boxen mit "grün" angezeit, jeodch funktioniert auf Fritz_A (Slave) nichts.

Was mache ich falsch? Würde mich über eine Lösung freuen.


Gruß Jogi2573

 

[PeterPawn]

Du mußt Dich einfach mal entscheiden, ob das entfernte Netz nun 192.168.20.0/24 oder 192.168.21.0/24 sein soll - so, wie das in den Screenshots steht, sollte das eher nichts werden. Es interessiert die entfernte Box nicht im Geringsten, welches Netz die Box mit der separaten "ipsecbr0" (so heißt das Interface vermutlich in den Support-Daten) an den anderen LAN-Anschlüssen (also abseits von LAN4) verwendet - was sollte sie mit dieser Information auch anfangen?

 

[jogi2573]

Hallo PeterPawn,

vielen Dank für die schnelle Antwort,
so wie ich es verstanden habe, soll ich auf den "SLAVE" unten als Netzwerkpräfix die 192.168.20.0 eintragen.
Schnon geschehen, leider ohne Erfolg.

Zur Konstrolle habe ich mal wieder der "SLAVE"-Box sagen wollen "tunnel doch bitte alle Ports", denn da muß ich unten im Feld (siehe VPN_20_all.jpg) nichts eintragen, geht aber auch nicht.

Was habe ich hier falsch verstanden?
Gruß Jogi2573

 

[PeterPawn]

Was habe ich hier falsch verstanden?

Ich rate mal wild und behaupte, daß die 5490 ja wohl das Netz 192.168.20.0/24 als ihr eigenes LAN (an den verbleibenden LAN-Ports) verwendet.

Die richtige Schlußfolgerung wäre es also gewesen (ausgehend von den in #1 gezeigten Konfigurationen), in der 7490 bei "Entferntes Netzwerk" 192.168.21.0/24 zu konfigurieren ... denn wie ich bereits weiter oben schrieb, interessiert es die 7490 kein Stück, welches Netz die 5490 an den LAN-Ports 1 bis 3 und im WLAN verwendet - entscheidend ist es nur, was sie für das zusätzliche Netzwerk an "LAN4" benutzt, denn genau in diesem Netzwerk soll der VPN-Tunnel ja auch enden. Da es keine DHCP-Requests über den Tunnel gibt (das AVM-VPN kann nur ab L3 tunneln und DHCP arbeitet auf L2), muß die 5490 dort schon selbst den DHCP-Hampelmann geben und nur dafür sind die Angaben (bei der 5490) in den unteren Feldern.

Da erscheint es nur logisch, wenn die Angaben in der 7490, was als "entferntes Netzwerk" bei der 5490 benutzt wird, sich auch genau auf dieses zusätzliche Netzwerk beziehen ... ergo: In der 7490 muß - bei diesem Typ von Verbindung - einfach nur das Netzwerk konfiguriert werden als "entfernt", was in der 5490 in den unteren Eingabefeldern angegeben wurde. EDIT: ... und das darf eben auch nicht dasselbe Netzwerk sein, wie es lokal ansonsten verwendet wird.

Das steht allerdings auch alles so in den KB-Artikeln von AVM ... man muß also nicht mal zwangsläufig verstehen, wie das zusammenarbeitet, um hier die richtigen Angaben zu wählen.

 

[jogi2573]

Hallo PeterPawn,
vielen Dank für die ausführliche Antwort, nun ich habe viel rumprobiert, als auch Deinen Tip befolgt, leider funktioniert es immer noch nicht, ich habe einmal wieder meine beiden Konfigurationen hier hochgeladen:

Was ist nun falsch? Könntest Du mir, oder evtl. ein anderes Foren-Mitglied weiterhelfen?
Vielen Dank.
Gruß Jogi

//edit by stoney: Bild geschrumpft

 

[PeterPawn]

Ich weiß nicht, wie es Dir geht ... aber ich lese da in den beiden Screenshots immer noch unterschiedliche Netzwerkadressen.

Und sollte es nach der Korrektur in der 7490 dann immer noch nicht funktionieren, würde ich Dir empfehlen, hier in anderen VPN-Threads einmal nachzulesen, welche Informationen man zur Diagnose bei VPN-Problemen bereitstellen sollte als Fragesteller, wenn man eine (passende) Antwort haben möchte (im Rahmen dessen, was so ein "freiwilliges Board" leisten kann im Vergleich zum Hersteller-Support).

EDIT: Die Konfiguration in der 5490 paßt aber auch noch nicht zur Beschreibung in #1 - das war nur - dank der Skalierung, die bei so riesigen Screenshots einsetzt, nicht direkt zu erkennen, daß in der 5490 bei der VPN-Konfiguration ja immer noch dasselbe Netz eingetragen ist für "ipsecbr0", welches (nach der Beschreibung in #1) auch für die 5490 ansonsten lokal genutzt wird. Ich meine mich zu erinnern, daß ich das zuvor schon angesprochen hatte und daß die AVM-Artikel das inzwischen deutlich klarstellen.

EDIT2:
=> 192.178.20.0/24 ist nicht gleich 192.168.20.0/24
=> wenn 192.168.20.0/24 das LAN der 5490 ist, kann es nicht gleichzeitig in der Konfiguration der 5490 als zusätzliches Netzwerk (an LAN4) verwendet werden
=> ja nachdem, welches "Zusatz-LAN" die 5490 dann am Ende tatsächlich konfiguriiert hat, muß in der 7490 auch die dazu passende Angabe konfiguriert sein

Ich weiß zwar nicht genau, was Du alles "probiert" hast, aber der Vergleich der Adressen in den beiden Boxen kann es schon mal nicht gewesen sein. Wenn ich die Screenshots aus #1 und #5 vergleiche, gibt es da - bis auf die Unterschiede beim Unkenntlichmachen der MyFRITZ!-Namen - ja eigentlich gar nichts, was sich geändert hätte. Die Netzwerkadresse in der 7490 ist immer noch genauso falsch ... nur wurden halt die beiden Netze "getauscht" und zwar in beiden Boxen. Hätte man - ausgehend von der Konfiguration im Bild in #1 - in der 5490 die korrekte Konfiguration einfach belassen und in der 7490 die richtige Adresse eingetragen (das wäre dann die 192.168.21.0/24 gewesen), wäre zumindest die Konfiguration erst mal passend und man kann sich auf "echte" Fehler bei der Benutzung freuen und diese ausräumen.

 

[Andreas1969]

Hallo zusammen, auf Rat von Robert stelle ich meine Frage einmal hier im Forum, da erhoffe ich mir eventuell sogar eine Lösung.
Ich schließe mich mal meinem Vorredner an, ich bekomme den Tunnel leider auch nicht an´s Laufen, sodass auch der gesamte Internettraffic darüber läuft.

Aufgabe:
Ich möchte auch zwei entfernte Fritzboxen übers Internet via VPN verbinden, wobei die eine Fritzbox alles was an LAN2 angeschlossen ist zur anderen Fritzbox tunneln soll (inklusive dem Internettraffic).
Im Gegensatz zu meinem Vorredner hab ich die Verbindung aber korrekt parametriert !
Der Tunnel selbst ist auch nicht das Problem, der läuft an sich mit vollem Datendurchsatz, aber nur, wenn ich die Option "Gesamten Netzwerkverkehr über die VPN-Verbindung senden" nicht gesetzt habe.
Das Routing zwischen den beiden Netzten klappt zwischen 192.168.2.0/24 und 192.168.3.0/24 auch einwandfrei, nur haben die Clients hinter dem LAN 2 Port keinen Internetzugriff.
Wenn ich dann die Option "Gesamten Netzwerkverkehr über die VPN-Verbindung senden" aktiviere, bricht die Fritzbox dann komplett zusammen, es funktioniert dann überhaupt nichts mehr.

Damit ich die Details jetzt nicht noch einmal komplett posten muss, verlinke ich mal auf das andere Forum, wo ich sämtliche Details schon beschrieben habe.
Hier die Einstellungen: Start
Und hier die Schlussanalyse: Ende

Vielleicht ist hier ja auch schon jemand auf das Problem gestossen und hat eine temporäre Lösung, bis AVM den Bug behoben hat.
Ich bedanke mich schon einmal für die Unterstützung.

 

[PeterPawn]

Ich versuch's mal und probiere einfach, meinerseits ausnahmsweise mal nicht herablassend zu werden oder zu wirken. Ich hoffe, es gelingt ...

Ich würde hier (wenn Du die Technik dafür hast) das Ganze erst mal lokal aufbauen (notfalls mit zwei Boxen, die als LAN1-Router konfiguriert sind), weil Du dann auch Zugriff auf beide Support-Dateien hast und notfalls leichter den Traffic auf den Interfaces mitschneiden kannst.

Ohne das "Gesamten Netzwerkverkehr ..." fehlt in der Box mit 192.168.3.0/24 an LAN2 die Information, daß auch an andere Ziele als 192.168.2.0/24 gerichtete Pakete ebenfalls in den Tunnel sollen. Mit der Option "Gesamten Netzwerkverkehr ..." wird dann für alle Pakete (Source any, Target 0/0, was dasselbe ist wie any) der Tunnel als Ziel definiert. Eigentlich sollte das theoretisch nur die Pakete betreffen, die jetzt auch am Port eintreffen, der als "ipsecbr1" von den anderen isoliert wurde.

Die restlichen Ports sollten davon nicht beeinflußt werden ... außer der AVM-WAN-Stack, an dem die Pakete für die Tunnel dann "ausgeleitet" werden (denn alle VPN-Pakete müssen über "dev dsl" und die Default-Route, einzelne Einträge gibt es nur für VPN-Verbindungen für Nutzerkonten, die lokale IP-Adressen im LAN kriegen), vergißt an dieser Stelle auf das "Absender-Interface" zu achten und wirft die Selektoren oder die Interfaces durcheinander.

Da das sicherlich auch eine Stelle ist, wo AVM im Rahmen der Nutzung der Crypto-Hardware Änderungen vornehmen muß, wäre ich aber nicht vollkommen von den Socken, wenn das in der Labor-Reihe passiert (Du schreibst ja, es ist auf beiden Seiten eine 07.19, aber eine ältere) - immerhin hat jede Verbindung ihre eigenen Keys und damit muß auch die Hardware zur Verschlüsselung anders konfiguriert werden, je nachdem, was hier das (erste) Ziel eines ausgehenden Pakets ist. Wieviele parallel verwendbare Pipelines die Crypto-Hardware bietet, ist bisher m.W. auch nicht wirklich bekannt - vielleicht sogar nur eine einzige.

Ob diese Vermutung mit der durchbrochenen Isoilation stimmt, müßte man daran überprüfen können, ob ein "ping" aus dem restlichen LAN B (also von 192.168.178.x/24) an die Adresse 192.168.2.1 (also für LAN A, was ja eigentlich nur am LAN2-Anschluß verfügbar sein sollte), am Ende korrekterweise unverschlüsselt auf dem "internet"-Interface landet oder nicht (bzw. nur in verschlüsselter und damit nicht erkennbarer Form, aber dann immerhin als ESP-Paket, was synchron zum Senden eines ICMP-Paketes auftaucht).

Die Mitschnitt-Funktion der Box sollte das hergeben - wobei es wirklich nur um das ausgehende Paket ginge, denn wenn das tatsächlich durch den Tunnel geht (weil die Isolation irgendwann "gelitten" hat und dann ist es natürlich auch wahrscheinlich, daß eine "default route" für LAN2 über den Tunnel, für den Rest in LAN B auch gilt, wenn man sie aktiviert hat) und sein Ziel an der zweiten Box erreicht, weiß diese natürlich trotzdem nicht, wohin sie die Antwort senden sollte (sie kennt ja nur 192.168.3.0/24 und nicht 192.168.178.0/24) und so würde diese (mangels passendem Selektor in der Box in LAN A) dort wieder übers Internet gehen und nicht durch den Tunnel.

Einen Versuch wäre es m.E. ansonsten auch wert, die zweite Regel in den Selektoren dahingehend zu ändern, daß als Absender nicht "any" verwendet wird, sondern nur das Segment, was an LAN2 konfiguriert ist, also die Regel auf "permit ip 192.168.3.0 255.255.255.0 any" zu ändern, in der Hoffnung, daß dann nur noch Pakete aus 192.168.3.0/24 (an beliebige Adressen) durch den Tunnel gehen. Auf der Gegenseite müßte alles bleiben wie bisher (also kein "Gesamten Netzwerkverkehr ..." auswählen) - da wüßte die Box ja schon, daß Antworten an 192.168.3.0/24 durch den Tunnel müssen. Wobei die zweite Regel Zeile in der Box an LAN B (permit ip any 192.168.2.0 255.255.255.0) ja ohnehin obsolet wird, wenn die zweite Regel (von AVM, die dann in der ersten Zeile steht) da hinzukommt - da kann man die dann auch gleich weglassen und es nur mit 192.168.3.0/24 als "Absender" versuchen, denn 192.168.2.0/24 ist in "any" natürlich eingeschlossen.

Wobei das tatsächlich ein dicker Bug wäre ... aber irgendwie auch eine naheliegende Erklärung für Deine Feststellung, daß bei aktviertem "Gesamten Netzwerkverkehr ..." auf der LAN B-Seite gar nichts mehr funktioniert. Eigentlich sollte diese Option ja auf das "ipsecbr1"-Interface beschränkt sein. Vielleicht hat das AVM aber auch schon längst gefixt und Du hast das Problem mit aktuellen Labor-Versionen gar nicht mehr.

Was Du jetzt machst (ob Du es erst mal untersuchst, vielleicht mit dem "ping" und einem Mitschnitt oder einen Workaround suchst mit anderen Selektoren oder erst mal die aktuellste Labor-Version probierst), mußt Du halt selbst wissen - ich persönlich würde mit der neuesten Version beginnen, weil entweder die Chance besteht, daß es schon gefixt ist oder man dann wenigstens, wenn die weiteren Analysen auf "Bug" hindeuten, auch die Meldung für die aktuelle Labor-Version weiterleiten kann (hier würde ich Dir das sogar deutlich ans Herz legen, wenn es sich als Bug herausstellt) und die weniger wahrscheinlich bei AVM untergeht, als eine solche für längst vergessene Labor-Versionen.

Und auch wenn man im Moment keinen Zugriff auf die Box an LAN B hat (vielleicht ja doch über das GUI auf der WAN-Seite?), bräuchte man dort im LAN (also auf einem Gerät aus 192.168.178.0/24) nur irgendeine "Quelle" für ein passendes Paket ... das muß ja kein ICMP sein, auch ein TCP-SYN an eine Adresse aus 192.168.2.0/24 würde ausreichen, wenn man das an der Box im LAN A mitschneiden kann, wenn es "aus dem Tunnel kommt" - das wäre ja schon ein erster Beweis, denn das dürfte natürlich nicht passieren.

EDIT: Wenn man kein Gerät in LAN B hat, wo man einen Request erzeugen könnte, aber per Fernwartung auf die FRITZ!Box dort kommt, kann man auch bei den Podcasts oder als Live-Bild eine URL aus 192.168.2.0/24 einrichten (die muß ja nicht existieren), wenn man die irgendwie aufrufen "lassen kann" (z.B. durch telefonische Anweisung an die Eltern mit dem FRITZ!Fon o.ä.). Auch das Eintragen einer SMTP-Serveradresse aus 192.168.2.0/24 und der anschließende Test der Einstellungen sollte ja wenigstens ein TCP-SYN-Paket hervorbringen können, auch wenn natürlich ein 3-Way-Handshake für TCP nie klappen wird auf diese Weise.

 

[Andreas1969]

@PeterPawn
Ich danke Dir erst mal ganz herzlich für Deine aufschlussreiche Antwort. Ich werde das mal in Ruhe austesten, am besten, wenn ich wieder länger vor Ort an Anschluss B bin.
Als erstes werde ich dann wohl die neueste Labor installieren, vielleicht hat sich das Problem damit ja schon erledigt. Wenn nicht, werde ich es nach Deiner Anleitung weiter analysieren.
Wünsche Dir noch schöne Rest Ostern

 

[Andreas1969]

So, die aktuelle Labor Version hab ich mal installiert. Das Problem ist dadurch aber nicht behoben, Fehler genau, wie zuvor, leider keine Änderung.
Als nächstes habe ich dann mal versucht, es ohne den gekapselten LAN 2 Port zum Laufen zu bringen.
Also den Haken an Fritzbox B "VPN-Tunnel ist nur an den ausgewählten LAN-Anschlüssen der Fritzbox verfügbar" herausgenommen.
Entsprechend hab ich dann in Fritzbox A die Gegenstelle von 192.168.3.0 auf 192.168.178.0 angepasst, sodass zwischen 192.168.2.0 (Fritzbox A) und 192.168.178.0 (Fritzbox B) geroutet wird.
Das funktioniert soweit, alle Clients an allen Ports Fritzbox B können mit allen Clients an allen Ports Fritzbox A kommunizieren und umgekehrt auch.

Dann an Fritzbox B den Haken "Gesamten Netzwerkverkehr über die VPN-Verbindung senden" aktiviert und Peng, auch da der Fehler, Telefonie tot, kein Client hat mehr zugriff auf´s Internet, also gleicher Fehler.
Diese Variante hatte aber definitiv noch mit OS 7.12 funktioniert, das hatte ich so schon am Laufen, nur entsprach der Datendurchsatz vom Tunnel damals nicht meinen Erwartungen, weshalb ich die Variante mit dem gekapselten LAN 2 gar nicht mehr probiert hatte.

 

[PeterPawn]

Zweimal LAN B im letzten Satz des ersten Absatzes? Habe ich da etwas falsch verstanden oder bist auch Du durcheinander gekommen?

Hast Du denn lokalen Zugriff auf die Box, bei der Du das "Gesamten Netzwerkverkehr ..." aktivieren willst? Das ist ja LAN B, wenn ich das richtig verstehe ... bist Du da dann vor Ort?

Wenn ja, ziehe doch mal in diesem Zustand (nichts geht mehr) die Support-Daten. Erstens sieht man darin, welche SA eingerichtet wurden bzw. ob da überhaupt welche eingerichtet wurden (sprich: ob die zweite Box die VPN-Verbindung danach noch aufbauen kann oder nicht). Zweitens findet man dann die eingerichteten Selektoren und die Auflistung der eingerichteten Netzwerk-Interfaces in dieser Support-Datei.

Ich bin auch nicht nur neugierig, wie das mit den Zugriffsmöglichkeiten auf die Boxen aussieht ... wenn man das genauer weiß (z.B. eben, ob man per Fernzugang da an den VPN-Einstellungen ändern und ggf. auch eine "handgemachte" Konfiguration importieren kann), kann man sich auch mögliche Tests für exakt die vorhandene Situation ausdenken.

So, wie ich #10 lese, funktioniert es ja auch nicht mehr, den gesamten Netzwerk-Verkehr über eine VPN-Verbindung zu schicken ... das ging aber eben vorher definitiv (und nicht nur bei Dir).

Die Frage, die sich mir hier stellt, wäre es erneut, ob die Verbindung überhaupt zustandekommt. Denn normalerweise müßte man ja schon vor dem Aufbau der VPN-Verbindung ein paar Zugriffe direkt über das WAN-Interface der Box ausführen (und natürlich auch die bereits einmal verschlüsselten Pakete dann direkt ausliefern, ohne erneute Runde durch die Verschlüsselung) ... angefangen bei der DNS-Abfrage, wo denn die Gegenstelle für das VPN zu finden wäre und beim Aktualisieren der eigenen IP-Adresse bei einem DynDNS-Service (da macht es ja häufig auch nicht soo viel Sinn, das über eine VPN-Verbindung zu machen, wenn der DynDNS-Service die IP-Adresse aus dem Absender der Anmeldung ableiten soll oder will).

Und so braucht auch eine solche Verbindung immer ein paar Ausnahmen ... zumindest war es bisher auch beim AVM-VPN so. Aber AVM hat auch die Verwaltung der ganzen VPN-Verbindungen in einen eigenen, neuen Daemon ausgelagert (der nennt sich "vpnd" und existiert erst seit 07.19) und auch da wären ein paar neue Fehler im Zuge dieser Umstellung sicherlich nichts Ungewöhnliches.

Auch im Zusammenhang mit DoT - eigentlich müßten DNS-Abfragen ja ständig direkt über das WAN-Interface gehen, ansonsten müßte beim Aufbau der VPN-Verbindung ja umgeschaltet werden und bei deren "Verlust" wieder zurück. Und ein solcher "Verlust" läßt sich auch nicht immer sicher feststellen - ohne DPD (dead peer detection) bemerkt man das häufig gar nicht. Also müßten eigentlich bei einer VPN-Verbindung, für die "Gesamten Netzwerkverkehr ..." eingeschaltet wird, noch ein paar mehr Regeln in der "accesslist" stehen ... sonst kann die Box diese Verbindung gar nicht erst aufbauen. Zumindest war es bisher ja so und ich kann mir eigentlich nicht vorstellen, daß AVM am Format etwas so Grundlegendes geändert hat - eher mangelt es vielleicht noch an der korrekten Umsetzung in diesen "Spezialfällen".

Daher ist das u.U. eine zweite, andere Baustelle mit diesem Test (selbst wenn's am Ende dieselbe Ursache sein mag) - wenn man das VPN auf einen einzelnen Port beschränkt, kann ja der DNS-Service der Box weiterhin über WAN gehen und diese VPN-Verbindung auch noch aufbauen. Bei einer auf einen einzelnen Port beschränkten Verbindung, gibt man für die Geräte an diesem Port ja sogar wieder den DNS-Server vor, weil der i.d.R. eben auch nur noch über die VPN-Strecke erreichbar ist und daher irgendwo im LAN auf der Gegenseite liegen sollte (sonst greift der Selektor mit der Zieladresse nicht) oder die lokale Box sein müßte (wenn der "multid" tatsächlich auch an ein "ipsecbrX"-Interface gebunden ist).

Mangels 7590 kann ich leider nicht parallel nachsehen, was da bei den einzelnen Änderungen an Einstellungen passiert und welche Auswirkungen das dann hat - mehr als Nachdenken kann ich also nicht anbieten. Höchstens noch einen Blick in eine Support-Datei ... wobei man die nicht in voller Schönheit in ein Forum stellen sollte. Aber die VPN-Abschnitte und die Interface-Anzeigen findet man in der Support-Datei auch und die würden ja schon reichen - leider brauchen die häufig auch noch eine "Nachbearbeitung" von Hand, weil da vieles enthalten ist, was man nicht veröffentlichen sollte (geht bei den DynDNS-Adressen der Peers schon los).

 

[Andreas1969]

Zweimal LAN B im letzten Satz des ersten Absatzes? Habe ich da etwas falsch verstanden oder bist auch Du durcheinander gekommen?

Da bin ich wohl beim Schreiben etwas durcheinandergekommen

Hast Du denn lokalen Zugriff auf die Box, bei der Du das "Gesamten Netzwerkverkehr ..." aktivieren willst? Das ist ja LAN B, wenn ich das richtig verstehe ... bist Du da dann vor Ort?

Ja, war vorhin mal für 1 Stunde vor Ort, wo ich es getestet hatte, die aktuelle Labor hatte ich vorher schon per Fernzugriff draufgebügelt.

Wenn ja, ziehe doch mal in diesem Zustand (nichts geht mehr) die Support-Daten.

Das mache ich beim nächsten Mal und schau mir dann die Support Daten an.

So, wie ich #10 lese, funktioniert es ja auch nicht mehr, den gesamten Netzwerk-Verkehr über eine VPN-Verbindung zu schicken ... das ging aber eben vorher definitiv (und nicht nur bei Dir).

Ja, das ging vorher definitiv noch mit der 7.12, hatte das bereits so am Laufen.

Mangels 7590 kann ich leider nicht parallel nachsehen, was da bei den einzelnen Änderungen an Einstellungen passiert und welche Auswirkungen das dann hat - mehr als Nachdenken kann ich also nicht anbieten. Höchstens noch einen Blick in eine Support-Datei

Die relevanten Details in nicht voller Schönheit kann ich die Woche ja dann mal einstellen, wenn ich die Supportdaten vor Ort gezogen hab, blöderweise geht das nicht von Extern, da ich bei gesetztem Haken für den gesamten Netzwerkverkehr keinen Zugriff mehr auf die Box an B habe und auch nicht mehr bekomme, bis ich den Haken vor Ort wieder rausgenommen habe.

Parallel habe ich den Bug über diesen Link
"https://avm.de/fritz-labor/frisch-aus-der-entwicklung/ihr-feedback/" auch nochmal an AVM gemeldet, mal schauen, ob sie darauf reagieren.

 

[Andreas1969]

So, heute kam die erste Antwort von AVM (da hatte ich das Problem geschildert, dass der Fehler in Verbindung mit ausgewählten LAN Ports auftritt).

Wir würde das Problem gern analysieren. Zunächst ist anzumerken, dass VPN-Tunnel nur an ausgewählten LAN-Port....' so funktioniert, dass der gesamte Datenverkehr am LAN-Anschluss über die VPN-Verbindung abgewickelt/geroutet wird. Damit dann auch der gesamte Internettraffic. Die Funktion hängt somit auch von der Konfiguration der VPN-Gegenstelle ab. Bei einer FRITZ!Box-LAN-LAN-Kopplung ist das nicht der Fall. VPN-Tunnel nur an ausgewählten LAN-....' und 'Gesamten Netzwerkverkehr über....' zusammen auswählen ist also im Konfigurationsmenü überflüssig, funktioniert aber bei uns dennoch. Man könnte den Haken 'Gesamten Netzwerkverkehr über....' automatisch setzen, wenn LAN-Anschlüsse ausgewählt wurden, oder deaktivieren. Jedenfalls funktioniert es bei mir uns. Erstellen Sie die Support-Daten bitte im Fehlerzustand die Support-Daten und beschreiben das aktuell vorliegende Problem

Die Antwort ist jetzt etwas ernüchternd, habe das Gefühl, dass es mal wieder wie´s Hornberger Schießen ausgeht
Ich weiß jetzt nicht so recht, wie ich darauf antworten soll.

Ich warte jetzt erst mal die Antwort auf meine zweite Anfrage ab, da hab ich AVM nochmals mitgeteilt, dass der Fehler generell auftritt, auch wenn kein einzelner LAN Port ausgewählt ist.
Mal schauen, wie Sie darauf antworten, die müssen den Fehler doch nachstellen können

 

[Andreas1969]

Gestern war ich wieder vor Ort an B
Habe den Fehlerfall noch mal erzwungen (Haken gesetzt) und dann die Exportdatei gezogen.
Die Exportdatei und, wie von AVM gewünscht, auch die Exportdatei der Gegenstelle an AVM mit nochmals einer genauen Fehlerbeschreibung gesendet.
Dummerweise hatte ich die beiden Exportdateien als ZIP File in die Mail gepackt.

Darauf kam heute die Antwort zurück:

ZIP-Archiver werden aus Sicherheitsgründen entfernt. Daher die Bitte, mir die Datein nochmals entpackt zu senden.

Naja, wenn ich das vorher gewusst hätte
Jetzt nochmal den zweiten Versuch gestartet und das Ganze in ungezippter Form verschickt.

Ich lasse mich mal überraschen, viel verspreche ich mir allerdings nicht, bin in der Vergangenheit schon mal extrem vom AVM Support enttäuscht worden
und musste mir eine Bastellösung bauen, um den damaligen Bug in der Fritzbox zu umgehen.
Man konnte damals den Fehler angeblich nicht nachstellen, obwohl ich AVM sämtliche Details und eine vollständige Analyse geliefert hatte.
Als Antwort kam damals, man könne den Fehler nicht finden/nachstellen, bzw. er existiert nicht, bei AVM würde das tun.
Um so enttäuschter war ich dann, als ich 2 Jahre später (mehrere OS Versionen weiter) in den Infos zu den Verbbesserungen / Fehlerbehebungen lesen musste, dass genau dieser Bug behoben wurde.
Hatte es dann auch sofort getestet und er war auch wirklich behoben.
Ich hoffe mal, dass es dieses mal nicht so endet.

 

[PeterPawn]

Ich drücke Dir die Daumen, wobei man AVM auch zugute halten muß an dieser Stelle, daß die intern tatsächlich fast alles komplett über den Haufen werfen und da kann so ein Bug schon mal auftreten - solange er im Rahmen von Beta-Tests in den Labor-Reihen dann auch gefunden wird.

Bei der 7490 gibt es seit der Labor-Version 75736 (in der 75207 fehlte das noch, dazwischen habe ich keine) ja auch die Möglichkeit, eine VPN-Verbindung auf einzelne Clients im "normalen" LAN zu beschränken (mit dem Abschnitt "allowed_vpn_clients" in einem Eintrag in der "vpn.cfg" - die Einstellungen dazu finden sich jetzt hinter dem "Erweiterte Einstellungen zum Netzwerkverkehr" bei einer VPN-Verbindung) - aber das GUI paßt auch in der 77201 dann noch nicht immer zu den erzeugten Einstellungen in der "vpn.cfg". Das wird bei der 7590 sicherlich nicht wirklich anders sein - diese Dateien teilen sich i.d.R. alle AVM-Versionen.

Schon die Frage, ob das zusammenpaßt, wenn man die "ipsecbrX"-Möglichkeit (also mit dem dedizierten Anschluß) wählt und parallel dazu noch das "Nur bestimmte Geräte nutzen die VPN-Verbindung" auswählen darf (wo dann auch noch die Geräte aus dem "normalen LAN" zur Auswahl angezeigt werden), müßte man vermutlich verneinen und das als weitere "offene Baustelle" interpretieren - der Versuch, beides parallel zu nutzen, führt bei mir dann auch prompt zu einem Fehler beim Speicherversuch.

Aber auch für diese Optionen (wenn man sie denn sicher implementiert kriegt und das nicht nur anhand der IP-Adresse festmachen will, die sich ein Client ja auch selbst statisch zuweisen könnte) braucht(e) es vermutlich eine komplette Überarbeitung des "Unterbaus" und den hat man mit dem "vpnd" ja ohnehin schon in der 07.19 gestartet.

Nur ist das eben alles "noch nicht fertig" und so teile ich den Optimismus einiger, daß die Release-Termine immer näherrücken würden, auch nur in kalendarischer Hinsicht (weil die Zeit vergeht) und nicht basierend auf dem derzeit sichtbaren Stand der Firmware.

Insofern hilft Deine Bereitschaft, die Protokolle mit AVM zu teilen, sicherlich ... zumindest macht sie auch darauf aufmerksam, wo es noch (weiteren) Klärungsbedarf gibt, denn die Widersprüche im GUI sind den Leuten bei AVM hoffentlich auch nicht verborgen geblieben ... aber solche Berichte wie den Deinen, daß spezielle Konstellationen dann gar nicht mehr funktionieren in der 07.19, las man bisher (zumindest hier im IPPF) auch nur selten.

 

[Andreas1969]

Heute kam die doch sehr ernüchternde Antwort von AVM

Ihre Daten habe ich gern zur Prüfung intern weitergeleitet. Sofern sich aus der Analyse Ihrer Daten seitens des FRITZ!OS Optimierungsansatz ergibt, so erfolgt hierzu eine Lösung in einem der kommenden Updates. Daher die Bitte, Ihre FRITZ!Box stets aktuell zu halten. Gern melde ich mich bei Ihnen nochmal, sofern sich bei der Untersuchung Ihrer Daten neue Fragen ergeben.

Das ist vom Wortlaut genau die selbe Antwort, die ich in 2016 erhalten hatte, als ich einen anderen VPN Bug an AVM gemeldet hatte.
Danach hatte ich nichts mehr von AVM gehört.
Der damals gemeldete Bug wurde dann tatsächlich "in einem der kommenden Updates" 3 Jahre! später im OS7.12 behoben.

Aber vielleicht kommt ja dieses mal doch noch eine weitere Antwort

Edit: Jetzt kam eine weitere Mail

wir untersuchen nun das Problem. Die Option auf der Seite ist nicht notwendig. Bitte deaktiviert lassen, da alle Anfragen des VPN-LAN-Ports und daran hängende Clients auch ohne Aktivieren dieser Option in den VPN-Tunnel geroutet werden. Lassen Sie bitte diese Option vorerst deaktiviert. Wir prüfen hier eine Änderung und Optimierung im FRITZ!OS. Freundliche Grüße aus Berlin

Anscheinend wird es jetzt doch was, sieht zumindest vielversprechend aus

 

[Andreas1969]

Heute gab es eine neue Labor, unter anderem folgende Änderung/Verbesserung:

Behoben - Unter Umständen wurden keine Daten über VPN-Verbindung übertragen

Ob das wohl tatsächlich schon behoben wurde?

 

[Andreas1969]

Leider mit der neuen Labor noch keine Änderung. Der Bug besteht weiterhin.
Es werden weiterhin nur lokale Anfragen durch den Tunnel geroutet, also nur zwischen 192.168.2.0 und 192.168.3.0

 

[PeterPawn]

Ich vermute mal, meinen Vorschlag mit der "accesslist" für "permit ip 192.168.3.0 255.255.255.0 any" hast Du nicht probiert? Oder gab das auch keine Änderung? Daß es anders laufen soll (wie es Dir der AVM-Support geschrieben hat), ist schon klar ... mir ging/geht es hier um die Frage, ob es einen Workaround (beim derzeitigen Stand) gibt.

 

[Andreas1969]

Ich vermute mal, meinen Vorschlag mit der "accesslist" für "permit ip 192.168.3.0 255.255.255.0 any" hast Du nicht probiert?

Nein, das hatte ich noch nicht probiert, mache ich beim nächsten mal vor Ort.