Wenn eine FTP Verbindung ohne VPN besteht, bricht diese nicht ab.
FTP nutzt TCP, IPSec (i.d.R. bzw. zumindest bei NAT-T) UDP als Transport-Protokoll.
Bei Stau
darf ein Internet-Router Pakete verwerfen, meist wird das UDP-Pakete als erstes treffen. Bei TCP-Paketen wird dann automatisch wiederholt, ansonsten muß das getunnelte Protokoll für Wiederholungen sorgen.
Fällt bei IPSec-Verbindungen ein KeepAlive-Paket - DPD (trotz "Paket" kein Kurierdienst, sondern "Dead Peer Detection") oder ISAKMP-KeepAlive - dem Stau zum Opfer, nimmt die sendende Seite (Alice) an, die Gegenseite (Bob) wäre "weg", da sie keine Antwort erhält. Dann baut Alice die Verbindung eben wieder auf, mit allen was dazu gehört.
Da Bob in diesem Falle aber gar nicht weiß, daß Alice eine neue Verbindung will (er hat ja keine Ahnung, daß ein KeepAlive von Alice ihn nicht erreicht hat) und seinerseits davon ausgeht, der Verkehr mit Alice wäre mit den bisher verwendeten Einstellungen verschlüsselt, wird er in diesem Falle als erstes mal einen Fehler in der Verschlüsselung diagnostizieren, denn die neue Verbindungsanfrage von Alice ist ja nicht richtig verschlüsselt. Deshalb sendet Alice auch eine INITIAL_CONTACT-Nachricht an Bob, die diesen dazu veranlaßt, die alte Verbindung komplett zu vergessen und sich auf eine neue Aushandlung einzustellen. Nach meiner Ansicht ist das der Auslöser für die "Ursache: 3 IKE Server"-Nachrichten im Eventlog, da ja Alice (indirekt) das Ende der vorhergehenden Verbindung fordert.
Die andere Alternative, warum eine IPSec-Verbindung geschlossen wird, ist der Ablauf der vereinbarten "Lebenszeit" (gemessen in Zeit oder mit dem aktuellen Schlüssel übertragenem Volumen) der Verschlüsselung, wobei dem Standard zufolge an dieser Stelle auch das Aushandeln eines neuen Schlüssels vollkommen ausreichend wäre. AVM hat hier aber imho wegen Problemen in der Android-Implementierung des IPSec-Stacks einiges verschlimmbessert und führt in vielen Fällen kein Rekeying durch, sondern beendet schlicht die komplette Verbindung, um sie hinterher sofort wieder neu aufzubauen (was ein nicht unerheblicher Overhead ist).
Wenn man jetzt mal Dein Log im zweiten Abschnitt ansieht, steht da folgendes (BTW: Es ist wenig sinnvoll, solche Protokolle zu vollkommen verschiedenen Zeitpunkten auszuwerten, wenn man verstehen will, was da (vermutlich) passiert ist, sollte man auch denselben Verbindungsab- und -aufbau betrachten):
05.11.2014 22:38:23 VPN-Verbindung zu 2222.ddns.net wurde erfolgreich hergestellt.
Erst einmal ein vollkommen normaler Verbindungsaufbau.
05.11.2014 23:36:53 VPN-Verbindung zu 2222.ddns.net wurde getrennt. Ursache: 3 IKE server
Die Gegenstelle hat nach einer knappen Stunde (die "lifetime" ist bei AVM-IKE 3600 Sekunden, wenn man es nicht umstellt) die Verbindung getrennt.
Das ist imho der oben erwähnte "Android"-Schutz, den man auch besser hätte umsetzen können, indem man ihn auf Android-Gegenstellen beschränkt - bei einer 7390 mit 06.03 und einer 6360 mit 06.05 hält eine IPSec-Verbindung fast "ewig" und dieser 1h-Quatsch ist glücklicherweise noch nicht enthalten:
Code:
14.11.14 06:32:59 VPN-Verbindung zu Bob wurde erfolgreich hergestellt.
14.11.14 06:32:58 VPN-Verbindung zu Bob wurde getrennt. Ursache: 3 IKE server
14.11.14 03:35:56 VPN-Verbindung zu Bob wurde erfolgreich hergestellt.
14.11.14 03:35:54 VPN-Verbindung zu Bob wurde getrennt. Ursache: 3 IKE server
13.11.14 03:37:14 VPN-Verbindung zu Bob wurde erfolgreich hergestellt.
13.11.14 03:37:12 VPN-Fehler: Bob, IKE-Error 0x203e
13.11.14 03:37:11 VPN-Verbindung zu Bob wurde getrennt. Ursache: 3 IKE server
12.11.14 03:38:08 VPN-Verbindung zu Bob wurde erfolgreich hergestellt.
12.11.14 03:38:07 VPN-Fehler: Bob, IKE-Error 0x203e
12.11.14 03:38:05 VPN-Verbindung zu Bob wurde getrennt. Ursache: 3 IKE server
11.11.14 03:39:19 VPN-Verbindung zu Bob wurde erfolgreich hergestellt.
11.11.14 03:39:18 VPN-Fehler: Bob, IKE-Error 0x203e
11.11.14 03:39:17 VPN-Verbindung zu Bob wurde getrennt. Ursache: 3 IKE server
10.11.14 03:40:26 VPN-Verbindung zu Bob wurde erfolgreich hergestellt.
10.11.14 03:40:25 VPN-Fehler: Bob, IKE-Error 0x203e
10.11.14 03:40:23 VPN-Verbindung zu Bob wurde getrennt. Ursache: 3 IKE server
09.11.14 03:41:43 VPN-Verbindung zu Bob wurde erfolgreich hergestellt.
In diesen 4 Tagen wurden über diese VPN-Verbindung knapp 80 GByte an Daten übertragen, da fand als jede Menge "Rekeying" statt, vollkommen ohne überflüssigen Neuaufbau im Stundenrhythmus. Der Neuaufbau mit Fehlercode 0x203e ist unumgänglich, da sich an dieser Stelle jeweils die IP-Adresse von Bob geändert hat (Zwangstrennung).
Aber zurück zu Deinem Protokoll ... irgendwann nach 23:36:53 hast Du einfach eine Zeile zuviel gelöscht, denn da wurde lt. Protokoll die Verbindung getrennt, die dann knapp eine Stunde später aber wieder Fehler verursachen soll ... da paßt etwas nicht zusammen. Nehmen wir mal an, da wurde dann anschließend die Verbindung wieder aufgebaut und Du hast das nur unterschlagen.
06.11.2014 00:34:24 VPN-Fehler: 2222.ddns.net, IKE-Error 0x1c
Jetzt geht etwas das Rätselraten los, denn dieser Fehler deutet eigentlich darauf hin, daß die falsche Gegenstelle angesprochen wurde. Wenn man sich die nächsten Fehler dann ansieht, würde ich vermuten, daß da bei 2222.ddns.net eine Zwangstrennung (oder der vorauseilende Gehorsam der entsprechenden Einstellung in der FRITZ!Box) einen Wechsel der IP-Adresse hervorgerufen haben. Das erklärt dann zumindest, warum auf die KeepAlive-Nachfragen
06.11.2014 00:34:59 VPN-Fehler: 2222.ddns.net, IKE-Error 0x2027
06.11.2014 00:36:05 VPN-Fehler: 2222.ddns.net, IKE-Error 0x2027
06.11.2014 00:36:09 VPN-Fehler: 2222.ddns.net, IKE-Error 0x203e
keine Antworten kommen (0x2027 ist "timeout") und damit dann die FRITZ!Box davon ausgeht, daß die Verbindung "tot" ist. Also wird sie wieder aufgebaut, dabei stellt sich dann aber heraus, daß die IP-Adresse nun eine andere ist (0x203e) und der Verbindungsaufbau (aggressive mode wg. dynamischer IP) muß komplett neu gestartet werden.
06.11.2014 00:36:13 VPN-Verbindung zu 2222.ddns.net wurde erfolgreich hergestellt.
Es dauerte nicht einmal 4 Sekunden, die VPN-Verbindung (nun mit der neuen Adresse) wieder aufzubauen.
Es tut mir leid, aus diesem Protokoll (das ist das mit den meisten Fehlernachrichten) läßt sich beim besten Willen kein
Sunwalker schrieb:
Jedoch haben wir aktuell sehr häufig Verbindungsabbrüche.
ableiten.
Einziges Problem ist das neue Verhalten der AVM-Firmware, die zur Umgehung des Android-Problems (das wohl nur dann auftritt, wenn das Android-Gerät von sich aus die Verbindung beendet) noch vor dem Ablauf der Lifetime des aktuellen Keys von sich aus die Verbindung schließt und dabei offenbar nicht in der Lage ist zu erkennen, daß das auf der anderen Seite gar kein Android ist, sondern ebenfalls eine FRITZ!Box. Daß dieses Verhalten neu (und imho vollkommen blödsinnig) ist, zeigt das Log der zwei "alten" Firmware-Versionen deutlich. Ob dieses merkwürdige Verhalten sich jetzt auf das ausführlichere Logging von IPSec-Ereignissen beschränkt, rätsele ich auch immer noch. Eine 7490 (06.20) zu genau derselben 7390 als Gegenstelle macht jedenfalls auch nicht jede Stunde die Verbindung (lt. Eventlog) neu auf, da erfolgt nach der Protokolldatei /var/tmp/ike.log auch ständig die Aushandlung neuer SAs, vollkommen ohne Log-Orgien auf der 7490. Auf der 7490 sieht der o.a. Adresswechsel der 7390 gestern morgen dann - nebenbei gesagt - so aus:
Code:
14.11.14 03:36:01 VPN-Verbindung zu Bob wurde erfolgreich hergestellt.
14.11.14 03:36:00 VPN-Verbindung zu Bob wurde getrennt. Ursache: 3 IKE server
Damit wage ich jetzt mal die These, daß da Bob vor der Zwangstrennung durch die Firmware ganz ordentlich die Verbindung zu beiden VPN-Gegenstellen (6360 ist Alice und 7490 ist Carol) beendet hat (Ursache 3 = Gegenstelle trennt Verbindung).
Wenn Du also wirklich solche häufigen Verbindungsabbrüche hast (nicht einmal den dritten Teil kann man richtig dafür als Beweis hernehmen, auch da hast Du mindestens eine Zeile unterschlagen zwischen
Code:
05.11.2014 17:42:04 VPN-Fehler: 3333.myftp.org, IKE-Error 0x2027
05.11.2014 17:41:25 VPN-Verbindung zu 3333.myftp.org wurde getrennt. Ursache: 3 IKE server
denn eine getrennte Verbindung wird keinen Timeout-Fehler verursachen), dann kann man das in den zitierten Protokollteilen jedenfalls nicht sehen.
Vermutlich reden im dritten Protokoll wohl zwei Seiten aneinander vorbei, wenn erst die Gegenseite trennt, dann auf der eigenen ein Timeout auftritt (mit der Folge der eigenen Trennung und des Neuaufbaus, s.o.) und dann wieder die Gegenseite trennt. Da scheinen dann einige KeepAlives nicht richtig anzukommen, ich würde auf eine happige Überlastung des Netzzugangs zu diesem Zeitpunkt tippen (ist aber nur geraten, die Protokolle geben eben - da sie nicht synchron sind - nur wenige Anhaltspunkte für Interpretationen).
. Nein war mein Fehler. Jetzt sind es 3 unterschiedliche. Wir haben eben alle im Laufe des letzten Jahres auf VDSL umgestellt und keiner wollte so nen Sp**dport. Zum einen wegen dem VPN, bei dem Besitzer der 7490 und mir auch weil der S0 Anschluss benötigt wird. Den hat das von Magenta angebotene Modell nicht.
