Fritzbox 7490 <-> 7390 LAN-LAN-Kopplung (VPN IPsec) treibt mich in den Wahnsinn!

[hachti]

Hallo allerseits,

ich habe gerade erhebliche Probleme damit, eine Fritzbox 7490, die ich letzte Woche in Marokko hinterlassen habe, per LAN-LAN-Kopplung mit meiner FB 7390 hier in Hannover zu koppeln.
Natürlich habe ich Google, das Forum hier und nicht zuletzt mein bescheidenes Informatikerfachwissen konsultiert, bevor ich nun diesen Beitrag schreibe.

Mein Problem ähnelt (!) dem hier bereits diskutierten:
http://www.ip-phone-forum.de/showthread.php?t=259543

Lustigerweise wurde dort auch keine Lösung gefunden, es hat plötzlich funktioniert. Wie bei mir. Und jetzt ist es wieder vorbei. Aber ich fange mal von vorne an zu erklären:

In Deutschland habe ich einen VDSL 50-Anschluß und eine FB7390 mit aktueller fw 623 laufen, wahlweise gerade auch mit der Laborversion ausprobiert, ändert nix.
In Marokko habe ich eine FB 7490 internationale Ausgabe auf Annex A an einem IAM DSL-Anschluß 12Mbit/1Mbit laufen. Die hat die neueste Firmware.

Als Dyndns nutze ich eine selbstgestrickte Lösung, die direkt eine Zone auf meinem eigenen Nameserver updatet. TTL ist 60, das Skript beendet sich extra nicht, bevor der Server auch die richtige Antwort gibt.
Trotzdem sagen beide Boxen, daß die DNS-Auflösung nach der Aktualisierung nicht funktioniert hätte. Domainnamen sind 100% korrekt angegeben. Bisher war mir die Fehlermeldung egal, da es trotzdem ausnahmslos korrekt funktioniert.
Ich betreibe meinen eigenen Dyndns-Dienst seit über 10 Jahren ohne Ausfälle. Also bitte nicht an dieser Stelle auf tiefstem Niveau auf mir herumhacken. Da man unhöfliche Caches (die die niedrige TTL ignorieren) bei einigen Providern
zu befürchten hat, sind meine beiden Fritzboxen gehalten, meinen eigenen DNS zu benutzen. Ich beschreibe das hier nur so ausführlich, weil es ja eventuell einen Zusammenhang mit meinem VPN-Problem gibt, den ich bisher nicht verstanden habe. Für Infos, was die Boxen dazu bringt, zu meckern, bin ich nebenbei auch dankbar. Erwartet die FB vielleicht mehr als nur einen A-Record? Oder muß ich bei meinem SOA-Record irgendetwas Esoterisches beachten, das mir nicht klar
ist?

Ich kann mit meinem Ipad per IPsec in beide Boxen eine VPN-Verbindung aufmachen, da gab es nie Probleme. Ich kann meine marokkanische Box außerdem stets von außen per https erreichen, sie ist also nicht am anderen Ende der Welt
"verloren".

Letzte Woche saß ich also in Marokko und habe versucht, die LAN-LAN-Kopplung in Gang zu bringen. Alles, was ich gesehen habe, war "wird aufgebaut" oder "nicht aufgebaut" sowie der beliebte IKE 0x2027 timeout-Fehler. Irgendwann
war es spät und ich habe aufgegeben. Gestern Abend nun schaue ich hier in Hannover in meine FB und sehe: Verbindung hergestellt! Alles funzt, ich konnte hin und her und her und hin. Die irrsten Kombinationen waren kein Problem (z.B. mit dem Ipad nach Marokko tunneln, dann über den Tunnel auf meinen Fotokopierer in Hannover zugreifen), ich war glücklich. Ohne etwas angefaßt zu haben.

Heute sieht es wieder anders aus: IKE 0x2027-Fehler, nix passiert. Beide Boxen glücklich, zufrieden und erreichbar. Mir fällt nun nichts mehr ein. Was ist da los????
Es wäre für mich sehr vorteilhaft, diese Kopplung stabil hinzubekommen. Ist es vielleicht ein Problem mit der 7390? Oder der aktuellen Firmware? Ich hätte an anderer Stelle noch eine 7490, falls das hilft. Auf Verdacht will ich hier
aber nicht alles umstellen, denn das bedeutet einigen Aufwand, da mein Betriebs- und Hausnetz ein wenig verwegen ist.

