VPN 7390-7490 über LTE: Nur noch in Minutenintervallen

tplus

Neuer User
Mitglied seit
20 Mrz 2007
Beiträge
115
Punkte für Reaktionen
2
Punkte
18
Hallo,

die FB7390 meiner Zweitwohnung in Frankreich ist mit meiner 7490 in Deutschland über ein VPN verbunden welches ständig aufrecht erhalten wird (keine öffentliche IP in F). Die Verbindung wird von Raspis in F und D mit Pings (Smokeping) ständig geprüft. Die 7390 ist über ein Netgear LB2120 Modem (bridge-mode) über LTE mit dem Internet verbunden, ich habe auch die Möglichkeit einer ADSL-Verbindung. Am 15.5. bin ich von F nach D gefahren und bis zum 19. Mai morgens lief alles normal, etwas größere Latenz als bei ADSL, aber ansonsten okay.

Seitdem wird die Verbindung nur noch für ca. 2-3 Minuten aufgebaut, danach ist wieder 6-7 Minuten Pause. Pings zu anderen Zielen, auch in D, sind aber normal und werden nicht unterbrochen. Wenn ich wieder zu ADSL wechsele, ist die Verbindung stabil, beim Wechsel zurück auf LTE geht es wieder los. Anhängend Screenshots der Smokeping Diagramme. Der Wechsel ADSL - LTE - LTE gestört ist gut zu erkennen (last 10 days).

Die Konfiguration der FB7390 in F:

Code:
**** END OF FILE ****
**** CFGFILE:vpn.cfg
/*
 * /var/tmp.cfg
 * Tue May 22 16:55:58 2018
 */

meta { encoding = "utf-8"; }

