[Problem] VPN Tunnel zwischen 2x 7490 bricht unter Volllast ständig zusammen - wenig Last OK

[debeggerheinz]

Hallo,

ich verbinde mittels zweier 7490 Fritzboxen zwei Netzwerke miteinander. Funktioniert soweit auch.

Ein Standort hat allerdings eine problematische Leitung, deren Abbrüche, resyncs und dreistellige CRC Fehlerzahlen pro Minute ich erst durch Heraufsetzen der Störsicherheit in den Griff bekommen habe (1 Punkt bei allen Optionen im Downstream nach links -> sync von 14 mbit runter auf 7). Damit kann ich leben und das ist soweit stabil. Standort ist ein kleines Büro in einem Gründerzentrum, ich vermute daher massives Gegensprechen durch etliche andere DSL Anschlüsse im Haus innerhalb der Hausverkabelung.

An beiden Standorten stehen je ein Synology NAS System, die sich übers VPN replizieren sollen.

Riesen Problem ist jetzt, schalte ich die Replikation ein, geht die Upstream Auslastung des "problematischen" Standortes logischerweise auf Anschlag und der VPN Tunnel wird nach ein paar Sekunden getrennt. Danach reconnect. Das passiert bis zu 3x pro Minute. Für mein Datensicherungs- und Replikationszenario ist das ganz schlecht.

Gleiches Verhalten übrigens auch, wenn Traffic zwischen 2 anderen Geräten (2 PCs oder Druckjob übers VPN) den Upstream über VPN auslastet.

DSL Sync und Internetverbindung stehen immer. CRC Fehler wie gesagt 0. CPU Auslastung beider Boxen max 68%.

Fehlermeldung in der Box der "sendenden" Seite: ... VPN Verbindung wurde getrennt. Ursache: 3 IKE server. Auf der "empfangenden" Seite: "VPN Verbindung wurde getrennt. Ursache: 4 Decapsulation error".

Die Zugrundeliegenden Tarife beider Internetverbindungen sind 1&1 Doppelflats 16000 und hängen per ADSL2+ am Mediaways Backbone. DSLAM Broadcom 147.158 B5004244434D 7630392E 00. Selber Ort, unterschiedliche Ortsteile, aber womöglich sogar die gleiche Vermittlungsstelle (Kleinstadt). Beide Boxen haben FritzOS 6.20 drauf und DSL-Version 1.100.5.9.

VDSL oder Kabel sind leider nicht erhältlich am einen Standort, also bitte keine Diskussion dahingehend.

Hat jemand irgendeinen Tip?

Notfalls und falls es keine Lösung fürs VPN gibt, müsste ich die Synologies direkt ins Internet weiterleiten und über https synchronisieren lassen, das möchte ich aus Sicherheitsgründen aber eigentlich nicht.

Gruß

 

[Telefonmännchen]

Ich betreue ein ähnliche Szenario an einem anderen Standort und habe dort mit einer 7272 und einer 7170 keine derartigen Probleme. Allerdings sind die zugrundeliegenden Anschlüsse auch recht gemütlich (2,5 bzw. 3,5 MBit/s) dürften aber die deutlich leistungsschwächeren FritzBoxen aber auch ordentlich belasten. Dort wird täglich ein inkrementelles Backup der geänderten Daten, zum Wochenende ein komplettes Datenbackup gefahren und zum Monatsende die komplette Windows-Partition als Image gesichert. Allerdings ist das vom Datenvolumen überschaubar (die tägliche Sicherung liegt zwischen 30 und 50 MB). Aber bei dem Komplettbackup laufen 30-40 GB über diese Verbindung. Das braucht natürlich seine Zeit ist aber stabil. Ein grundsätzliches Problem würde ich ausschließen, allerdings lasten solche Verbindungen an schnellen Leitungen die Box schon etwas aus. Wobei die 7490 ausreichend Reserven besitzen sollte. Hmmm....

Als Alternative würde ich aber nicht auf den Sync per HTTPS zurückgreifen, sondern der implementierte VPN-Lösung auf OpenVPN-Basis den Vorzug geben. Hierbei sind auch nur jeweils eine einzige Portfreigabe auf jeder Seite notwendig. Die VPN-Last würde dann auf den Synos selbst anfallen. Testweise hatte ich das schon mal ein paar Tage in Betrieb, habe aber aus Kompatibilitätsgründen der AVM-Lösung den Vorzug gegeben, weil ich zu Wartungszwecken auch andere FritzBoxen an die Standorte anbinden wollte (insgesamt vier FritzBoxen und vier Roadwarrior).

