[Problem] VPN Verbindung zw. FritzBox 7490 und 7390 bricht ab

Nontschew

Neuer User
Mitglied seit
10 Feb 2017
Beiträge
14
Punkte für Reaktionen
1
Punkte
0
Hallo zusammen,

ich bin aktuell am Verzweifeln über zwei Fritzboxen 7490 + 7390 eine stabile VPN Verbindung herzustellen.

Kurze Problembeschreibung:
Ziel ist zwei Fritzboxen (7390 + 7490) über VPN miteinander zu verbinden, wobei die 7390 hinter einem LTE Router Speedport LTE2 (der nur als Modem konfiguriert ist) sitzt.
Die Verbindung geht auch wunderbar und ohne Probleme, bis sie nach ca. 1 oder 2h mit dem Fehlercode 0x203d abgebrochen wird --> beide Fritzboxen protokollieren zeitgleich diesen Fehlern. Danach folgen Fehler mit LifeTimeExpired und Timeouts. Wiederaufbau der Verbindung geht erst, sobald ich den Router 7490 neu starte bzw. die Verbindung deaktiviert und wieder aktiviert wird.
Interessant zu beobachten ist auch, dass die Verbindung immer in vielfachen von knapp einer Stunde abbricht, also nach 1h, 2h oder 3h - länger als gut 3h ging es aber noch nie.

Zur besseren Verdeutlichung habe ich die Konfiguration mal aufgezeichnet:
2017-02-13_11h37_50.jpg

Hinweis:
als DynDNS habe ich sowohl MyFritz als auch Selfhost probiert, Phänomen bleibt das selbe. Für die Konfiguration wurden die entsprechenden Daten jeweils in die Fitzboxen direkt bei Freigaben --> VPN eingegeben, also nicht mit dem Fitz-Konfigurationstool erstellt.


Ich habe mich auch schon an den AVM Support gewandt, aber hier bekomme ich nicht wirklich tiefgründige Hilfe.

Frage von mir ist nun: Kennt jemand diesen Fehler? Was können Ursachen sein?
Es geht mir in erster Linie um Fehlereingrenzung, sprich: liegt es an der 7390? am Speedport? oder gar an der LTE Verbindung selber?

Ich würde mich sehr über Eure Hilfe freuen und möchte mich im Vorfeld schon dafür bedanken!

mfg
Nontschew
 
Ja das Problem ist mir selbst sehr wohl bekannt. Wenn die FB7390 keinen Traffic "produziert" z.B. via SIP 620->IP-Phone@FB7490, kann die LTE-Verbindung (wohl eine private IP hinter einem CGN) schon mal vom Provider gekappt werden. Da stets nur die FB7390 die VPN-Verbindung anstossen kann, gibt sie halt bei Inaktivität auf.

Diese cfg läuft bei mir sehr stabil über Wochen.