vpncfg {
        vpncfg_version = 1;
        connections {
                enabled = yes;
                editable = no;
                conn_type = conntype_lan;
                name = "deutschland.selfhost.bz";
                boxuser_id = 0;
                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 = "deutschland.selfhost.bz";
                keepalive_ip = 192.168.1.1;
                localid {
                        fqdn = "$$$$NLxxxxx";
                }
                remoteid {
                        fqdn = "$$$$CExxxx";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "$$$$JAxxxx";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.10.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.1.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 192.168.1.0 255.255.255.0";
                app_id = 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";
}


// EOF

**** END OF FILE ****
**** CFGFILE:user.cfg

Wer weiß Rat?

Besten Dank für Tips...
 

Anhänge

  • ping_f_wechsel_adsl.JPG
    ping_f_wechsel_adsl.JPG
    106 KB · Aufrufe: 7
  • ping_f_nach_d.JPG
    ping_f_nach_d.JPG
    162.9 KB · Aufrufe: 7
  • connection_france.JPG
    connection_france.JPG
    132.5 KB · Aufrufe: 6
An anderer Stelle hatte ich mal empfohlen, statt dem schnöden Ping es mit einem VOIP-Account via VPN zu versuchen? Wenn Dein LTE-Provider keinen (in seinen Augen sinnvollen) Traffic erkennt (ein Ping gehört sicherlich nicht dazu?), kappt er ggfs. die Verbindung. Im Protokoll Deines LTE-ISP sollte das ja erkennbar sein?
Btw rechnet mein spanischer Mobilfunkprovider nur den Download-Traffic ab aus Mobilfunk-Client-Sicht, weshalb ich für die SIP-Accounts via VPN mit der kleinsten Trafficrate von 600MB/Monat für 2,51€ stets locker hinkomme.
LG
 
Es existiert eine VOIP Verbindung (sipgate). Bitte beachten: Die LTE Verbindung wird nicht gekappt, alle anderen Pings, z. B. zu google.fr oder dus.net laufen konstant durch. Ich kann den VOIP Anschluss erreichen, sipgate immer meldet eine Verbindung.

Es betrifft NUR die VPN Verbindung der beiden Fritzboxen. Die Ursache ist also hier zu suchen, nicht beim LTE Modem. Und: es lief ja einige Tage normal. Ich habe nichts verändert.

Die Pings wären mir natürlich egal, aber ohne VPN kann ich die Webcam oder den FHEM Server nicht erreichen. 2 min. Zeitfenster sind sehr mühsam. Es wird z. B. auch eine RDP-Verbindung zum Raspi unterbrochen. Sinnvoller Datentraffic ist also vorhanden.
 
Zuletzt bearbeitet:
Irgendwo e.g. in der FR-FB sollte doch eine Fehler-Nr. auftauchen, falls dort -das Eigenleben des LB2120 kann ich nicht beurteilen- alle 2 Min. die VPN zusammenbricht? Die Gegenstelle in DE lauscht nur und meldet nur Standard-Fehler.
LG
Nachtrag: Das SIPing-Intervall ist auf welche Zeit eingestellt? 30sek? oder 120 ;)
 
Dann läuft imho die Telefonie nicht durch den VPN-Tunnel bzw. wurde aus dem LTE/Privat-IP-Bereich angestossen. Registriere ein IP-Phone mit MSN/Registrar der DE-FB und umgekehrt aus DE-FB-Sicht. Ich habe das quasi "kreuzweise" eingerichtet und gute Erfahrung damit.
LG
 
Mein Tipp ... noch einmal einen Schritt zurück machen und klar und deutlich abklären, daß hier tatsächlich auch getrennte Rollen zum Einsatz kommen. Das hört sich mit den zwei Minuten (oben waren es noch 2-3, wo es dann wieder unwahrscheinlicher wird) nämlich eher so an, als würde die Verbindung in einer Richtung als "tot" angesehen (daher ja "dead peer detection"), während die andere Richtung korrekt aufgebaut wurde.

Es kann auch gut sein, daß erst nach einer kurzen Unterbrechung der VPN-Verbindung so ein Problem auftritt, wenn die Peers beide gleichzeitig (auch ohne weiteren Traffic) in so einem Falle die SAs erneuern sollen bzw. wollen. Solange es nicht einen wirklich guten Grund gibt (und solange die Keepalive-Pings der Box selbst funktionieren, liegt der eigentlich nicht vor), sollte man auf "always_renew" verzichten. Die (derzeitige) Interpretation dieses Parameters wäre es ja, daß der Peer, in dessen Konfigurationsdatei dieser Parameter auftaucht, eine abgelaufene SA auch dann erneuert, wenn eigentlich kein Traffic für den Tunnel vorliegt und man eine "on demand"-Verbindung eigentlich sanft entschlummern lassen könnte.

Mit diesem Parameter könnte also auch eine ansonsten passive Box auf die Idee kommen, ihrerseits eine Verbindung zu initiieren - auch wenn sie (in der Konfigurationsdatei) gar keine Adresse bzw. keinen Namen für den Peer hat. Den kriegt sie aber beim erfolgreichen Verbindungsaufbau (und wenn's schlecht läuft und kein CGN dazwischen ist, klappt im Anschluß sogar der eingehende Verbindungsaufbau leidlich) und so kann sie schon mal auf die Idee kommen, ihrerseits Kontakt aufnehmen zu wollen - das geht bekanntlich nur zu häufig dann schief, wenn sich zwei Verbindungen gegenseitig immer die Haxen weghauen.

Ich würde hier also noch mal einen Blick in die deutsche Konfiguration werden, da jede Angabe für "remotehostname" und "remote_ip" entfernen und auch das Erneuern der SAs ohne Traffic verbieten. Eine "Zwangspause" der deutschen Box (z.B. durch einen Restart nach dem Ändern der Konfiguration) könnte auch Wunder wirken ... wenn sich der IKE-Daemon auf der anderen Box erst mal so weit settlen kann, daß er jedwede zuvor ausgehandelte SA (die haben i.d.R. eine Lebensdauer von 1 h) auch tatsächlich abräumen kann und nicht der Verfall irgendeiner alten und eigentlich inaktiven SA gleich wieder hektische Betriebsamkeit (wg. "always_renew=yes") auslöst.

Klartext: Konfiguration in D überprüfen, ggf. anpassen, in die Box laden und deaktivieren. Dann den deutschen Peer neu starten (damit man die Internet-Verbindung weiterhin nutzen kann, der Peer aber trotzdem eine neue Adresse kriegt, die dann irgendwann zum Peer in F "durchdringt") und etwas mehr als eine Stunde später die VPN-Verbindung in D wieder aktivieren. Bei korrekter Konfiguration (passiver Responder in D) sollte sich dann auch die französische Box zeitnah wieder melden und den Tunnel nunmehr nur noch von einer Seite neu aufbauen wollen, was seiner Lebenszeit in den meisten Fällen förderlich ist.
 
Der Smokeping besagt ja nur, dass irgendwo auf der Strecke die Pakte verloren gehen. Vielleicht liegt hier ein Routing-Problem vor. Am besten mal mit Pingplotter die Hops überwachen.
 
Die FB-France befindet sich hinter CG-NAT, daher auch das "always_renew". Von Deutschland aus anpingen kann ich die nicht. Die in D eingetragene DDNS ist daher nicht gültig.
 
Imho wirst Du Routing aus Mobilfunknetzen nie wirklich transparent verfolgen können? Wie in Deiner Funkzelle bishin zu Deinem "Tarif" verfahren wird birgt etliche Unschärfen!
LG
 
Die FB-France befindet sich hinter CG-NAT, daher auch das "always_renew".
Was hat das genau miteinander zu tun?

Die in D eingetragene DDNS ist daher nicht gültig.
Daraus schließe ich jetzt einfach mal, daß es sich nicht um "handgemachte" Konfigurationen handelt und das wäre dann in der Tat der erste Schritt auf dem Weg zu einer langzeitstabilen VPN-Verbindung.
 
Da das VPN nicht von Deutschland aus aufgebaut werden kann, sollte das VPN ständig aufrecht erhalten werden. Über Nacht gab es eine Verbindungsunterbrechnung in F (Neustart des Modems jeden Morgen) und in der FB-D hatte ich die VPN Verbindung deaktiviert. Nach Verbindungsaufbau aber das gleiche Schema. Hier die Konfig der FB-D:

Code:
**** CFGFILE:vpn.cfg
/*
 * /var/tmp.cfg
 * Wed May 23 10:01:55 2018
 */

meta { encoding = "utf-8"; }

vpncfg {
        vpncfg_version = 1;
        connections {
                enabled = yes;
                editable = no;
                conn_type = conntype_user;
                name = "handy";
                boxuser_id = 10;
                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 = 130.180.55.201;
                keepalive_ip = 0.0.0.0;
                remoteid {
                        key_id = "$$$$xxx";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "LT8h/all/all/all";
                keytype = connkeytype_pre_shared;
                key = "$$$$xxx";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = yes;
                xauth {
                        valid = yes;
                        username = "$$$$xxx";
                        passwd = "$$$$xxx";
                }
                use_cfgmode = yes;
                phase2localid {
                        ipnet {
                                ipaddr = 0.0.0.0;
                                mask = 0.0.0.0;
                        }
                }
                phase2remoteid {
                        ipaddr = 130.180.55.201;
                }
                phase2ss = "LT8h/esp-all-all/ah-none/comp-all/no-pfs";
                accesslist =
                             "permit ip 0.0.0.0 0.0.0.0 130.180.55.201 255.255.255.255";
                app_id = 0;
        } {
                enabled = yes;
                editable = no;
                conn_type = conntype_lan;
                name = "frankreich.selfhost.bz";
                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 = "frankreich.selfhost.bz";
                keepalive_ip = 0.0.0.0;
                localid {
                        fqdn = "$$$$xxx";
                }
                remoteid {
                        fqdn = "$$$$xxx";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "$$$$xxx";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.1.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.10.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 192.168.10.0 255.255.255.0";
                app_id = 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";
}


// EOF

**** END OF FILE ****

Ich hatte da jetzt nichts geändert (zu früher ADSL in F) da es ja insgesamt 2-3 Wochen (bis meine 20 GB fast aufgebraucht waren) problemlos lief.

Man kann übrigens sehen, dass bei Netzverkehr (z. B. RDP) die Intervalle etwas dichter werden.
 
Zuletzt bearbeitet:
Lass den
Code:
remotehostname = "frankreich.selfhost.bz";
besser leer.
Code:
remotehostname = "";
Das geht auch mit der FR-DSL-Verbindung.
LG
 
Zuletzt bearbeitet:
@tplus:
Schau Dich mal hier im IPPF etwas näher um und versuche etwas zum Thema "initiator" und "responder" beim AVM-VPN zu finden (es gibt genug zu diesem Thema).

Für eine VPN-Verbindung, die automatisch aufgebaut wird (von der Box in F, von D aus ginge es ja ohnehin nicht, wenn F hinter einem CGN hängt), reicht es vollkommen aus, wenn die Box in F die Adresse der Box in D kennt und unter "keepalive_ip" dort eine Adresse aus dem LAN in D (die muß nicht existieren, nur unter die entsprechende Maske und damit unter das "Routing" nach D fallen) eingetragen wurde.

Da braucht es auch in F eigentlich kein "always_renew" (weil das Ping ja dafür sorgt, daß der Tunnel wegen "echtem Traffic" wieder aufgebaut wird) ... aber solange es in D aus ist und da auch keine Adresse für die Box in F eingetragen ist (das geht nun mal nur mit handgemachten Konfigurationen), sollte das in F auch kein K.O. darstellen und Du kannst es später bei Gelegenheit korrigieren, wenn Du vor Ort bist.

Allerdings gehe ich dabei davon aus, daß auf beiden Boxen die jeweils letzte Release-Version installiert ist ... bei älteren Versionen konnte es schon mal vorkommen, daß der Keepalive-Ping nicht richtig weiterlief, nachdem der Tunnel neu aufgebaut wurde.

Ansonsten (wenn das oben Stehende also nicht hilft) braucht es für die weitere Diagnose schon noch ein paar mehr Infos ... die findet man dann in den Support-Daten der beiden Boxen. Worauf es dabei im Einzelnen ankommt aus so einer Support-Datei und wie weit man beim Maskieren vor der Veröffentlichung hier gehen kann und sollte, steht auch schon in genug anderen Threads zum Thema "VPN mit getrennten Rollen" und auch in vielen anderen, die sich nur mit VPN an sich befassen.
 
Besten Dank. Nach löschen des Remotehostnames in D und Neustart in D ist die Verbindung jetzt stabil (ein Abbruch während RDP). Es gibt trotzdem noch etwas Optimierungsbedarf. Die Webcam in F sendet bei ADSL (16/1 MB) einen halbwegs akzeptablen Stream. Bei LTE (60/20 MB) ist das eine Diashow (alle 40 sek ein Bild). Problem scheint die hohe Latenz D>F zu sein (95 - 340 ms). F>D ist besser (82 - 117 ms). Unter "Last" sinkt die Latenz D>F sofort. Siehe Screenshot: von 18:18 bis 18:26 habe ich auf dem Raspi in F über RDP Tetris gespielt.

Wie könnte ich das optimieren?

ping_d_nach_f_2.JPG ping_d_nach_f.JPG
 
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.