[Frage] Änderung bei VPN führt zu Reconnect

ty1977

Neuer User
Mitglied seit
3 Jun 2007
Beiträge
29
Punkte für Reaktionen
5
Punkte
3
Warum wird immer die Internet-Verbindung kurz getrennt, egal ob ich:
  • Einen VPN-Eintrag lösche
  • Einen VPN-Eintrag ändere
  • Einen VPN-Eintrag erstelle
  • Einen VPN-Eintrag "an/aus" stellen
Es wird hier auch nicht geprüft, ob ein Telefonat geführt wird.

Ist das so bei Design ?

Früher (7170 etc.) war es ja nur über Import möglich, VPN Einstellungen zu erstellen.
Aber seit es in der GUI geht, muss dass noch sein ?
 
Zuletzt bearbeitet:
Wenn das so ist, verwendest Du eine alte FRITZ!OS-Version und solltest diese aktualisieren. Wenn es keine neuere Firmware-Version gibt, solltest Du (nicht nur wegen des beschriebenen VPN-Problems) auf neuere Hardware wechseln.
 
Ich verwende eine 7490 :(.

Ich habe sowohl User VPN Zugänge als auch FB zu FB
 
"bei Design": Bei keiner Firmware-Version von AVM habe ich das jemals anders erlebt: Bei jeglicher VPN-Änderung wird die Internet-Verbindung neu gestartet.
 
Das ist bei mir definitiv anders (gerade noch einmal getestet mit 141.06.83). Es wurde eine deaktivierte VPN-Verbindung per GUI aktiviert, zuvor wurde der Status der Internet-Verbindung (per Shell-Zugang) ausgegeben und im Anschluß erneut - wie man sehen kann, wurde die Internetverbindung nicht erneut aufgebaut:

Code:
# showdsldstat
time: 2019-04-25 12:39:30
0: sync_cable: CABLE (showtime)  OPERATIONAL
 maxspeed    106000000   53000000    106Mbit/s  53.00Mbit/s
 actual            224       1016     224bit/s   1.02Kbit/s
                                         0.00%        0.00%
running (voip=0,tr069=0,tv=0,ntp=0,ipv6=0,ipv4=0,vpn=0)
Active Provider: -
PPPoE Forward: disabled
VPN:  connected since 2019-04-25 04:54:40 (setup time 6 secs)
    localvirtualip 0.0.0.0 dns1 0.0.0.0 dns2 0.0.0.0
VPN: vpn2 disconnected (last connect time -)
VPN: MyFRITZ!App 2 (vpn_myfritz) disconnected (last connect time -)

0: name internet
0: sync_group: sync_cable
0: iface eth_udma0 RBE/14/dsl c8:0e:14:xx:xx:xx stay online 1 (voip) (prop: default internet) (prop6: default internet)
0: IPv6: native unnumbered (ia_pd)
0: IPv6: connected since 2019-04-22 12:56:21 (setup time 2 secs) (connect cnt 1)
0: IPv6: address 2a02:8109:a400:xxxx::1/64 valid 5082 prefered 2382
0: IPv6: prefix 2a02:8109:a400:xxxx::/62 valid 5082 prefered 2382 (first used)
0: IPv6: mtu 1500
0: IPv6: dns 2a02:8100:c0:241::4:1101 valid 5082 (dhcp)
0: IPv6: dns 2a02:8100:c0:249::4:1101 valid 5082 (dhcp)
0: IPv4: native
0: IPv4: connected since 2019-04-22 12:56:19 (setup time 0 secs) (connect cnt 1)
0: IPv4: disconnect prevention disabled
0: IPv4: ip 91.64.23x.xxx mask 255.255.255.0 gw 91.64.23x.xxx dhcp mtu 1500
0: IPv4: masqaddr 91.64.23x.xxx
0: IPv4: dns 83.169.184.33 83.169.184.97
0: route 91.64.23x.0/24 protocol iface
0: route 83.169.184.33/32 via 91.64.23x.xxx protocol dns
0: route 83.169.184.97/32 via 91.64.23x.xxx protocol dns
0: RX bytes:24177904466 pkt error:0 discard:0 filtered:16789 dropped:180
0: RX pkts:31075872 unicast:18372465 multicast:350481 broadcast:12352926
0: TX bytes:6035870085 pkt error:0 discard:0 filtered:0 dropped:15380
0: TX pkts:7826921 unicast:7825891 multicast:199 broadcast:831
# Apr 25 12:41:03 dsld[1272]: route_and_proxyarp_delete(192.168.131.14): not found
Apr 25 12:41:03 dsld[1272]: route_and_proxyarp_delete(192.168.131.3): not found
# showdsldstat
time: 2019-04-25 12:41:13
0: sync_cable: CABLE (showtime)  OPERATIONAL
 maxspeed    106000000   53000000    106Mbit/s  53.00Mbit/s
 actual           2416       1808   2.42Kbit/s   1.81Kbit/s
                                         0.00%        0.00%
running (voip=0,tr069=0,tv=0,ntp=0,ipv6=0,ipv4=0,vpn=0)
Active Provider: -
PPPoE Forward: disabled
VPN: vpn1 connected since 2019-04-25 12:41:05 (setup time 2 secs)
     localvirtualip 0.0.0.0 dns1 0.0.0.0 dns2 0.0.0.0
VPN: vpn_newly_enabled connecting ...
VPN: vpn2 disconnected (last connect time -)
VPN: MyFRITZ!App 2 (vpn_myfritz) disconnected (last connect time -)

0: name internet
0: sync_group: sync_cable
0: iface eth_udma0 RBE/14/dsl c8:0e:14:xx:xx:xx stay online 1 (voip) (prop: default internet) (prop6: default internet)
0: IPv6: native unnumbered (ia_pd)
0: IPv6: connected since 2019-04-22 12:56:22 (setup time 2 secs) (connect cnt 1)
0: IPv6: address 2a02:8109:a400:xxxx::1/64 valid 4980 prefered 2280
0: IPv6: prefix 2a02:8109:a400:xxxx::/62 valid 4980 prefered 2280 (first used)
0: IPv6: mtu 1500
0: IPv6: dns 2a02:8100:c0:241::4:1101 valid 4980 (dhcp)
0: IPv6: dns 2a02:8100:c0:249::4:1101 valid 4980 (dhcp)
0: IPv4: native
0: IPv4: connected since 2019-04-22 12:56:20 (setup time 0 secs) (connect cnt 1)
0: IPv4: disconnect prevention disabled
0: IPv4: ip 91.64.23x.xxx mask 255.255.255.0 gw 91.64.232.254 dhcp mtu 1500
0: IPv4: masqaddr 91.64.23x.xxx
0: IPv4: dns 83.169.184.33 83.169.184.97
0: route 91.64.23x.0/24 protocol iface
0: route 83.169.184.33/32 via 91.64.23x.xxx protocol dns
0: route 83.169.184.97/32 via 91.64.23x.xxx protocol dns
0: RX bytes:24178265916 pkt error:0 discard:0 filtered:16799 dropped:180
0: RX pkts:31081153 unicast:18372654 multicast:350547 broadcast:12357952
0: TX bytes:6035923899 pkt error:0 discard:0 filtered:0 dropped:15381
0: TX pkts:7827169 unicast:7826139 multicast:199 broadcast:831
Wie man sieht, wird zwar die VPN-Verbindung neu aufgebaut (vpn1 war zuvor aktiv), aber sowohl die IPv4- als auch die IPv6-Verbindung wird vom "dsld" gehalten.

Es ist also zumindest vom Modell und/oder der Firmware-Version abhängig, ob die Internetverbindung unterbrochen wird bei Änderungen an der VPN-Konfiguration.
 
Ich habe es gerade noch einmal mit der 7.01 versucht. Sowohl aktivieren als auch deaktivieren erzeugt bei mir einen Reconnect.
Ich kann leider nicht mit dem Log dienen ...
 
Man kann wohl tatsächlich nicht von dem Verhalten von xDSL- auf das von Kabel-Boxen schließen und vice versa. Wo bei xDSL die Verbindung neu gestartet wird, gibt es bei meiner 6490 nur einen Neustart der anderen bestehenden VPN-Verbindung.

Code:
25.04.19  13:50:01  VPN-Verbindung zu lan2lan1.andilao.vpn [84.185.*.*] IKE SA: DH2/AES-256/SHA2-512 IPsec SA: ESP-AES-256/SHA2-512/LT-3600 wurde erfolgreich hergestellt.
25.04.19  13:50:01  VPN-Verbindung zu lan2lan1.andilao.vpn wurde getrennt. Ursache: 12 SA loss
25.04.19  13:49:55  VPN-Zugang eingerichtet. Diese Änderung erfolgte im Heimnetz von IP-Adresse: 192.168.*.*.
25.04.19  13:49:55  FRITZ!Box-Benutzer "vpn.benutzer1" wurde Zugang aus dem Internet erlaubt (VPN-Recht). Diese Änderung erfolgte im Heimnetz von IP-Adresse: 192.168.*.*.
 
Ich müßte es auch erst noch einmal testen, aber mir ist so, als ob sich meine 7490 (die hängt aber per LAN1 im Netz, wenn auch im Router-Modus) genauso verhält ... daher hatte ich meinerseits einfach geschlußfolgert (vielleicht eben auch falsch), daß das nach den zusätzlichen Änderungen, die AVM am VPN schon zur 07.0x vorgenommen hatte (jetzt sagt das FRITZ!OS ja auch noch an, welche Algorithmen verwendet werden - schon im Event-Log - und die interne Protokollierung ist auch viel umfangreicher), jetzt das "normale Verhalten" wäre und auch bei den Boxen gilt, die das DSL-Modem verwenden.

Aber ich werde das nachher mal bei der 7580 mit 07.10 noch einmal testen (allerdings auch da nur den Betrieb über den WAN-Anschluß) - es gibt ja keinen offensichtlichen Grund für dieses Verhalten und daher glaube ich (bis zum Beweis des Gegenteils) nicht, daß das tatsächlich "by design" ist. Der "dsld" (und der "avmike" hängt ja hinter dem und wird sogar (iirc) vom "ctlmgr" neu gestartet bei Änderungen an der VPN-Konfiguration - da muß ich beim Test mal auf dessen PID achten) hat ja eigentlich mit dem VPN praktisch nichts zu tun - solange es nicht darum geht, daß die erste und einzige VPN-Verbindung (de-)aktiviert wird, denn dann müssen auch noch die Portweiterleitungen im "pcpd" gesetzt werden und dafür könnte ich mir eine solche Notwendigkeit (wenn man keinen Bock darauf hat, das "smarter" umzusetzen) dann auch wieder vorstellen.

Jedenfalls mal wieder ein spannendes Thema ... und nach den ganzen Änderungen durch AVM lohnt sich sicherlich auch mal wieder eine ausführliche Bestandsaufnahme. Mir war sogar so, als hätte ich dieses Verhalten irgendwo hier festgehalten (EDIT: das war dann wohl schon hier (vorletzter Absatz): https://www.ip-phone-forum.de/threads/fritz-os6-vpn-manuell-per-cfg-einrichten.283418/#post-2139159 bzw. noch früher), als AVM es (dachte ich zumindest) geändert hat.

Denn daß/wenn nunmehr nicht bei jedem Furz beim VPN die Internetverbindung neu aufgemacht wird, was ja dann i.d.R. auch wieder eine neue IP-Adresse bewirkt, womit auch wieder erst die DynDNS-Änderungen (die sind ja verzögert, je nachdem, was im Eintrag als "livedelay" eingetragen ist, bis zu 4 Minuten) ausgeführt werden müssen, damit es bei einer bestehenden und aktiven VPN-Verbindung weitergehen kann, etc. pp., ist ja ein deutlicher Fortschritt gewesen.

Wenn ich das aber gerade richtig gesehen habe, stimmt die frühere Aussage mit dem (De-)Aktivieren aber auch nicht mehr so ganz - zumindest macht auch meine 141.06.83 beim "ctlmgr_ctl" und einer Änderung an "activated" eine andere, aktiv genutzte (VPN-)Verbindung neu auf. I.d.R. verifiziere ich so etwas ja, bevor ich es aufschreibe, daher bin ich mir fast sicher, daß ich damals unter dem o.a. Link ein Verhalten beschrieben habe, wie ich es auch tatsächlich beobachtet hatte - nur habe ich versäumt, in diesem Beitrag die Version zu erwähnen und das tatsächliche "erste Auftreten" suche ich jetzt nicht ohne echte Notwendigkeit - die "alten Erkenntnisse" bringen für die aktuellesten Versionen ja dann offensichtlich ohnehin nichts mehr.
 
Zwischenstand:
Eine 7390 mit 06.85 am 1&1-VDSL-Anschluß (über Telekom) verhält sich ebenso, wie ich das zuvor beschrieben habe ... bei einer Änderung (De-/Aktivierung) einer (zweiten bzw. weiteren) VPN-Verbindung bleibt die Internetverbindung problemlos bestehen, nur (eine) weitere VPN-Verbindung(en) wird/werden dabei neu aufgebaut.

Damit würde ich die Beobachtung, daß das bei AVM noch nie anders war als in #4 geschildert bzw. daß es bei den DSL-Boxen generell anders wäre, bezweifeln ... hier ist also auch ein DSL-Modem involviert. Wie es sich bei späteren Versionen (die 7390 geht nur bis 06.85) verhält, muß ich erst noch weiter testen - denkbar, daß AVM da wieder eine Rolle rückwärts gemacht hat.

EDIT:
Dieselbe 7390 hält auch die Internetverbindung, wenn man die letzte VPN-Verbindung deaktiviert - sogar die Änderungen an den Portweiterleitungen kann man in den Supportdaten verfolgen (04:53 Uhr wurde die Internetverbindung erneuert, danach nur VPN-Konfigurationen de-/aktiviert). Das zwischenzeitliche Löschen und erneute Aufsetzen der Portweiterleitungen kommt also mit einiger Wahrscheinlichkeit vom "avmike" - was zumindest auch logisch wäre - nachdem die letzte Verbindung deaktiviert wurde, werden auch die Portweiterleitungen nicht erneut eingerichtet:
Code:
2019-04-26 04:53:19.193 - MAP  changed  VOIP     TCP [192.168.xxx.1]:5060 "VOIP": external [79.197.aaa.bbb]:5060
2019-04-26 04:53:19.196 - MAP  changed  VPN      UDP [192.168.xxx.1]:4500 "VPN": external [79.197.aaa.bbb]:4500
2019-04-26 04:53:19.199 - MAP  changed  IGDPROBE TCP [192.168.xxx.1]:9 "IGDPROBE4": external [79.197.aaa.bbb]:9
2019-04-26 04:53:19.207 - MAP  changed  VOIP     UDP [192.168.xxx.1]:5060 "VOIP": external [79.197.aaa.bbb]:5060
2019-04-26 04:53:19.238 - MAP  changed  SELF     TCP [192.168.xxx.1]:xxxxx"TCP xxxxx": external [79.197.aaa.bbb]:xxxxx
2019-04-26 04:53:19.242 - MAP  changed  VOIP     UDP [192.168.xxx.1]:7078-7109 "VOIP": external [79.197.aaa.bbb]:7078-7109p
2019-04-26 04:53:19.249 - MAP  changed  VPN      UDP [192.168.xxx.1]:500 "VPN": external [79.197.aaa.bbb]:500
2019-04-26 10:59:28.699 - MAP  deleted  VPN      UDP [192.168.xxx.1]:500 "VPN": external [79.197.aaa.bbb]:500
2019-04-26 10:59:28.702 - MAP  deleted  VPN      UDP [192.168.xxx.1]:4500 "VPN": external [79.197.aaa.bbb]:4500
2019-04-26 10:59:28.719 - MAP  complete VPN      UDP [192.168.xxx.1]:500 "VPN": external [79.197.aaa.bbb]:500
2019-04-26 10:59:28.721 - MAP  complete VPN      UDP [192.168.xxx.1]:4500 "VPN": external [79.197.aaa.bbb]:4500
2019-04-26 11:09:37.146 - MAP  deleted  VPN      UDP [192.168.xxx.1]:500 "VPN": external [79.197.aaa.bbb]:500
2019-04-26 11:09:37.148 - MAP  deleted  VPN      UDP [192.168.xxx.1]:4500 "VPN": external [79.197.aaa.bbb]:4500
2019-04-26 11:09:37.193 - MAP  complete VPN      UDP [192.168.xxx.1]:500 "VPN": external [79.197.aaa.bbb]:500
2019-04-26 11:09:37.195 - MAP  complete VPN      UDP [192.168.xxx.1]:4500 "VPN": external [79.197.aaa.bbb]:4500
2019-04-26 11:18:27.957 - MAP  deleted  VPN      UDP [192.168.xxx.1]:500 "VPN": external [79.197.aaa.bbb]:500
2019-04-26 11:18:27.958 - MAP  deleted  VPN      UDP [192.168.xxx.1]:4500 "VPN": external [79.197.aaa.bbb]:4500
Damit ist meine These aus #8, daß es wg. der Portweiterleitungen eine Rolle spielen könnte, wieviele VPN-Verbindungen aktiviert sind, auch widerlegt - zumindest für die genannte Version.

Auch das erneute Aktivieren der (ersten) VPN-Verbindung nach diesem Test, führte bei dieser Box nicht dazu, daß die Internet-Verbindung neu aufgebaut wurde.
 
Ich kann das von Peter bestätigen für eine FB7362SL (06.83) und FB7412 (06.83 und 06.85).

Was mich noch stört, ist das bei Änderung (De-/Aktivierung) eines VPN-Eintrages, alle VPN-Verbindungen getrennt und wieder hergestellt werden.
Muß das sein?
 
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.