Gruß Telefonmännchen

 

[Affenjunges]

Hallo,

ich bin über Google auf diesen Thread aufmerksam geworden und kann in soweit sagen, dass man die Leitungsqualität fast ausschließen kann.
Habe ein absolut identisches Problem zwischen einer FritzBox 7390 (DSL16k) und FritzBox 7490(VDSL50), gegengetestet mit einer 3370 zu einer 6360 Cable, immer und immer wieder Decapsulation Error bzw. IKE Server. Mit jeder Firmware ist das schlimmer geworden, war es früher vielleicht 1x in der Woche, ist es heutzutage mit der 6.20er minütlich, besonders wenn die Synologys richtig Daten schaufeln. Aber auch komplett ohne Last wird dauernd die Verbindung getrennt. Habe das Problem auch schon dem AVM-Support mitgeteilt und Logs hin und hergeschickt, aber so richtig diagnostizieren konnten sie es nicht, wird halt doch immer bisschen auf die Leitung geschoben. Aber die ist es nicht, 3 unabhängige DSL-Leitungen und ein UnityMedia-Anschluss könen nicht alle schlechte Verbindungswerte haben, das ist ganz offensichtlich ein Firmware-Fehler, der durch die Bank weg alle aktuellen FritzBoxen betrifft.

 

[Bullson]

Mir gehts genauso. Auffällig scheint mir zweierlei:
1) ich verbinde ebenfalls zwischen 1und1 16Mbit (7390) und Unitymedia 200Mbit (7390)
2) Bei mir kommt der Fehler (Decapsulation 4) immer genau nach 12 Minuten und dann wird sich innert 5 Sekunden neu korrekt verbunden.

Das Problem kam bei mir erst auf als ich den Unitymedia von 100 auf 200Mbit upgegradet habe. Das Modem ist jedoch gleich geblieben.

Das muss doch einzugrenzen woran das liegt?

 

[zimbodan]

Hallo,

wir betreiben eine ähnliche Konfiguration - Hauptgeschäft, zwei Filialen und Außenlager. Im Hauptgeschäft wird die Warenwirtschaft betrieben, die einmal wöchentlich ein kompletten Backup 160GB zu einer Filiale schickt (rsync). Unter normalen Umständen laufen die Verbindungen einwandfrei. Vom Außenlager werden die Signale der Überwachungskameras so übertragen, das der Upstream (600kB) permanent (24/7) komplett ausgelastet ist.

Sobald der Backup anspringt läuft er ca. 16 Stunden gut, danach treten die Fehler auf der VPN Strecke auf (Senden 3 IKE Server, Empfangen 4 Decapsulation Error). Irgendwann gibt dann der rsync auf :-(
(Senden AVM 3370 an DTAG VDSL 50, Empfangen AVM 7360 an M-Net 100)

Nach etwas Probieren (AVM Support ist wirklich für die Füsse!) habe ich festgestellt, dass ein simpler Neustart der beiden AVMs das ganze wieder stabilisiert - für die nächsten 16 Stunden. Ich bin jetzt zwar nicht der Fritz IOS Experte - aber nach meiner bescheidenen Meinung hat die Fritz.Box da ein Überlauf-Problem oder etwas Vergleichbares, das bei großen Datenvolumina auftaucht.

Da ich keine Lust habe mich weiter mit dem AVM Support zu streiten (Blinde die über den Sonnenuntergang diskutieren) habe ich ein einfaches Skript geschrieben, dass den Backup in 12 Stunden Tranchen zerteilt und dazwischen die Fritz.Boxen durchstartet. Seitdem läuft es mit nur noch sporadischen Fahren, die rsync verkraftet. Keine schöne Lösung aber ein funktionierender Workaround für uns.

Vielleicht hilft es ja jemanden ;-)

 

[Bullson]

Schau mal welche Firmware du drauf hast.
Wie ich hier schon schrieb:
http://www.ip-phone-forum.de/showthread.php?t=272915&p=2059151&viewfull=1#post2059151
Liegt es bei uns zu 100% an der 6.2 FW mit der älteren läuft alles sofort wieder wochenlang ohne Fehler. Sonst immer alle Nase lang 3 IKE Server

 

[TomDue62]