BTW: Weder in Hannover noch in Marokko gibt es irgendwelche IPv6-Verwicklungen, ist alles IPv4 mit echten IP-Adressen. Geprüft, bestätigt, geprüft, erprobt -> keine Diskussion wert.

Und jetzt hoffe ich, daß jemand etwas zu schreiben hat, an das ich nicht gedacht habe, oder das so absurd ist, daß man nicht drauf kommt. Etwas, das hilft
Vielen Dank im Voraus!

Grüße aus Hannover

Philipp

 

[eisbaerin]

Dein Hauptproblem ist: Es gibt keine FB3790!

Und heute ist noch kein 1. April!

Und mit einer nicht existierenden FB kann man natürlich auch kein VPN machen

 

[thtomate12]

Hast du mal die VPN-Konfig mit den direkten IPs probiert? Dann ist der DynDNS schon mal nicht zu beachten

 

[hachti]

Nein? Wieso soll es die nicht geben? Meine behauptet jedenfalls, eine zu sein.

 

[hachti]

Nein, habe ich noch nicht ausprobiert, da ich den Eindruck hatte, daß die Box jedesmal, wenn man etwas an einer VPN-Verbindung ändert, einen Reconnect macht. Aber probieren kann ich es.
Im Moment (seit 15:01) ist meine Box am anderen Ende nicht mehr sichtbar :-(
Etwas Hoffnung gibt mir, daß die Kundenlogin-Seite von Maroc Telecom auch irgendwie gerade nicht geht... Aber sobald ich meine Box wiedersehe, probiere ich es zumindest nochmal mit den konkreten IPs.

 

[hachti]

Also, Maroc Telecom hat sich dann doch irgendwie wieder gerührt, kann wieder mit der Box sprechen. IP direkt eintragen funktioniert nicht, da sich beide Boxen jeweils wenn man auf Speichern drückt in der VPN-Einstellung einmal reconnecten. Also
ist die Info immer sofort falsch :-(

 

[eisbaerin]

Nein? Wieso soll es die nicht geben? Meine behauptet jedenfalls, eine zu sein.
Anhang anzeigen 81042

Dann bist du ja noch blinder als ich auf beiden Ohren :lach:
Schau dir das Bild noch 3 mal an, (1 mal genügt ja scheinbar nicht)

 

[hachti]

Jaja, Eisbärin - ich hab's inzwischen kapiert
7390, 7490, 3790, was soll's - Ich hätte vielleicht schreiben sollen "AVM's dickste Box und eine Nummer kleiner" ;-)

 

[eisbaerin]

ich hab's inzwischen kapiert

Jaja, bei dem einen geht es halt schneller ... (der hätte es in #2 schon begriffen)
Dann korrigiere das bitte in #1 3 mal.

 

[hachti]

Dann korrigiere das bitte in #1 3 mal.

Jetzt hast Du nicht aufgepaßt - das war schon korrigiert. Und in der Überschrift kann ich es nicht korrigieren.

Und nebenbei ist mein schöner Thread jetzt schon kaputt dank dieser Haarspalterei - vielen Dank!

Es ging ursprünglich darum, daß ich meine Fritzboxen nicht zum miteinander sprechen bringen kann. Und nicht um einen lausigen Zahlendreher!

 

[thtomate12]

Und in der Überschrift kann ich es nicht korrigieren.

Doch 1. Beitrag "earbeiten", "Erweitert","Titel"

 

[PeterPawn]

@hachti:
Ich würde Dir vorschlagen, den Aufbau der VPN-Verbindung nur von einer Seite aus zu erlauben. Dazu muß nur in der "passiven" Box der "remotehostname"-Eintrag in der VPN-Konfiguration gelöscht werden.

Es gibt (m.W.) in dem Punkt, daß das AVM-VPN manchmal unter Kollisionen leidet, wenn der Verbindungsaufbau von beiden Seiten gleichzeitig erfolgt, einen Konsens hier im Forum.

Diese Kollisionen führen dann u.a. zu dem von Dir beschriebenen Phänomen, daß aus einen unerklärlichen Grund die Verbindung plötzlich doch aufgebaut werden kann. Das ist i.d.R. dann darauf zurückzuführen, daß die Verbindungsversuche beider Seiten so weit auseinander liegen, daß sie sich nicht mehr überlappen.

Mein Vorschlag funktioniert natürlich dann nicht, wenn Du die Verbindung tatsächlich "on demand" aufbauen willst ... den Verbindungsaufbau durch die "aktive" Box - auch ohne lokalen Verkehr, der zur "anderen Seite" geleitet werden müßte - kann man durch einen Eintrag "keepalive_ip = Adresse im Remote-LAN;" "erzwingen".

EDIT: Ansonsten wäre der Inhalt der /var/tmp/ike.log auf beiden Boxen hilfreich bei der Diagnose des Problems.

 

[mannebk]

Salü zusammen,

da hier nix mehr vom Themenersteller steht, geh ich davon aus, das der Hinweis von PeterPawn die Probleme erfolgreich gelöst hat und damit immer noch gültig ist.

Ich leide nämlich in unerklärlichen Abständen auch an solchen "VPN-Ausfällen" und such mir seit Monaten einen Wolf nach einer Lösung und hab die vitalen Systeme schon aus der LAN-Lan kopplung raus genommen und per openVPN direkt an einem 2. VPN Server angebunden. Nun heute hat entweder google was anderes angezeigt oder ich hab anders gesucht, what ever, ich hab diesen Beitrag gefunden *freu* und damit hier die erste Aussage zu den IPsec Verbindungsabbrüchen bei der Fritz Lan-Lan kopplung überhaupt gefunden. Danke dafür.

Interessant ist, das der AVM Support mir das nicht als Hinweis gab, sondern mein VPN Ticket als "das muss der Entwickler ansehen" geschlossen hat. Wobei es da auch primär um das core spanning des VPN Prozesses ging, was die FB offensichtlich bis heute nicht kann.

Meine eigene Situation ist wie folgt:
Seit gut 12 Monaten hab ich hier ein dauerhaft aktives VPN-Stern-Netzwerk stehen, das insbesondere bei SMB Verbindungen extrem langsam ist.
Es sind div. Boxen 7490er und 7390er, alle im Autoupdate-Modus, also immer mit current fw. Diese verbinden sich per IPsec lan-lan kopplung an die 7490 hinter der meine Server stehn.
Alle Boxen haben ein Routing für die Subnetze der anderen Boxen über die Hauptstelle.

Ich habe Wochenlang keinerlei Probleme mit dem VPN (war kürzlich beruflich in Indien und im Oman, hab also 4 Wochen nix angerührt und keiner meiner Mitarbeiter an den Standorten hatte sich beschwert das was nicht ginge (und auf Nachfrage kam, alles war tip top, ich solle wieder auf Dienstreise gehen weil, kaum bin ich wider im Land, bricht das VPN zusammen). Sprich Abbrüche im 10 Minuten-Takt mit anschließendem neuverbinden das mal zeitnah klappt, mal auch nicht.

Auch ich hab meinen eigenen dyns service laufen, gehe aber zusätlich noch über ma.cx (dyns.cx) als dienstleister.

Aktuell ist es so, das die entfernten boxen sich über ma.cx ne ddns adresse machen, während die Hauptbox über meinen eigenen ddns dienst erreichbar ist, die Idee dahinter war, das falls meiner ausfällt, die "clients" von der Hauptbox aus über ma.cx erreichbar wären, und falls ma.cx ausfällt, die Hauptbox über meinen ddns erreichbar ist.

Offensichtlich muss ich mich jedoch nun für das VPN für eine von beiden entscheiden.

Ich probier das jetzt auch einfach mal aus, das ich in der Hauptbox schlicht die ddns Adresse der Remoteboxen rausnehme und mal sehe wie sich dann die VPN Verbindung verhält.

Wenn hier von mir nix mehr kommt, dann wars erfolgreich.

Gruß
Manne

 

[Shirocco88]

Wobei es da auch primär um das core spanning des VPN Prozesses ging, was die FB offensichtlich bis heute nicht kann.

Bitte genauer beschreiben, was Du mit "core spanning" meinst;

Ansonsten wäre der Inhalt der /var/tmp/ike.log auf beiden Boxen hilfreich bei der Diagnose des Problems.

wie PeterPawn schreibt, sind diese Inputs (zu finden in Supportdaten Datei http://fritz.box/?lp=support) ergänzt um Ereignislog http://fritz.box/?lp=log) bei Diagnose des Problems hilfreich; diese Inputs der betroffenen beiden Fritzboxen kann ich in #13 nicht finden;

 

[mannebk]

Bitte genauer beschreiben, was Du mit "core spanning" meinst

Da hab ich mich wohl unklar ausgedrückt. Ich meinte die Multi-Core-Fähigkeit des IPsec Prozesses.

Die Übertragungskapazität einer VPN Verbindung von 7490 zu 7490 an 100/40 vdsl Anschlüssen der Telekom schöpfen mit NICHTEN die Leitungskapazität aus.

Be meinen Untersuchungen woran das liegt, und wie ich das beheben könnte, bin ich, in zusammenarbeit mit dem AVM Support, zu dem Ergebniss gekommen, das der VPN Prozess in der Fritzbox maximal 1 core zu 100% auslastet. Wieviel % der 100/40mbit Leitung das dann konkret waren, weiß ich nicht mehr. Ich meine mein 40mbit Upload war deutlich unter 25% ausgelastet was einem Upload von ca. 8mbit entspricht, was auf der downloadseite natürlich dann unter 10% sind. Dateiübertragung erfolgte auf die NAS der 7490 übers frontend, lokal draufkopiert über das gleiche Web Front End war es um den Faktor 2 schneller was bedeutet, der Speicher könnte mehr als das VPN hergibt. Ergo ist das VPN der Flaschenhals und das liegt scheins am Prozesshandling im core der idle in der gegend rumhängt, während der User auf den Datentransfer wartet.

Beim transfer von 7490 zu einer 7390 sind es übrigens nur 6mbit.

Überträgt man von einer 7490 gleichzeigit an eine 7390 und 7490 steigt der Durchsatz etwas. erreicht jedoch nicht die Summe der einzelen übertragungen. 6+8 müsste 14 ergeben, es werden jedoch nur ca. 11 mbit ausgehend erreicht.

Schlussfolgerung, der Flaschenhals ist eingehend die zur verfügungstehende CPU Leistung und bei 2 ausgehenden Transfers dann die ausgehende CPU leistung.

Da die FB gleichzeitig jedoch nur eine sehr begrenzte CPU last ausweist, lässt dies nur den Schluss zu, das der VPN prozess nicht berechtigt ist mehr zu verwenden oder auf einen core begrenzt wurde, möglicherweis um die Telefonie nicht "auszunocken" während einer VPN Übertragung mit hohem Bandbreitenbedarf. Oder es könnte sein, das das Multithreading das in IPsec schon recht lange implementiert ist, ich meine was mit 2006 oder so im Kopf zu haben, eben schlicht noch keinen eingang in die AVM Version gefunden hat. Möglicherweise unter dem SIP prioritäts Gesichtspunkt.

Und was die stabile IPsec Verbindung angeht. ich muss meine Aussage von vorhin wiederrufen. Ich hab immer noch die gleichen verbindungsabbrüche von der 7390 zur 7490. die andere getestete Verbindung 7490 zu 7490 ist bis dato stabil.

Und was das Log angeht, leider kann ich die Abbrüche nicht vorher sagen.... daher ist es mir bisher noch nicht gelungen ein vernünftiges log beider beteiligten FBs zu erstellen

### edit by stoney ###

ergänzung, ich hab das grad nochmal gemacht, die files hin und hergeschoben.

auch bei transfer über danhinter liegende hardware, also sprich die FB macht NUR das VPN, kommt zwischen 2 7490 nicht mehr wie 8mbit leitungsauslastung zustande auch wenn alle teilnehmer als "echtzeit" gerated sind.

Wohingegen die 2mbit ausgehende Leitung von einem meiner easybell 16/2 Anschlüsse von einer 7490 problemlos zu 100% vom VPN ausgelastet werden kann.

 

[Shirocco88]

ch meinte die Multi-Core-Fähigkeit des IPsec Prozesses.

üblicherweise ist ein UNIX-Process auf einen Core begrenzt;
auch ist bei Embedded-Systemen oft eine Thread : Process Beziehung von 1:1;
d.h. die genannten Fähigkeiten sind hier nicht gegeben.

Oder es könnte sein, das das Multithreading das in IPsec schon recht lange implementiert ist, ich meine was mit 2006 oder so im Kopf zu haben, eben schlicht noch keinen eingang in die AVM Version gefunden hat.

ich kenne kein Multi-Threading bei FB7490 mit Fritz!OS 06.8x.

 

[mannebk]

jups genau das meinte ich, danke für die korrekte therminologie.

 

[PeterPawn]

Bei IPSec-Verbindungen bringt aber Multithreading praktisch nichts ... die Pakete (innerhalb einer Verbindung) müssen immer schön in Reihenfolge verschlüsselt und anschließend mit HMAC gesichert werden, weil die verwendeten Block-Modi dafür sorgen, daß die "Ausgangslage" für jedes weitere Paket von seinem Vorgänger abhängt.

Wenn da noch irgendwo (De-)Kompression dabei ist, dann erfolgt die vor der Ver- und nach der Entschlüsselung - braucht aber ohnehin nur wenig Ressourcen im Vergleich zu einer sicheren Verschlüsselung mit AES-128 oder AES-256.

Was sich parallelisieren läßt (keine Ahnung, ob AVM das macht oder nicht), ist das Entschlüsseln des Payloads und das Prüfen des HMAC - sofern man bei HMAC-Problemen dann auch den Prozess des Entschlüsselns abbricht (der braucht i.d.R. auch länger als das Hashen) oder zumindest dessen Ergebnis 100% sicher verwirft.

Somit bringt das nur dann ggf. etwas, wenn man mehrere Threads unterstützt (auch das weiß ich nicht, ob es von AVM so umgesetzt wurde), wenn man auch wirklich mehrere Verbindungen bedienen will - wobei ich mir tatsächlich auch vorstellen kann, daß AVM da gar nicht erst (beim Ver- und Entschlüsseln selbst, nicht beim Key-Exchange) mit mehreren Threads arbeitet ... das sichert zumindest ab, daß anderen kritischen Prozessen (z.B. dem Timing für TDM beim DECT) genug Power zur Verfügung steht. Wobei das ja in einem Kernel-Thread erfolgt mit dem Ver- und Entschlüsseln (sieht man daran, daß die Zeit dafür dem "sirq"-Punkt zugeschlagen wird beim "top") - da müßte es dann also auch noch irgendeine Serialisierung geben, denn IPSec-Pakete müssen - sollten sie auf unterschiedlichen Wegen und in abweichender Reihenfolge eintreffen - auch wieder in die richtige Abfolge gebracht werden, sonst wird das nichts mit dem Entschlüsseln.

 

[mannebk]

@PeterPawn: danke für die Erklärung, so detailliert konnte mir das AMV nicht erklären, die sagten nur, das müsse sich die Entwicklung ansehen.... hab dann nie wieder was von denen gehört.

Naja, die remote sites die Hochgeschwindigkeits brauchen hab ich inzwischen über einen dedizierten VPN angebunden. Das ist halt mit Kosten verbunden, Anschaffung, Strom und Wartung. Daher gehe ich bei den remote sites die diese Kapazität nicht brauchen doch lieber den Weg über die ohnehin vorhandene FritzBox.

back on topic

es ist mit dem einseitgen Aufbau der VPN Verbindung sehr viel stabiler!

Seit der änderung hab ich quasi keine Verbindungsabbrüche mehr. Um das zu überwachen habe ich am FreePBX Telefonserver den Qualify Peer Intervall auf 5 Sekunden gesetzt, dadurch bekomme ich nun sofort mit wenn eine der remote sites fehlt. Was aber in der vergangenen Woche quasi nicht mehr vorgekommen ist.

Und da ich nun immer über den Eintrag in meinen eigenen DNS-Server verbinde, hab ich den FBs auch meinen eigenen DNS Server als primären WAN DNS mit TTL 30 gegeben, so steht die Verbindung nach der Zwangstrennung in sekundenschnelle wieder.

Dieser Tipp mit der einseitigen Aufbau-Syntax in Form das man schlicht an der anderen Seite die Remote-Adresse des VPN aus der config löscht ist also eine EXTREME verbesserung. Nur schade das AVM diesen Tipp nicht im Support offeriert, hätte mir viel stress und Ärger erspart.

Gruß Manne

 

[PeterPawn]

Schön ... der Box fehlt aber ohnehin so etwas wie die Möglichkeit, die einzelnen VPN-Verbindungen "in Textform" zu editieren oder einzelne davon so zu exportieren, daß man sie nach manuellen Anpassungen auch wieder importieren kann. Leider gibt es auch intern tatsächlich nur die in den jeweiligen Formularen angezeigten Eingabe- und Auswahlmöglichkeiten, denn das wird von AVM nicht Zug um Zug zusammengesetzt, sondern alles gemeinsam dem "ctlmgr" vorgesetzt und der organisiert dann das Erstellen einer neuen Konfiguration oder die Änderung einer bestehenden. Damit ist das praktisch nicht zu erweitern und man muß alles komplett neu implementieren, wenn man eigene Konfigurationsoptionen (wie eine explizite Aufteilung in "initiator" und "responder") ergänzen will.

Ansonsten mußt Du ja nur noch Dein Annex A-Problem aus der Signatur lösen ... auch dafür gibt es Vorschläge. Hast Du Dir mal einen davon vorgenommen und es getestet?