This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

VPN-Traffic friert Internetverbindung ein

ASG Virtual Appliance V7.505 auf ESX 4.1

Hallo,

ich habe seit einigen Tagen nach einem Standortwechsel (Umzug des Büro's incl. aller Hardware) folgende Problem:
Die Astaro (Virt. Appliance / ESX) baut die Internetverbindung korrekt auf - Internet / Mail funktionieren korrekt.
Nach etwa 2 Minuten sind auch die 4 VPN's zu ext. Standorten aufgebaut. Solange kein oder kaum Daten über die
VPN-Strecken laufen ist auch weiterhin alles OK. Beginnt einer der angebundenen Standorte jedoch in grösseren Mengen Daten zu senden 
(das sind Bildfolgen mit i.d.R. 50-100 Bildern mit ca. 1MB) beginnt der folgende Effekt:
Die Datenübertragung startet - nach einem Zeitraum, der zwischen 5 und 15 min schwankt, bricht die Verbindung ab.
Alle 4 VPN-Tunnel werden getrennt. Die Internetverbindung (T-DSL-Business) hat den Status verbunden, allerdings mit Traffic 0kbit in
beiden Richtungen.
Dieser Zustand bleibt erhalten bis ich die DSL-Schnittstelle über reconnect neu verbinde.
... bis zur nächsten Datenübertragung von den Aussenstellen ist dann alles wieder OK. Das sind im Tagesgeschäft allerdings max. 15 Minuten.

Ich habe DSL-Modems getauscht, VPN's gelöscht und neu eingerichtet, 2 Tage Langzeittest von der Telekom auf dem DSL'er machen lassen,
die VPN's einzeln ausser Betrieb gesetzt um den fehlerhaften zu finden, die Astaro 'werksresettet' und die funktionierende Konfig von vor
dem Umzug zurückgelesen ...
alles ohne Erfolg!

Es gab keine Hardwareänderung (außer neuen LevelOne-GBit-Switchen), T-DSL-Business ist samt Technik und Zugangsdaten mitgezogen ..., lediglich der der VM für ein zusätzliches Netz durchgeschaltete Netzwerkadapter, der ist jedoch noch offline.

Ich habe keine logische Erklärung dafür.
Hat jemand eine Idee?

VPN-Gegenstellen: 1x Lancom 1811, 1x Lancom 1611, 1x Lancom 7111, 1x Cisco Concentrator 6000er Serie

Gruß webrudi


This thread was automatically locked due to age.
  • Vielleicht eine MTU Fehlanpassung?

    MfG - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Ist auf 1492 eingestellt. Das sollte stimmen.
    Da ich kürzlich den merkwürdigen Effekt im Netzwerk hatte, den ich schlussendlich nicht verbindlich der Astaro oder dem ESX zuschreiben konnte bin ich gerade dabei die ASG auf echte Hardware umzuziehen. Mal schauen was dann passiert ...
     MfG
    mhlrudi
  • ...meines Wissens gibt die DTAG für T-DSL business mit fester IP eine MTU von 1456 vor.
  • Gut. Ich habe die MTU geändert auf 1456. Das Ergebnis bleibt das gleiche. Nach wenigen Minuten ist die Verbindug wieder tot, d.h. der Datendurchsatz ist auf Null. Verbindungsstatus in der Astaro ist OK! Dadurch wird die Verbindung auch nicht automatisch neu aufgebaut. Inzwischen sind auch erst einmal alle VPN's deaktiviert. ... die waren offensichtlich nicht - wie von mir angenommen - Ursache des Problems. Die Verbindung schmiert auch völlig ohne Last ab.
    Allerdings habe ich diesen Effekt gehabt beim ping -f -l ***x
    MTU Einstellung Astaro:
    1.) 1492
    ping -f -l 1464 t-online.de läuft durch am Client
    2.) 1456
    ping -f -l 1428 t-online.de läuft durch am Client - darüber geht nichts, damit könnte ich ja leben.
    Nachdem die Internetverbindung wieder mal neu getartet werden musste lieferte mir ein erneutes ping -f -l 1428 t-online.de am gleichen PC die bekannte Meldung 'das Paket müsste fragmentiert werden ...'
    Erfolgreich lief jetzt der Ping erst bei 1398 durch! Rechnerneustart & Test an einem weiteren Rechner brachten das gleiche Ergebnis ... bis zum nächsten Neustart der Internetverbindung: Überraschung - jetzt läuft der ping wieder mit 1428 ...
    irgendwie habe ich das Gefühl das ich ein Phantom jage. 

    MfG mhlrudi
  • so wie es aussieht, haben wir in letzter zeit die selben symptome (dsl-ausfall bei übertragung größerer datenmengen via vpn).

    wir haben auf unserer büro-astaro 3 dsl-anschlüsse im multipath konfiguriert und darüber läuft ein vpn zu einer astaro in einer anderen lokation. hinter der dortigen astaro wiederum laufen auf einigen servern cronjobs, die regelmässig grosse datenmengen ins büro kopieren sollen. der cronjob bricht meistens wegen timeouts ab. auch wenn man es von hand startet, läuft es nicht immer durch.
    das ganze ist erst so, seit wir den job via vpn laufen lassen. zuvor lief er am vpn vorbei und da gab es eigentlich nie probleme.

    was wir beobachtet haben ist, dass in dem zeitraum dann auch kein internet-zugriff im büro möglich ist. es sieht also so aus, als ob die dsl-anschlüsse nicht mehr funktionieren.

    ich werde das auch nochmal genauer untersuchen und ggf. einen case beim support aufmachen. vlt gibt es ja noch weitere, die das problem haben, dann sieht man möglicherweise, dass es kein einzelfall ist.
  • Bedenkt bitte, das VPN auch Headerinformationen beinhaltet und aufgrund eines falsches MTU Wertes (dieser sollte tiefer sein, als der am Interface eingestellte) dann die Verbindungen ins leere laufen.
    Wir haben mit T-DSL Business am Interface einen MTU von: 1492 und bei den IPSEC Einstellungen (Site-to-Site-VPN -> IPSec -> Erweitert) einen MTU Wert von 1420, sowie "Pfad-MTU-Erkennung zulassen" eingeschaltet. Dieser Wert sollte 1. bei beiden Gegenstellen gleich sein / bzw. sich immer nach dem schwächsten Glied in der Kette richten.

    Grüße

    Schroeder
  • Bedenkt bitte, das VPN auch Headerinformationen beinhaltet und aufgrund eines falsches MTU Wertes (dieser sollte tiefer sein, als der am Interface eingestellte) dann die Verbindungen ins leere laufen.
    Wir haben mit T-DSL Business am Interface einen MTU von: 1492 und bei den IPSEC Einstellungen (Site-to-Site-VPN -> IPSec -> Erweitert) einen MTU Wert von 1420, sowie "Pfad-MTU-Erkennung zulassen" eingeschaltet. Dieser Wert sollte 1. bei beiden Gegenstellen gleich sein / bzw. sich immer nach dem schwächsten Glied in der Kette richten.


    wir haben heute nachmittag noch etwas getestet und sind seither noch mehr verwirrt.

    die mtu des vpn war in der tat auf den beiden seiten verschieden (1376 vs 1420), aber auch nachdem ich beide auf 1420 gesetzt hatte, sind mir die dsl-anschlüsse um die ohren geflogen. immer derjenige, über den das vpn lief (ich habe alle durchprobiert), fiel auf einmal aus. mtu path discovery war auf beiden seiten aktiviert. der einzige unterschied zu den angaben in deinem post liegt bei uns darin, dass die mtu der dsl-interfaces jeweils auf 1456 und nicht 1492. soweit ich mich erinnere, haben wir 1456 eingestellt, weil es im t-dsl business kundencenter empfohlen wurde.

    wir sind zu dem ergebnis gekommen, dass es nicht an der astaro liegt. denn laut den logs der vorgeschalteten dsl-modems (alles fritzboxen, verschiedene modelle) fand jeweils eine neu-synchronisierung statt. wieso sollte das passieren, wenn nur die astaro ein problem hätte? unsere fritzboxen können es eigentlich auch nicht sein, denn es wäre schon sehr merkwürdig, wenn alle dasselbe problem hätten. ein hitzeproblem bei uns können wir auch ausschliessen, denn alles auf unserer seite steht in einem klimatisierten raum.

    jemand noch eine idee?

    grüße
    -norman

  • jemand noch eine idee?


    Schon mal versucht in der Fritzbox unter /Internet/DSL-Informationen/Einstellungen/ den Wert von Max. Performance in Richtung Max. Stabilität zu verschieben ?

    Btw. So wie ich das verstanden habe, habt Ihr in Eurem Büro mehrere DSL Leitungen, oder ? Wenn ja, bricht die Leitung auch zusammen wenn Ihr nur eine verwendet ?
  • ich hatte mal das selbe problem mit T-DSL business und Netscreen VPN.


    hat am ende am MTU gelegen. 1456 ist richtig. hast du das auch an der fritzbox eingerichtet?

    wenn ich es richtig in erinnerung habe... am modem/router 1456 eingestellt und am vpn gateway wieder die 1492.