Grüsse aus der Schweiz!
Ich habe genau dasselbe Problem: 1 x 7490 an VDSL 100/20 (sync mit 37/10) und 1 x 7390 an VDSL 40/10 (sync mit 11/2). Ich bekommen dieselben IKE Fehler: Ursache 4 Decapsulation Error bei der 7390 und Ursache 3 IKE Server bei der 7490.
Auch ich synchronisiere 2 Synology-NAS via RSYNC von der 7490-Seite auf die 7390-Seite. Früher kein Problem, auch wenn der Transfer Tage gedauert hat. Jetzt mit Firmware 06.30 (aber auch schon vorher mit 06.2x) nur noch Probleme. Mal im Sekunden-Bereich, wobei rsync sich fangen kann, mal bis zu 1 Stunde, wobei rsync abbricht. Danach ist es wieder stabil, bei unbelasteter Leitung. Nur bei Last tritt dies auf.
AVM wollte, dass ich die 7490 komplett neu und von Hand einrichte, weil ich früher mal Telnet aktiviert habe. Sonst helfen sie nicht! Ist mir aber zu aufwändig. Zudem hat mein Provider die 7390 geliefert und die automatische Konfiguration ist dort (aktuell bei beiden Boxen) aktiviert. Somit weiss nicht nicht genau, was der Provider da noch reinwuselt.
Das mit dem zeitgesteuerten Reboot wäre als Übergangslösung interessant, falls es läuft. Wie geht das? Kann man das Script irgendwo runterladen? Und geht es auch mit 06.30? (kein Telnet mehr).

 

[HabNeFritzbox]

Man darf VPN der FB nicht wirklich voll nutzen, legt restliche Internet lahm, Aussetzer bei Telefonie ect.

Wenn ihr nen Syno habt, nutzt da VPN und macht in FB ne Route zum Syno. Das läuft dann gut, da dann auch FB QoS anwendet und nicht Rest ignoriert außerhalb vom VPN.

 

[Bullson]

Wie ich weiter vorne schrieb lag es IMMER nur an der Firmware. Noch immer betreibe ich das System so. Ohne einen einzigen IKE oder sonstigen Fehler. Ausser eben wenn die DSL Box die tägliche Zwangstrennung durchführt.
Sobald ich eine neuere fw drauf tue sind die Fehler sofort wieder da.
Soweit ich weiß gibt es für die 74er Boxen keine alte FW oder? Ich hab zumindest aus diesem Grund noch die 73er.
Find ich traurig von AVM dass die das angeblich nicht wissen / hinkriegen / ändern....

Probiers aus. Ich hab 6.03 und alles läuft perfekt

 

[grauGolz]

Leute, besorgt euch doch ein solides VPN Gateway mit OpenVPN und werdet glücklich. Hardware gibt es doch genügend. Software auch.

 

[splenditnet]

Hallo grauGolz,
OpenVPN funktioniert problemlos als LAN2LAN-Lösung auch auf FritzBox im BridgeMode (tap-device)
siehe http://www.wehavemorefun.de/fritzbox/OpenVPN

einfach openvpn-Binary mittels Freetz erstellen und mit modfs ins squashfs der Fritzbox einpflegen.

Gruß
Splenditnet

 

[grauGolz]

Den Aufwand nach Bugs in OpenSSL (OpenVPN nutzt OpenSSL) jedesmal die gestopfte Version reinzufreetzen tut man sich doch nur ungern an.

Man muß auch auf die Leute von "freetz" hoffen in Bezug auf die Pflege des Projektes.

Angeblich wird "stable" gar nicht mehr gewartet.

Fazit:

OpenVPN mit FB XYZ ist für mich kein Thema.

 

[PeterPawn]

@splenditnet:
Don't feed him ...

 

[grauGolz]

OpenSSL und "freetz".

"freetz" sagt:

Das Verzeichnis branches steht für eventuelle Entwicklungszweige. Hier werden die stabilen Versionen weiter gepflegt. Aha, gepflegt ist gut.
Faktisch ist "stable" nicht benutzbar weil dort OpenSSL (0.9.8y,1.0.1g) löchrig ist wie ein Schweizer Käse.

OpenSSL sagt:

Note: The latest stable version is the 1.0.2 series of releases. This is also our Long Term Support (LTS) version (support will be provided until 31st December 2019).
The 1.0.1 version is currently only receiving security bug fixes and all support will be discontinued for this version on 31st December 2016.
Our newest version is 1.1.0 which is currently in alpha testing and should not be used for production purposes at this time.
The 0.9.8 and 1.0.0 versions are now out of support and should not be used.

 

[grauGolz]

OpenSSL sagt:

https://mta.openssl.org/pipermail/openssl-announce/2016-February/000063.html

Es darf gefreetzt werden.

 

[grauGolz]

Möchte ich wirklich wissen wie viele löchrige Boxen im Land werkeln? Nein.