Code:
vpncfg {
        vpncfg_version = 1;
        connections {
                enabled = yes;
                editable = no;
                conn_type = conntype_lan;
                name = "Frei wählbar";
                boxuser_id = 0;
                always_renew = no;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 0.0.0.0;
                remote_virtualip = 0.0.0.0;
                remotehostname = "dyndns der FB7490";
                keepalive_ip = IP der FB7490;

LG
 
Nach dem Hinzufügen der beiden Konfigurationsdateien (von jeder Box eine, steht in den Supportdaten) und der beiden Protokolle (steht ebenfalls in den Supportdaten) kann Dir bestimmt geholfen werden ... ansonsten ist 0x203D ein Zeichen dafür, daß beide Boxen "aus dem Tritt" geraten, was angesichts der ansonsten geschilderten Konfiguration eigentlich auch kein wirkliches Wunder ist.

Eine stabile VPN-Verbindung, bei der eine Seite keine öffentliche IPv4-Adresse hat, ist mit dem FRITZ!Box-GUI bekanntermaßen nicht zu konfigurieren. Das ist hier in vielen Threads auch bereits thematisiert und sollte mit den dort nachzulesenden Hinweisen (Initiator-/Responder-Rolle explizit festlegen) eigentlich recht schnell zu lösen sein.

Sollte das nicht klappen, sieht man dann irgendwann etwas im Protokoll und den passenden Konfigurationsdateien, wenn Du die an Deinen nächsten Beitrag anhängst.

Das hat auch nicht unbedingt etwas mit "no traffic" zu tun (dagegen wirkt das "keepalive_ip" aka "Verbindung dauerhaft halten" bereits), das ist mit ziemlicher Sicherheit ein Problem beim "Rekeying". Die "Verlängerung" auf 8 h Lifetime hat AVM m.W. nur bei "conntype_user" vorgenommen, damit werden die ersten Probleme hier sicherlich nach 54 Minuten auftreten. Das geht dann vielleicht noch gut, wenn der Initiator schnell genug ist und wird sich in diesem Abstand dann auch wiederholen, bis irgendwann der Responder seinerseits zuerst eine neue SA aushandeln will und natürlich den Initiator nicht erreichen kann, denn der kann ja keine "eingehenden Verbindungen". Das dann eintretende Timeout reißt dann auch eine ggf. vom Initiator bereits parallel dazu eingerichtete SA wieder mit in den Abgrund.
 
Danke zunächst für die Antworten. Ich habe mich nun durch das Forum gesucht und die angehängten cfg's erstellt.
Dabei ist in der 7490 (die am IPv4 hängt) der Remotehostname = "".

Wo ich mir nicht sicher bin - da ich mich hier nicht auskenne:
Always_renew = yes bei beiden Fitzboxen? und was ist mit der keepalive_ip = IP der 7490 --> habe ich so eingetragen, braucht es aber den Eintrag auch in der 7390?

cfg der 7490 mit IPv4 -
Code:
vpncfg {
        connections {
                enabled = no;
                conn_type = conntype_lan;
                name = "DS-Lite.selfhost.eu";
                always_renew = yes;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 0.0.0.0;
                remote_virtualip = 0.0.0.0;
                remotehostname = "";
                localid {
                        fqdn = "IPv4.selfhost.eu";
                }
                remoteid {
                        fqdn = "DS-Lite.selfhost.eu";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "FreiWählbar";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.100.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.2.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 192.168.2.0 255.255.255.0";
        }
        ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500", 
                            "udp 0.0.0.0:4500 0.0.0.0:4500";
}


cfg der 7390 mit DS-Lite -
Code:
vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_lan;
                name = "IPv4.selfhost.eu";
                always_renew = yes;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 0.0.0.0;
                remote_virtualip = 0.0.0.0;
                remotehostname = "IPv4.selfhost.bz";
                keepalive_ip = 192.168.100.1;
                localid {
                        fqdn = "DS-lite.selfhost.eu";
                }
                remoteid {
                        fqdn = "IPv4.selfhost.bz";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "FreiWählbar";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.2.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.100.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 192.168.100.0 255.255.255.0";
        }
        ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500", 
                            "udp 0.0.0.0:4500 0.0.0.0:4500";
}


Könnte ich das so probieren oder was ist noch falsch?
 
Zuletzt bearbeitet:
Ich tippe mal, daß der Verbindungsaufbau schon am "enabled = no" scheitern wird.

Das "always_renew" (nach meiner Interpretation die Aufforderung zum "Rekeying" auch dann, wenn keine Daten zu übertragen sind) habe ich bei mir auf der Responder-Seite immer abgeschaltet ... die kann da ohnehin nichts machen.

Die "keepalive_ip"-Einträge kannst Du handhaben wie Du willst, die bauen auch keine Verbindung auf, wenn der Responder gar nicht weiß, wie er die Gegenstelle kontaktieren soll. So ein Eintrag erzeugt halt bei aktiver Verbindung zusätzlichen Traffic - was das auf der Responder-Seite ansonsten bringen sollte, verstehe ich nicht. Auf der Initiator-Seite dient das dann genau dazu, Traffic für den Peer zu erzeugen, der zum Aufbau der SAs führt.

Was sollte Dich denn davon abhalten können, es zu probieren? Selbst wenn noch etwas falsch sein sollte, bringen doch die passenden Protokolle erst den notwendigen Aufschluß.

Ich weiß nicht, wie es anderen geht, aber ich habe (abseits von einem schnellen Blick, wo dann das "enabled = no" in der ersten Zeile direkt ins Auge springt) keine Lust, Konfigurationsdateien "zu analysieren", wenn nicht einmal klar ist, ob die ein Problem enthalten oder nicht. Das mag zwar dem Frager die Arbeit beim Testen ersparen ... aber ich fühle mich dazu nicht berufen und trete hiermit zur Seite - der Nächste (Hilfswillige) bitte.
 
@PeterPawn:
Zunächst Danke für Deine Antwort, die mir auch schon weiter geholfen hat.
Es ging mir nicht darum, das die Dateien analysiert werden sollen, ich wollte nur verstehen was das always_renew und keepalive_ip bewirkt. Damit ist soweit klar, wie ich die Einstellungen für die Initiator/Responder Seite vornehmen muss.
Einigermaßen die Zusammenhänge zu verstehen ist mir immer lieber, als blind drauf los. Nur darum ging es mir. Natürlich werde ich das jetzt entsprechend testen und mich dann wieder melden.

Ich bin übrigens der Meinung, dass Du mit dem von dir angesprochenen 54min Problem recht hast, dass passt ganz gut zu den Zeiten wo die Verbindung dann in die Knie geht.

Und bei dem enabled = no musste ich eben selber lachen... ;-) keine Ahnung wie sich das eingeschlichen hat.
Also erst mal DANKE
 
Wie PeterPawn schrieb, kann es in der IPv4 FB7490 so aussehen (so steht es in meiner IPv4 cfg)

Code:
vpncfg {
        vpncfg_version = 1;
        connections {
                enabled = [COLOR=#ff0000]yes[/COLOR];
                editable = no;
                conn_type = conntype_lan;
                name = "Canary";
                [COLOR=#0000ff]boxuser_id = 0; Entsteht, da weitere VPN-User eingerichtet[/COLOR]
                always_renew = no;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 0.0.0.0;
                remote_virtualip = 0.0.0.0;
                remotehostname = "";
                [COLOR=#800080]keepalive_ip = 0.0.0.0; optional wie von PeterPawn erläutert, falls die Traficrate @LTE nicht zu knapp.[/COLOR]
                localid {
                        fqdn...

Beobachte es halt eine Weile und berichte mal beizeiten.

LG

- - - Aktualisiert - - -

Btw. habe ich auf beiden Boxen
always_renew = no;

eingetragen. Läuft bei mir stabiler
 
Wenn meine Interpretation der Bedeutung halbwegs stimmt, ist das auch kein echter Unterschied ... solange es durch das "keepalive_ip" ständig zu übertragende Daten gibt, stellt sich beim Ablauf einer SA ja die Frage gar nicht erst, ob diese nun auch zu erneuern wäre, wenn es gerade keinen Bedarf dafür gibt.
 
Guten morgen zusammen,

so nun habe ich gestern die angepassten cfg-Files probiert und siehe da, die Verbindung klappte.
Meine Änderungen im cfg-File habe ich wie von Euch beschrieben vorgenommen:
1) FB7390 (Initiator am DS-Lite hinter dem Speedport)
always_renew = yes;
keepalive_ip = 192.168.100.1;
2) FB7490 (Responder am IPv4):
always_renew = no;
remotehostname = "";


Auch blieb die Verbindung damit erst mal stabil und meine Freude war schon groß. Bis heute morgen wieder alles abgebrochen wurde:

Unbenannt.JPG

Die Verbindung wird dann auch nicht wieder aufgebaut, so lange, bis ich an der FB7490 die Internetverbindung neu initialisieren lasse.
Ich habe nun die Support-Daten extrahiert und den VPN Abschnitt raus kopiert.
-> von der FB7390:
Anhang anzeigen 7390_17.02.14-07Uhr__kein wiederaufbau der Verbindung.txt

-> von der FB7490:
Anhang anzeigen 7490_17.02.14-07Uhr__kein wiederaufbau der Verbindung.txt

Der Zeitpunkt wo der Abbruch statt fand, ist jetzt da nicht mehr mit beinhaltet. Die Verbindung wird jetzt nicht wieder aufgebaut...
Kann man hieraus schon etwas weiteres sagen oder was wäre noch an Infos notwendig? Bin am Verzweifeln :-(


Die cfg-Files habe ich jetzt noch mit der boxuser_id = 0 erweitert und die Verbindung noch mal gestartet. Wenn ich den Abbruch mitbekomme, reiche ich die Log's dann von diesem Zeitraum noch nach, sofern das noch etwas hilft....

Ansonsten hoffe ich, dass ihr vielleicht so schon etwas seht.

Besten DANK für Eure Unterstützung!!!

- - - Aktualisiert - - -

Ich habe es nun geschafft, zum Zeitpunkt des Abbruch der VPN-Verbindung jeweils die Supportdaten der Fritten zu ziehen.

Hier die Zeitstempel von Verbindung Aufbau bis Abbruch:
Logging_Abbruch_7390.JPG

Support VPN Daten der FB7390:
Anhang anzeigen FB7390_2017.02.14-1447Uhr__Logging_Abbruch.txt

Support VPN Daten der FB7490:
Anhang anzeigen FB7490_2017.02.14-1446Uhr__Logging_Abbruch.txt

Zur Vollständigkeit die cfg-Files:
FB7390
Anhang anzeigen 7390_DS-lite.txt

FB7490
Anhang anzeigen 7490_IPv4.txt

Und noch mal zur besseren Übersicht der schematische Aufbau des ganzen:
Anhang anzeigen Konfiguration_Schema.pdf


Ich hoffe nun wirklich sehr, damit lässt sich jetzt etwas anfangen. WEnn noch Fragen sind und etwas fehlt, jederzeit gerne. Ansonsten hoffe ich wirklich, dass Ihr mir helfen könnt.
Für Eure Bemühungen bin ich jetzt schon sehr Dankbar!

Viele Grüße
Nontschew
 
Da wirst Du um einen Paketmitschnitt zum richtigen Zeitpunkt nicht herumkommen und ob der dann wirklich hilft, muß sich auch erst noch zeigen.

0x1B heißt, daß da irgendetwas mit dem empfangenen Datenpaket nicht stimmt (schon die Frage, woher die doppelten Pakete kommen sollten, wäre ja hoch interessant, wenn's nicht (vermutlich) nur das Ergebnis einer "falschen Entscheidung" wäre - sieht man halt nur im Packetdump) und da jemand ein Paket wohl bei der Übertragung geändert hätte.

Was aber gar nicht richtig nachvollziehbar ist, warum die Verbindung zunächst mal (10:56 Uhr 7390) von NAT-T (das ist das einzige, was hier überhaupt funktionieren kann) auf direkte Verbindung (Port 500) zurückschalten sollte. Da dabei die Paketformate anders sind, stimmt am Ende der erwartete Aufbau nicht -> das Ergebnis ist wohl das 0x1B, bis man sich wieder auf eine einheitliche Interpretation des Formats verständigen kann.

Vergleicht man nun die Protokolle ab den letzten erfolgreichen Rekeying um 13:42 Uhr, sieht man ja in der 7490 deutlich, daß da die von der 7390 um 14:35 gesendeten Daten gar nicht erst ankamen ... das Ergebnis auf der 7390 (timeout) spricht auch dafür.

Wie soll man jetzt "von außen" erkennen, was da die Ursache sein könnte? Entweder die Telekom überträgt die Daten nach einer gewissen Zeit nicht mehr richtig (das kann auch irgendeine max. Zeit für diei "Blockade" eines Ports oder einer IP-Adresse sein, denn daß da auf der LTE-Seite tatsächlich 4500 als "Absenderport" bei einem CGN erscheint, ist schon recht ungewöhnlich - das ist eher kein "richtiges" CGN bzw. warum nennst Du das "DS-Lite"?) oder der DSL-Anbieter läßt irgendwann keine Daten mehr "rein". In der 7490 kommt jedenfalls (dem Protokoll nach) um 14:35 auch nichts an, was irgendwie falsch oder verfälscht wäre - da ist schlicht nichts, bis die Lifetime der aktiven SA dann auf beiden Seiten abgelaufen ist (14:41:25) und dann kommt beim nächsten Verbindungsversuch die 7390 auch wieder zur 7490 durch (es gab vorher schon andere, seit 14:35:25), hier wird aber um 14:41:58 dann fälschlicherweise wieder auf "ohne NAT" zurückgeschaltet.

Die "verschwundenen Pakete" beim Rekeying mal außer acht gelassen ... wie kommt es jetzt eigentlich dazu, daß da auf einmal kein NAT-T mehr verwendet werden soll?

Kann es sein, daß die 7390 doch ihre eigene (externe) IPv4-Adresse (2.164.4.252) kennt (was bei DS-Lite eigentlich nicht der Fall wäre)? Normalerweise wird in P1 ein Hash über die eigene IPv4-Adresse und die Empfängeradresse (jeweils mit Port) mitgesendet (siehe RFC 3947, Punkt 3.2), den der Empfänger dann mit dem Hash über die bei ihm vorliegenden Adressen (seine eigene und die des Absenders) vergleichen kann - stimmen die Hashwerte nicht überein, gibt es irgendwo auf dem Weg eine zusätzliche Adressübersetzung und es wird auf NAT-T geschaltet. Wenn hier aber von NAT-T wieder zurückgeschaltet werden soll (leider gibt es beim AVM-IPSec m.W. keine Möglichkeit, die Verwendung von NAT-T zu erzwingen, wie bei vielen anderen Implementierungen), dann kann das eigentlich nur daran liegen, daß die 7390 tatsächlich ihre eigene IPv4-Adresse (2.irgendwas) in den Hash-Wert gepackt hat und das kann ja eigentlich nicht sein, die dürfte sie nach Deiner Zeichnung gar nicht kennen.

Das ist also genauso mysteriös wie die Frage, warum da (wenn ich das richtig verstehe, auch immer beim selben - also vierten - Versuch des Rekeyings?) keine weiteren Daten mehr auf der anderen Seite ankommen.

Da kann aber wirklich alles sein, von einem Fehler im Speedport-Router bis zum Netz zwischen den Peers. Nur die FRITZ!Boxen würde ich da tatsächlich ausnehmen wollen, weil VPN zwischen 7390 und 7490 nachweislich funktioniert (auch mit klarer Rollenverteilung) und es schon irgendetwas mit der Umgebung zu tun haben müßte.

Wobei ich zugebe, daß ich das mit der 06.80 bei der 7390 noch nicht getestet habe ... die liegt mir noch nicht so richtig. Mit einer 06.50 auf der 7390 habe ich das hier aber selbst ohne Probleme am Laufen, die 7390 ist bei mir auch der Initiator - ein Problem bei der "Weiterleitung" der eintreffenden Pakete an den zuständigen Daemon (da hat AVM ja praktisch abgerissen und neugebaut mit dem PCP in der neuen Version) bei der 7490 auf der Gegenseite kann es damit also irgendwie auch nicht sein.

Also brauchst Du wohl den jeweiligen (parallelen) Mitschnitt auf dem externen Interface der FRITZ!Boxen beim Auftreten des Problems (wenn das tatsächlich reproduzierbar ist mit festem Timing, ist das ja keine Hürde), damit man zumindest sehen kann, ob und ggf. sogar wo die Pakete nun versanden.

Die Konfiguration sollte eigentlich funktionieren ... das tut sie in dieser Form bei vielen anderen jedenfalls. Daß es nach dem erneuten Verbindungsaufbau auf der 7490-Seite dann funktioniert, dürfte an der neuen IPv4-Adresse auf dieser Seite liegen, wo dann nach der DynDNS-Aktualisierung die 7390 das realisiert (10:59:21) und komplett von vorne beginnt - dabei wird dann auch wieder das NAT richtig erkannt und es funktioniert wieder einige Zeit.

BTW ... beim Mitschnitt der IPSec-Pakete kann man auf der "1. Internetverbindung" die verschlüsselten Pakete (quasi in der Umverpackung) sehen und auf der "Routing-Schnittstelle" die bereits entschlüsselten. Letztere sind sicherlich besser zu untersuchen, aber die anderen sollte man parallel auch mitschneiden, weil die auf der "Routing-Schnittstelle" natürlich nur nach erfolgreicher Entschlüsselung erscheinen.

EDIT: Ich sehe gerade, daß die 7390 und die 7490 bei mir wg. einer leicht geänderten Netzwerk-Topologie gar kein NAT-T mehr verwenden müssen und das damit auch nicht tun ... somit entfällt meine Aussage bzgl. NAT-T, wenn es um "keine Probleme hier" geht. Denkbar wäre also noch, daß bei AVM irgendetwas beim vierten Rekeying bei Verwendung von NAT-T generell schiefgeht bei der 113.06.80 - sicherlich findet sich jemand, der das bei einer Konstellation mit Mobilfunkstick an einer FRITZ!Box und einer 7490 mit 06.80 als Responder dann auch schon als "funktioniert" aus eigener Anschauung bestätigen kann (oder vielleicht auch nicht, dann wäre wenigstens die Ursache weiter umzingelt). Im Protokoll der 7390 fehlt halt genau der Teil, dem man entnehmen könnte, was die 7390 über ihre eigene Adresse so weiß (das wäre das "add" für die Verbindung oder Änderungen aufgrund neuer externer Adresse (aus Sicht der 7390) - was normalerweise auch zum Restart des VPN-Daemons führen sollte, der dann mit dieser Adresse wieder neu initialisiert).
 
Zuletzt bearbeitet:
Hallo PeterPawn,
ich bin zum einen ziemlich erschlagen über die viele Information, zum anderen aber tief beeindruckt über Deine Fachkenntnisse und darüber, dass Du Dir so viel Zeit für die Analyse und die ausführliche Antwort genommen hast. Vielen Dank dafür!!!

Nun mal zu dem, was ich - im Vergleich zu Dir - als absoluter Leihe verstanden habe.
Erst mal muss ich sagen, dass ich mich noch mal betreffs DS-Lite und CGN belesen habe und da bisher wohl falsch unterwegs war. Meine Verbindung vom Speedport geht über LTE, d.h. ich verstehe es so, dass es sich um einen CGN Anschluss, wo ich eine private IP zugewiesen bekomme, handelt.

Zu Deiner Frage:
Kann es sein, daß die 7390 doch ihre eigene (externe) IPv4-Adresse (2.164.4.252) kennt (was bei DS-Lite eigentlich nicht der Fall wäre)? Normalerweise wird in P1 ein Hash über die eigene IPv4-Adresse und die Empfängeradresse (jeweils mit Port) mitgesendet (siehe RFC 3947, Punkt 3.2), den der Empfänger dann mit dem Hash über die bei ihm vorliegenden Adressen (seine eigene und die des Absenders) vergleichen kann - stimmen die Hashwerte nicht überein, gibt es irgendwo auf dem Weg eine zusätzliche Adressübersetzung und es wird auf NAT-T geschaltet. Wenn hier aber von NAT-T wieder zurückgeschaltet werden soll (leider gibt es beim AVM-IPSec m.W. keine Möglichkeit, die Verwendung von NAT-T zu erzwingen, wie bei vielen anderen Implementierungen), dann kann das eigentlich nur daran liegen, daß die 7390 tatsächlich ihre eigene IPv4-Adresse (2.irgendwas) in den Hash-Wert gepackt hat und das kann ja eigentlich nicht sein, die dürfte sie nach Deiner Zeichnung gar nicht kennen.
Kann ich mir nur so erklären, weil ich im cgf-File als localid den DynDNS Namen angegeben habe, wo der Speedport seine IP hin meldet. Ansonsten hat die 7390 ja keinen Kontakt zur Außenwelt und kann die Adresse tatsächlich nicht kennen. Wäre es so im cgf der 7390 richtiger?

Code:
                keepalive_ip = 192.168.100.1;
                localid {
                        [COLOR=#0000ff]fqdn = 192.168.10.2;[/COLOR]     [I]--> das ist die IP mit der die 7390 am Speedport hängt.
                                                    bisher stand hier die DynDNS Adresse, wo der Speedport seine WAN-IP hin gemeldet hat...
                                                    Sprich: fqdn = "LTE-CGN.selfhost.eu"[/I]
                }
                remoteid {
                        fqdn = "IPv4.selfhost.bz";
                }

Das wäre mal das erste was mir auffällt, was evtl. falsch und die Ursache sein könnte???


Ansonsten habe ich verstanden, liegt die Ursache vermutlich beim LTE Anbieter (Telekom) oder am Speedport.
Würde es evtl. etwas bringen, den Speedport durch eine Fritzbox LTE zu ersetzen?

Zum Thema Paketmitschnitt bin ich erst mal überfragt. Damit beschäftige ich mich aber gerne, wenn alles andere - evtl. auch Hardware Wechsel wie oben beschrieben - nicht zum Ziel führt.

Danke für Deine Unterstützung!
 
Zuletzt bearbeitet:
Die Änderung an der Konfigurationsdatei wäre falsch - danach geht erst einmal gar keine VPN-Verbindung mehr.

Die Frage, ob das nun ein exaktes Timing ist (beim vierten Rekeying => also nach 4 * 54 Minuten), habe ich immer noch, aber wenn sich das Thema erst einmal erledigt hat, ist die nicht so wichtig.

Bei der Frage zum Hardware-Tauschs kann ich nicht helfen ... ohne Kenntnis der Ursache wäre jede "fundierte" Einschätzung nur geraten. Liegt es am Speedport, könnte es helfen - liegt es am LTE-Vertrag, aber auch ... oder eben nicht.

Wenn Du das fortsetzen willst, braucht es eine Protokoll-Datei von der 7390, wo man sehen kann, was diese ihrerseits als ihre eigene IP-Adresse ansieht beim VPN (als "localip" in der "< add"-Zeile) und die Aussage (von jemand anderem), daß 113.06.80 und 84.06.80 bei LAN-LAN-Kopplung mit NAT-T und zugewiesenen Rollen funktionieren.

Ich persönlich würde erst einmal die Ursache eingrenzen, bevor ich eine FRITZ!Box LTE kaufe, wenn das Problem vielleicht ganz woanders liegt. Der Aufwand zur genaueren Recherche und der für Kauf und Umkonfiguration dürften sich nicht großartig unterscheiden. Letzteres spart ggf. Zeit, ersteres Geld - beides kann auch vergeblich sein.
 
Die Frage, ob das nun ein exaktes Timing ist (beim vierten Rekeying => also nach 4 * 54 Minuten), habe ich immer noch, aber wenn sich das Thema erst einmal erledigt hat, ist die nicht so wichtig.

Das hat sich natürlich nicht erledigt, ich möchte den Fehler ebenfalls eingrenzen. Das werde ich vermutlich aber nur mit Deiner Unterstützung schaffen!

Also zu der Frage ob das ein exaktes Timing ist 4*54Minuten: Nein das ist es nicht, die Verbindung bricht nicht vor 54min zusammen. Aber auch mal nach genau 60min, oder auch mal nach 114min. In dem Fall waren es mal gut 4h. "Gefühlt" würde ich auch sagen, dass die Verbindung immer länger hält, solange wie ich am PC etwas mache. Wenn alles ruht, bricht es dann nach >54min ab...


Sorry, aber bin mir nicht sicher was du genau mit der Protokoll-Datei von der 7390 meinst. Eine *.export Datei der 7390? Oder ein gesamtes support-File?

Vielleicht kann mir die Frage ja der AVM Support beantworten?
und die Aussage (von jemand anderem), daß 113.06.80 und 84.06.80 bei LAN-LAN-Kopplung mit NAT-T und zugewiesenen Rollen funktionieren.
 
Zuletzt bearbeitet:
Mit dem Protokoll meine ich die "ike.log" aus den Support-Daten der 7390, die muß aber eben diese Zeile mit dem "< add" enthalten (vergleiche das einfach mit der von der 7490, wo Du die Internet-Verbindung neu gestartet hattest gg. 11 Uhr) - die fehlt halt (weil die 7390 "durchlief") im Protokoll der 7390.

Ob Du von AVM da wirklich eine sinnvolle Auskunft kriegst, weiß ich nicht ... versuchen könnte helfen, aber ich würde mich auch auf die "positive Auskunft" aus dem Support nicht verlassen, solange das dort nicht jemand genauso auch nachgestellt und getestet hat. Da ist die Chance, das hier von jemandem mit diesen Boxen und einem Mobilfunk-Stick an der 7390 (das läuft dann am Ende wohl auf dasselbe hinaus wie bei Dir) bestätigt zu bekommen, vermutlich größer - vielleicht findet sich ja jemand mit dieser Konstellation.

Beim "Timing" habe ich jetzt verstanden, daß es nicht immer 3x mit dem Rekeying klappt - Du bist auch sicher, daß Du das jetzt nicht mit der Situation vor Deiner Änderung an den Konfigurationsdateien (als Du Responder und Initiator explizit zugewiesen hast, was in jedem Falle hier richtig ist - daran ändert auch das neue Problem nichts) verwechselst?

Wenn das nämlich so wäre, dann entfallen automatisch alle Theorien, es könnte irgendetwas mit der Dauer der Verbindung zu tun haben - daß es in #1 noch unterschiedliche Zeiträume gab, hatte ich verstanden (da gab es auch einen Grund dafür); ich meinte tatsächlich den aktuellen Stand.
 
Mit dem Protokoll habe ich verstanden. Wenn ich heute Abend zu Hause bin, werde ich das erzeugen und dir zukommen lassen.

Und betreffs Timing, du hast Recht, ich habe den Zeitraum vor meinen Änderungen mit einbezogen. Ich werde die Verbindung heute Abend /Nacht wieder starten und dann die Zeiträume protokollieren, wie lange sie bestand hat.

Schicke ich dann spätestens morgen früh zu.
DANKE!
 
Schicke ich dann spätestens morgen früh zu.
Eilt nicht ;-) ... mein VPN läuft und ich bin auch noch nächsten Monat (vermutlich) hier, also kein "Druck" meinerseits, das irgendwie so schnell wie möglich zu erledigen.

Nur zu irgendeinem "Abschluß" muß es am Ende kommen (das kann eben auch das Switchen auf eine FRITZ!Box LTE sein oder irgendetwas anderes, was nicht direkt eine Lösung ist), damit man nicht "in der Luft" hängenbleibt ohne jede Information für spätere Leser des Threads. Wenn nach dem letzten Beitrag beim (späteren) Leser immer noch die Frage offen bleibt: "Was kam denn da nun raus?", dann wird der den Thread ggf. nur wegen dieser einen Frage noch einmal "aufwärmen".
 
Ich bin vollkommen bei dir, zu einem Abschluss muss es kommen, egal was am ende dabei raus kommt. Dann ist den Lesern geholfen und mir auch... :)

Also, anbei die aufbereiteten Zeiten von Start der Verbindung bis Abbruch:

Anhang anzeigen Zeiten.pdf

Du hattest also Recht, es ist immer eine feste Systematik erkennbar. 1h steht die Verbindung komplett, wenn es darüber geht, dann 2h-6min; 3h-12min; 4h-18min usw... Bezogen auf eine volle Stunde

So, anbei nun noch die log von der 7390 mit der "<Add" Funktion:
Anhang anzeigen FB7390_2017.02.16-0712Uhr__Logging_Add.txt


Ich hoffe das hilft so weiter...
 
Zuletzt bearbeitet:
So, anbei nun noch die log von der 7390 mit der "<Add" Funktion:
Ich hoffe das hilft so weiter...

FB7390_DS-Lite: ike.log
Code:
[COLOR=#ff0000]2017-02-16 07:12:07 avmike:< cb_sa_create_failed(name=IPv4.selfhost.bz,reason=IKE-Error 0x202e)[/COLOR]
2017-02-16 07:12:18 avmike:< add(appl=dsld,cname=Mirko,localip=192.168.10.2, remoteip=0.0.0.0, p1ss=LT8h/all/all/all, p2ss=LT8h/esp-all-all/ah-none/comp-all/no-pfs p1mode=4 keepalive_ip=0.0.0.0 flags=0x803f tunnel xauth cfgmode nat_t no_certsrv_server_auth)
2017-02-16 07:12:18 avmike:new neighbour Mirko:  dynamic  user  every-id  nat_t
2017-02-16 07:12:18 [COLOR=#0000ff]avmike:< add(appl=dsld,cname=IPv4.selfhost.bz,[/COLOR]localip=192.168.10.2, remoteip=255.255.255.255, p1ss=all/all/all, p2ss=esp-all-all/ah-none/comp-all/pfs p1mode=4 keepalive_ip=192.168.100.1 flags=0x8001 tunnel no_xauth no_cfgmode nat_t no_certsrv_server_auth)
2017-02-16 07:12:18 avmike:new neighbour IPv4.selfhost.bz:  nat_t
2017-02-16 07:12:18 avmike:IPv4.selfhost.bz start_vpn_keepalive 192.168.100.1
[COLOR=#ff0000]2017-02-16 07:13:46 avmike:IPv4.selfhost.bz: Phase 1 failed (initiator): IKE-Error 0x202d
2017-02-16 07:13:46 avmike:< cb_sa_create_failed(name=IPv4.selfhost.bz,reason=IKE-Error 0x202d)[/COLOR]
2017-02-16 07:13:49 avmike:IPv4.selfhost.bz: Warning: source changed from 0.0.0.0:500 to 93.217.149.197:500
2017-02-16 07:13:49 avmike:mainmode IPv4.selfhost.bz: selected lifetime: 3600 sec(no notify)
2017-02-16 07:13:49 avmike:mainmode IPv4.selfhost.bz: add SA 1
2017-02-16 07:13:49 avmike:IPv4.selfhost.bz remote peer supported XAUTH
2017-02-16 07:13:49 avmike:IPv4.selfhost.bz remote peer supported DPD
2017-02-16 07:13:49 avmike:IPv4.selfhost.bz remote peer supported NAT-T RFC 3947
2017-02-16 07:13:49 avmike:IPv4.selfhost.bz: sending embedded inital contact message (0,93.217.149.197,0.0.0.0)
2017-02-16 07:13:49 avmike:IPv4.selfhost.bz: switching to NAT-T (Initiator)
2017-02-16 07:13:49 avmike:IPv4.selfhost.bz: Phase 1 ready
2017-02-16 07:13:49 avmike:IPv4.selfhost.bz: current=0.0.0.0 new=93.217.149.197:4500
2017-02-16 07:13:49 avmike:IPv4.selfhost.bz start_vpn_keepalive already running
2017-02-16 07:13:49 avmike:IPv4.selfhost.bz: no valid sa, reseting initialcontactdone flag
2017-02-16 07:13:49 avmike:IPv4.selfhost.bz: local is behind a nat
2017-02-16 07:13:49 avmike:IPv4.selfhost.bz: sending initial contact message
2017-02-16 07:13:49 avmike:IPv4.selfhost.bz: start waiting connections
2017-02-16 07:13:49 avmike:IPv4.selfhost.bz: Phase 2 starting (start waiting)
2017-02-16 07:13:50 avmike:IPv4.selfhost.bz: Phase 2 ready
2017-02-16 07:13:50 avmike:< cb_sa_created(name=IPv4.selfhost.bz,id=1,...,flags=0x00012101)
2017-02-16 07:13:50 avmike:IPv4.selfhost.bz stop_vpn_keepalive to 192.168.100.1
2017-02-16 07:13:50 avmike:IPv4.selfhost.bz start_keepalive_timer 3540 sec
2017-02-16 07:13:50 avmike:IPv4.selfhost.bz: start waiting connections
2017-02-16 07:13:50 avmike:IPv4.selfhost.bz: NO waiting connections
2017-02-16 07:14:00 avmike:>>>4500 nat-t-keepalive[93.217.149.197:4500]
IKE-Error 0x202E "dns: unspecified error"
IKE-Error 0x202D "dns: timeout"
IKE-Error 0x2027 "timeout"
IKE-Error 0x202B "id type not supported"
http://service.avm.de/help/de/FRITZ-Box-Fon-WLAN-7490/014/hilfe_syslog_122
https://avm.de/service/fritzbox/fri...Box-Netzwerken-kann-nicht-hergestellt-werden/

es sieht nach Problem mit DynDNS aus; Bitte ddnslog_1.txt aus supportdata.txt beifügen.

und wo ist das ike.log der FB7490-IPv4 ?
diese müssen natürlich zeitlich zueinander passen und einen "Rekeying"-Vorgang bzw. VPN-Tunnelabbruch umfassen,
d.h. >= 2,5 Std. umfassen
 
Zuletzt bearbeitet:
PeterPawn wollte explizit das log der 7390 mit der "<Add" Funktion sehen, daher habe ich nur dieses File gepostet.
Das Logging von beiden Fritzboxen mit Abbruch findest du unter #9.

Bitte ddnslog_1.txt aus supportdata.txt beifügen

Wenn damit das ike.log gemeint ist, steht dazu nichts drinne. Was auch logisch ist, da den dynDNS der speedport bedient, siehe Übersicht Konfiguration #1

Code:
##### BEGIN SECTION dyndns DynDNS
dyndns
ls: /var/tmp/ddnslog*: No such file or directory
##### END SECTION dyndns

Anmerkung hierzu:
Code:
[COLOR=#ff0000]2017-02-16 07:12:07 avmike:< cb_sa_create_failed(name=IPv4.selfhost.bz,reason=IKE-Error 0x202e)[/COLOR]
Am 16.02. um 07:11 Uhr habe ich händisch den Speedport neu gestartet um die von PeterPawn gewünschte "<Add" Funktion auf der 7390 zu erzeugen. Evtl. hat der Fehler damit zu tun und nichts mit dem selbständigen Abbruch der VPN Verbindung

- - - Aktualisiert - - -


#########################################################################################################################################

Ich habe nun doch noch mal die ike.logs beider Fritzboxen gezogen und sowohl auf der FB7490 als auch auf der FB7390 das "<add" mitschneiden können.

Zeitliche Zusammenfassung (alles 17.02.):

03:36:29 FB7490: Zwangstrennung + Aufbau neue Internetverbindung --> add Funktion ausgelöst --> VPN funktioniert
05:11:51 Speedport: händischer Neustart, damit neue Internetverbindung --> add Funktion auf der FB7390 ausgelöst
06:13:39 FB7390: VPN Verbindung abgebrochen, Fehler 0x2027 (gilt natürlich auch für die 7490, hier ist Lifetime expired eingetragen)

Anbei die zugehörigen ike.log

FB7390:
Anhang anzeigen FB7390_2017.02.17-0620Uhr__Logging_Add_Abbruch.txt

FB7490:
Anhang anzeigen FB7490_2017.02.17-0620Uhr__Logging_Add_Abbruch.txt

@PeterPawn: Konntest Du Dir die in #17 geposteten Zeiten+Daten bzw. jetzt die neuen ike.log einmal ansehen? Besten DANK!!
 
Zuletzt bearbeitet:
@Nontschew:
Ich weiß nicht so richtig, wie ich Dir jetzt helfen soll bzw. was Du an neuen Erkenntnissen anhand der beiden Protokolle erwarten würdest, was nicht in den bisher gezeigten schon zu sehen war.

Dadurch, daß Du die Aktionen auf beiden Seiten zu unterschiedlichen Zeitpunkten ausgeführt hast, kann man m.E. auch nicht auf einen definierten Zeitraum für das Auftreten des Fehlers schließen. Durch den innerhalb der vermuteten Timeout-Zeitspanne liegenden Neustart auf der LTE-Seite und die damit einhergehende Verschiebung der 54-Minuten-Intervalle kann man m.E. nicht mit Sicherheit sagen, daß das Problem zwischen 180 und 240 Minuten nach dem letzten erfolgreichen Verbindungsaufbau auftritt. Das mußt Du also wohl noch einmal (bzw. eigentlich mind. zweimal bei unveränderten Rahmenbedingungen) testen.

Nach den sichtbaren Zeilen im 7390-Protokoll zu urteilen, sieht sich die 7390 auf einer privaten IPv4-Adresse - damit dürfte die NAT-Erkennung (das mit den Hashes hatte ich schon beschrieben) nur dann schiefgehen, wenn die Daten für P1 fälschlicherweise nicht direkt über das Internet übertragen werden (und damit auf der anderen Seite mit der öffentlichen IP-Adresse aus 2.irgendwas ankommen), sondern durch den (alten) Tunnel zum Peer gelangen.

Nur dann kann der Hash über Absenderadresse und -Port beim Empfänger mit dem übereinstimmen, was die 7390 ihrerseits sendet.

Ich wollte die "add"-Zeile ja nicht als Selbstzweck sehen, sondern um vom Zeitpunkt eines Fehlers, wo beide Boxen von NAT-T auf "direkt" zurückschalten wollen, bis zur letzten "add"-Zeile zurückblättern zu können, welche IP-Adresse die 7390 wohl als ihre eigene senden mag - das kann man auch einem Mitschnitt entnehmen, wenn man die Cookies kennt und die Hash-Berechnung dann einfach für die "Kandidaten" selbst ausführt und mit dem gesendeten Wert vergleicht

Genau das geht aber mit den letzten Protokollen auch nicht - das einzige Mal, daß da der Rückfall auf direkte Verbindung "angedacht" wird, ist am Beginn der 7390-Datei und von dort an führt kein Weg zurück zu einer vorhergehenden "add"-Zeile.

Nachfolgende Zeilen haben nur begrenzten Wert - danach funktioniert ja die Verbindung erst einmal wieder und den Fehler mit dem Wechsel des Ports gibt es danach in den Protokollen nicht erneut.

Mit so einer Änderung ist natürlich auch ein Wechsel des Paketformats verbunden, das ist ja nicht nur "komm, wir nehmen einen anderen Port" und das war's dann - da wird ein Paketformat verwendet, bei dem NAT-Gateways auf dem Weg vom Absender zum Empfänger Adressen und Ports austauschen können, ohne daß die Integrität (bzw. die Integritätsprüfung) des verschlüsselten Payloads "leidet".

Solange die gezeigten Konfigurationsdateien tatsächlich die richtigen sind (insb. bei den "accesslist"-Einträgen), gibt es keinen ersichtlichen Grund, warum die Daten (UDP an Port 4500 oder 500) durch den Tunnel zum Peer gesendet werden sollten. Das wäre nur dadurch zu erklären, daß alle Daten durch den Tunnel gesendet werden sollen (also eine "any any"-Rule) und dabei die IKE-Pakete nicht davon ausgenommen werden (mit einer "deny"-Regel für UDP 4500 und 500 - wobei beim Versuch, UDP 4500 ebenfalls über den Tunnel zu senden, eigentlich gar keine VPN-Verbindung funktionieren dürfte).

Ob das wirklich der Fall ist (dem Protokoll der 7390 nach wollte diese vor 03:36 ja wieder diesen "Rückschritt" machen, im Protokoll der 7490 fehlt der Teil wieder), muß dann eben ein Paketmitschnitt auf beiden Seiten her und zwar auch hier ein zeitgleicher.

Ich habe es in diesem Thread nicht noch einmal gesondert betont, aber zur Fehlersuche bei einer VPN-Verbindung gehört generell einfach ein zeitgleiches Vorgehen (am besten ein Neustart) auf beiden Seiten und dann eben auch das zeitgleiche Protokoll (und der Mitschnitt, wenn man einen anfertigt) von beiden Seiten.

Ich habe keine Ahnung, ob der Speedport-Router irgendwie selbst noch etwas mit L2TP/IPSec oder IPSec mit IKE anstellt, um Daten durchs LTE-Netz zu kriegen - schon die Tatsache, daß da immer dieselbe IP-Adresse und tatsächlich der Port 4500 (beim Absender/Initiator) verwendet wird, ist eine etwas merkwürdige Konstellation - da sieht ja fast wie eine öffentliche IPv4-Adresse aus, die dem Speedport da zugeordnet wird (wenn auch eine wechselnde, wie der Neustart des Speedport ja zeigt, da wird aus 2.166.201.135 dann ja 2.174.54.216).

Ob das nun immer nach derselben Zeit aus dem Tritt gerät oder nicht, wäre ebenfalls noch zu klären - so ein fester Zeitraum würde (auch ohne exakte Kenntnis, wann das nun genau auftritt) eben auf ein Timeout-Problem irgendeiner beteiligten Komponente hindeuten.

Parallel dazu wäre natürlich auch ein Protokoll nützlich (wobei das aus einem kompletten Mitschnitt wieder extrahiert werden könnte), ob wirklich im letzten "Intervall" vor dem Fehler beim Rekeying der Tunnel noch die ganze Zeit über funktioniert und Daten transportieren könnte. Ob wirklich DPD verwendet wird oder nicht, sieht man im AVM-Protokoll ja auch nicht (und weiß man beim AVM-Daemon auch nicht genau), aber entsprechende Pakete (oder auch die "keepalive"-Echo-Requests inkl. Antworten) sollten sich im Mitschnitt problemlos finden lassen.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.