[Gelöst] VPN zw. DSL-Box in D und UMTS-Box in ES - ES-Verbindung hat 2 IPs (1 priv 1 öffentl)?

[Docmarten]

Nur ist die Konfiguration, in der diese "accesslist" mit den zwei Einträgen verwendet wird, hier ja offensichtlich nicht die für das Büronetzwerk, sondern die für die "DE-Box" oder "DE-DSL" - so steht es jedenfalls weiter oben - und da macht das keinen wirklichen Sinn, zumal 192.168.50.0/24 ja auch noch das LAN dieser Box ist. Für eine weitere Box mit "Büronetzwerk" wäre das immer noch richtig, wenn diese über die VPN-Verbindung zu "DE-DSL" (also zur 192.168.50.0/24) ebenfalls das Netz 192.168.0.0/24 (also die Box in ES) erreichen soll.

D.h. auf "permit ip any 192.168.50.0 255.255.255.0" reduzieren?

Ich würde hier also das "keepalive_ip" auf eine existierende Adresse setzen ... das erzeugt zwar etwas mehr Traffic (weil jetzt auf das "ICMP echo request"-Paket auch eine Antwort erfolgen sollte), aber eben auch in beide Richtungen regelmäßigen Traffic, der dann wieder Verbindungen am Leben und CGN-Connections (für den aufgebauten Tunnel) offen hält.

keepalive_ip der DE-Box (die der ES-Box soll ich ja gem. Micha auf die IP der DE-Box setzen)? Und dann irgendeine existierende IP aus dem ES-Netzwerk verwenden, korrekt?

wie immer verweise ich in diesem Kontext auf die "ike.log" als Protokoll und notfalls sogar auf den Paketmitschnitt für den Tunnel, wenn man wissen will, warum der am Ende offenbar wg. Inaktivität abgebaut wurde.

Danke, ist Neuland für mich, werde mich einlesen.

@Micha:

Interessanter wäre zusätzlich die Einrichtung eines IP-Telefons in der ES-Box zu der *13# (span. Mobilfunknummer des Sticks) und die Registrierung in der DE-Box.

Wie meinst Du das mit der Einrichtung "zur" spanischen Mobilfunknummer des Sticks? Sipgate habe ich auf der ES-Box ja bereits am Laufen.
Danke + Grüße
Martin

 

[PeterPawn]

Ein "keepalive_ip" auf einer Seite (theoretisch ist es sogar egal, auf welcher) sollte bereits ausreichend sein, solange daraus auch Traffic in beide Richtungen erwächst, es also eine Antwort gibt, weil das Ziel existiert (und antworten kann, was bei der Box selbst am wahrscheinlichsten ist, weil die schließlich den Tunnel auch aufbauen und verwalten muß).

Es gab zwar mal ein paar FRITZ!OS-Versionen von AVM, wo der ICMP-Generator wohl nicht richtig funktionieren wollte (und dann kann man tatsächlich versuchen, auf SIP-Registrierungen als Ersatz auszuweichen, ansonsten macht das in meinen Augen nur begrenzten Sinn - zumal da auch noch die ständige Zunahme der Zeit zwischen zwei Versuchen zu berücksichtigen wäre, wenn eine SIP-Registrierung nicht erfolgreich war) ... aber das kriegt man mit einem Packet-Dump im Handumdrehen heraus, ob das "keepalive_ip" die gewünschte Wirkung entfalten kann oder nicht - entweder man sieht die ICMP-Pakete oder man sieht sie nicht.

Ein "keepalive_ip" auf beiden Seiten müßte (zumindest vor den von AVM verkündeten Änderungen) die Datenmenge im "idle mode" der VPN-Verbindung noch einmal verdoppeln, weil dann in beide Richtungen je ein "ICMP echo request" und ein "ICMP echo reply" erfolgen sollte - innerhalb desselben Intervalls.

 

[Docmarten]

Ein "keepalive_ip" auf einer Seite (theoretisch ist es sogar egal, auf welcher) sollte bereits ausreichend sein, solange daraus auch Traffic in beide Richtungen erwächst, es also eine Antwort gibt, weil das Ziel existiert (und antworten kann, was bei der Box selbst am wahrscheinlichsten ist, weil die schließlich den Tunnel auch aufbauen und verwalten muß).

Danke, dann setze ich mal keepalive_ip der ES Box auf die IP der DE Box.

aber das kriegt man mit einem Packet-Dump im Handumdrehen heraus, ob das "keepalive_ip" die gewünschte Wirkung entfalten kann oder nicht - entweder man sieht die ICMP-Pakete oder man sieht sie nicht.

Habe mich gerade mal beim Thema ike.log/Telnet-Ersatz auf den Stand bringen wollen, und auf wen stoße ich (via https://www.antary.de/2017/07/04/fritzbox-shell-zugang-nachruesten-auch-bei-aktuellem-fritzos/)? Auf https://www.ip-phone-forum.de/threads/fritz-box-7580-ohne-shell-zugang-was-nun.292558/ Aber ich nehme an, dass dieser Weg durch Schließen der Lücken nicht mehr geht. Was empfiehlst Du für den Shell-Zugriff? Du hast ja auch einige Tolos auf Deiner Github-Seite im Angebot, wobei ich nicht weiß, ob ich mich da wirklich drantraue...

 

[PeterPawn]

Weder für den Inhalt der "ike.log" noch für den Mitschnitt der Pakete braucht es einen Shell-Zugang zur Box - das ist schon mal der falsche Weg. Es gibt zwar weiterhin gute Gründe (zumindest bei einigen), warum man einen solchen bräuchte, aber die Problemstellung hier gehört nicht (bzw. nicht wirklich) dazu.

 

[Micha0815]

wenn eine SIP-Registrierung nicht erfolgreich war

Das interessante aus meiner Sicht daran ist, dass eine rote LED auf der DE-FB leuchtet, falls die Registrierung >1h andauert. Ob der gewünschte Effekt via beidseitigem "keepalive_ip" stetig andauert ist nach meiner (unmassgeblichen) Erfahrung auch eine Stabilitätssache des Mobilfunknetzes/der Mobilfunkverbindung. Je höher der "Grundtraffic" umso höher die Wahrscheinlichkeit imho der steten Mobilfunkverbindung.
Auf den Kanaren habe ich es schon mehrfach live erlebt, dass über Stunden garkein "Netz" vorhanden war, was einem Stick+Box inkl. VPN höchst übel nehmen können bzgl. Neuverbindung.

...wobei ich nicht weiß, ob ich mich da wirklich drantraue

Aus der Ferne bekommst Du das eher nicht auf Deine ES-FB7490. Zuhause auf 6490 oder sonstige DOCSIS ... Da musst schon das etwas grössere Besteck auftischen. In den erweiterten Supportdateien auf beiden Seiten zeitnah zum VPN-Aufbau steht wohl auch der Abschnitt ike-log drin
LG

 

[stoney]

Ich möchte jetzt aus der Ferne nur im Notfall Änderungen an der ES-Box durchführen, denn wenn sie danach wegen irgendeines Fehlers "weg" ist",

Richte doch für diese Zeit den Zugriff via MyFRITZ-Internetzugang ein. So jedarf es keiner VPN Verbindung falls etwas schief geht.
Über die Länge des Threads habe ich diesen Umstand scheinbar vergessen....

 

[PeterPawn]

Das dürfte wieder daran scheitern, daß genau die Box in ES, um die es hier geht, keine öffentliche IPv4-Adresse hat, wenn sie über den USB-Stick im Internet ist. Da wird MyFRITZ! dann auch nichts dran ändern ...

 

[Docmarten]

Das dürfte wieder daran scheitern, daß genau die Box in ES, um die es hier geht, keine öffentliche IPv4-Adresse hat, wenn sie über den USB-Stick im Internet ist. Da wird MyFRITZ! dann auch nichts dran ändern ...

Das ist auch nach wie vor mein Wissensstand. Wegen dieses Umstands sind ja genau diese Verrenkungen erforderlich, bei denen mich Micha und PeterPawn so nett unterstützen

 

[Docmarten]

wie immer verweise ich in diesem Kontext auf die "ike.log" als Protokoll und notfalls sogar auf den Paketmitschnitt für den Tunnel, wenn man wissen will, warum der am Ende offenbar wg. Inaktivität abgebaut wurde.

Ich nehme an, dass das der Inhalt des ike.log ist (danke Micha für den Hinweis, dass man das aus den erweiterteten Supportdaten herausfischen kann/muss). Zuvor die "Zusammenfassung" aus dem normalen Ereignislog:

15.01.20 09:36:10 VPN-Verbindung zu ESDE.2020 [47.60.41.226] IKE SA: DH2/AES-256/SHA2-512 IPsec SA: ESP-AES-256/SHA2-512/LT-3600 wurde erfolgreich hergestellt.
15.01.20 08:46:33 VPN-Fehler: ESDE.2020, IKE-Error 0x2027
15.01.20 08:45:47 VPN-Verbindung zu ESDE.2020 wurde getrennt. Ursache: 9 Dead Peer Detection
15.01.20 08:37:09 VPN-Verbindung zu ESDE.2020 [47.60.41.226] IKE SA: DH2/AES-256/SHA2-512 IPsec SA: ESP-AES-256/SHA2-512/LT-3600 wurde erfolgreich hergestellt.
15.01.20 08:06:04 VPN-Fehler: ESDE.2020, IKE-Error 0x2027 [4 Meldungen seit 15.01.20 08:05:08]
15.01.20 08:04:54 VPN-Verbindung zu ESDE.2020 wurde getrennt. Ursache: 9 Dead Peer Detection
15.01.20 03:52:01 VPN-Verbindung zu ESDE.2020 [47.60.41.226] IKE SA: DH2/AES-256/SHA2-512 IPsec SA: ESP-AES-256/SHA2-512/LT-3600 wurde erfolgreich hergestellt.

D.h. um 08:04 und um 08:45 hatte ich versucht, auf ES zuzugreifen.

2020-01-15 06:44:06 avmike:< cb_sa_created(name=ESDE.2020,id=4,...,flags=0x00032003)
2020-01-15 06:44:06 avmike:ESDE.2020: start waiting connections
2020-01-15 06:44:06 avmike:ESDE.2020: NO waiting connections
2020-01-15 06:44:16 avmike:>>>4500 nat-t-keepalive[IP.der.ES.box:18477]
2020-01-15 06:45:04 avmike:< delete_sa(appl=dsld,cname=ESDE.2020,id=3,what=7,reason=Lifetime expired)
2020-01-15 06:45:04 avmike:FreeIPsecSA: spi=5AF08429        protocol=3 iotype=1
2020-01-15 06:45:04 avmike:FreeIPsecSA: spi=0D12        protocol=4 iotype=1
2020-01-15 06:45:04 avmike:FreeIPsecSA: spi=EF9DA74F        protocol=3 iotype=2
2020-01-15 06:45:04 avmike:FreeIPsecSA: spi=9FAC        protocol=4 iotype=2
2020-01-15 07:28:03 avmike:<<< 4500 aggressive mode[IP.der.ES.box:18477] ESDE.2020: V1.0 720 IC 925a0e5d8da4028b RC 00000000 0000 SA flags=
2020-01-15 07:28:03 avmike:aggressive mode ESDE.2020: selected lifetime: 3600 sec(no notify)
2020-01-15 07:28:03 avmike:ESDE.2020 receive VENDOR ID Payload: XAUTH
2020-01-15 07:28:03 avmike:ESDE.2020 receive VENDOR ID Payload: DPD
2020-01-15 07:28:03 avmike:ESDE.2020 receive VENDOR ID Payload: NAT-T RFC 3947
2020-01-15 07:28:04 avmike:ESDE.2020: add phase 1 SA: DH2/AES-256/SHA2-512/3600sec id:5
2020-01-15 07:28:04 avmike:>>> aggressive mode 4500[IP.der.ES.box:18477] ESDE.2020: V1.0 588 IC 925a0e5d8da4028b RC a668dbb99ebe9fbc 0000 SA flags=
2020-01-15 07:28:04 avmike:<<< 4500 aggressive mode[IP.der.ES.box:18477] ESDE.2020: V1.0 236 IC 925a0e5d8da4028b RC a668dbb99ebe9fbc 0000 HASH flags=e
2020-01-15 07:28:04 avmike:ESDE.2020: Phase 1 ready
2020-01-15 07:28:04 avmike:ESDE.2020: current=IP.der.ES.box:18477 new=IP.der.ES.box:18477
2020-01-15 07:28:04 avmike:ESDE.2020: local is behind a nat
2020-01-15 07:28:04 avmike:ESDE.2020: remote is behind a nat
2020-01-15 07:28:04 avmike:ESDE.2020: start waiting connections
2020-01-15 07:28:04 avmike:ESDE.2020: NO waiting connections
2020-01-15 07:31:03 avmike:ESDE.2020: renew request for dynamic user ignored.
2020-01-15 07:34:03 avmike:ESDE.2020: del phase 1 SA 4
2020-01-15 07:38:08 avmike:<<< 4500 quickmode[IP.der.ES.box:18477] ESDE.2020: V1.0 2332 IC 925a0e5d8da4028b RC a668dbb99ebe9fbc a85cb438 HASH flags=e
2020-01-15 07:38:08 avmike:>>> quickmode 4500[IP.der.ES.box:18477] ESDE.2020: V1.0 380 IC 925a0e5d8da4028b RC a668dbb99ebe9fbc a85cb438 HASH flags=e
2020-01-15 07:38:08 avmike:<<< 4500 quickmode[IP.der.ES.box:18477] ESDE.2020: V1.0 108 IC 925a0e5d8da4028b RC a668dbb99ebe9fbc a85cb438 HASH flags=e
2020-01-15 07:38:08 avmike:ESDE.2020: Phase 2 ready
2020-01-15 07:38:08 avmike:NEW Phase 2 SA: ESP-AES-256/SHA2-512 SPI: 2A11C5D5 LT: 3600 I/O: IN
2020-01-15 07:38:08 avmike:NEW Phase 2 SA: ESP-AES-256/SHA2-512 SPI: 55EEB5EE LT: 3600 I/O: OUT
2020-01-15 07:38:08 avmike:NEW Phase 2 SA: IPComp-LZJH SPI: 7F2 LT: 3600 I/O: IN
2020-01-15 07:38:08 avmike:NEW Phase 2 SA: IPComp-LZJH SPI: 4AE6 LT: 3600 I/O: OUT
2020-01-15 07:38:08 avmike:< cb_sa_created(name=ESDE.2020,id=5,...,flags=0x00032003)
2020-01-15 07:38:08 avmike:ESDE.2020: start waiting connections
2020-01-15 07:38:08 avmike:ESDE.2020: NO waiting connections
2020-01-15 07:38:18 avmike:>>>4500 nat-t-keepalive[IP.der.ES.box:18477]
2020-01-15 07:44:05 avmike:< delete_sa(appl=dsld,cname=ESDE.2020,id=4,what=7,reason=Lifetime expired)
2020-01-15 07:44:05 avmike:FreeIPsecSA: spi=E731CA19        protocol=3 iotype=1
2020-01-15 07:44:05 avmike:FreeIPsecSA: spi=C467        protocol=4 iotype=1
2020-01-15 07:44:05 avmike:FreeIPsecSA: spi=8E34EA91        protocol=3 iotype=2
2020-01-15 07:44:05 avmike:FreeIPsecSA: spi=8A11        protocol=4 iotype=2
2020-01-15 08:03:59 avmike:>r> infomode 4500[IP.der.ES.box:18477] ESDE.2020: V1.0 140 IC 925a0e5d8da4028b RC a668dbb99ebe9fbc be23e3b6 HASH flags=e
2020-01-15 08:04:08 avmike:>r> infomode 4500[IP.der.ES.box:18477] ESDE.2020: V1.0 140 IC 925a0e5d8da4028b RC a668dbb99ebe9fbc b35d3c02 HASH flags=e
2020-01-15 08:04:45 avmike:>r> infomode 4500[IP.der.ES.box:18477] ESDE.2020: V1.0 140 IC 925a0e5d8da4028b RC a668dbb99ebe9fbc c4105ac7 HASH flags=e
2020-01-15 08:04:54 avmike:< delete_sa(appl=dsld,cname=ESDE.2020,id=0,what=3,reason=Dead Peer Detection)
2020-01-15 08:04:54 avmike:>r> infomode 4500[IP.der.ES.box:18477] ESDE.2020: V1.0 124 IC 925a0e5d8da4028b RC a668dbb99ebe9fbc 57ba66e8 HASH flags=e
2020-01-15 08:04:54 avmike:FreeIPsecSA: spi=2A11C5D5        protocol=3 iotype=1
2020-01-15 08:04:54 avmike:>r> infomode 4500[IP.der.ES.box:18477] ESDE.2020: V1.0 124 IC 925a0e5d8da4028b RC a668dbb99ebe9fbc db82f1fa HASH flags=e
2020-01-15 08:04:54 avmike:FreeIPsecSA: spi=07F2        protocol=4 iotype=1
2020-01-15 08:04:54 avmike:>r> infomode 4500[IP.der.ES.box:18477] ESDE.2020: V1.0 124 IC 925a0e5d8da4028b RC a668dbb99ebe9fbc d60c82ce HASH flags=e
2020-01-15 08:04:54 avmike:FreeIPsecSA: spi=55EEB5EE        protocol=3 iotype=2
2020-01-15 08:04:54 avmike:>r> infomode 4500[IP.der.ES.box:18477] ESDE.2020: V1.0 124 IC 925a0e5d8da4028b RC a668dbb99ebe9fbc fcae421a HASH flags=e
2020-01-15 08:04:54 avmike:FreeIPsecSA: spi=4AE6        protocol=4 iotype=2
2020-01-15 08:04:54 avmike:>r> infomode 4500[IP.der.ES.box:18477] ESDE.2020: V1.0 124 IC 925a0e5d8da4028b RC a668dbb99ebe9fbc 2646adfb HASH flags=e
2020-01-15 08:04:54 avmike:ESDE.2020: del phase 1 SA 5
2020-01-15 08:04:54 avmike:< create_sa(appl=dsld,cname=ESDE.2020)
2020-01-15 08:04:54 avmike:ESDE.2020: Phase 1 starting
2020-01-15 08:04:54 avmike:>>> aggressive mode [IP.der.ES.box] ESDE.2020: V1.0 720 IC 5cd9d65d548aa33e RC 00000000 0000 SA flags=
2020-01-15 08:04:56 avmike:>r> aggressive mode [IP.der.ES.box] ESDE.2020: V1.0 720 IC 5cd9d65d548aa33e RC 00000000 0000 SA flags=
2020-01-15 08:05:00 avmike:>r> aggressive mode [IP.der.ES.box] ESDE.2020: V1.0 720 IC 5cd9d65d548aa33e RC 00000000 0000 SA flags=
2020-01-15 08:05:08 avmike:ESDE.2020: Phase 1 failed (initiator): IKE-Error 0x2027
2020-01-15 08:05:08 avmike:< cb_sa_create_failed(name=ESDE.2020,reason=IKE-Error 0x2027)
2020-01-15 08:05:11 avmike:< create_sa(appl=dsld,cname=ESDE.2020)
2020-01-15 08:05:11 avmike:ESDE.2020: Phase 1 starting
2020-01-15 08:05:11 avmike:>>> aggressive mode [IP.der.ES.box] ESDE.2020: V1.0 720 IC eae29d373a2becc RC 00000000 0000 SA flags=
2020-01-15 08:05:13 avmike:>r> aggressive mode [IP.der.ES.box] ESDE.2020: V1.0 720 IC eae29d373a2becc RC 00000000 0000 SA flags=
2020-01-15 08:05:17 avmike:>r> aggressive mode [IP.der.ES.box] ESDE.2020: V1.0 720 IC eae29d373a2becc RC 00000000 0000 SA flags=
2020-01-15 08:05:25 avmike:ESDE.2020: Phase 1 failed (initiator): IKE-Error 0x2027
2020-01-15 08:05:25 avmike:< cb_sa_create_failed(name=ESDE.2020,reason=IKE-Error 0x2027)
2020-01-15 08:05:33 avmike:< create_sa(appl=dsld,cname=ESDE.2020)
2020-01-15 08:05:33 avmike:ESDE.2020: Phase 1 starting
2020-01-15 08:05:33 avmike:>>> aggressive mode [IP.der.ES.box] ESDE.2020: V1.0 720 IC a7ce9f854651f766 RC 00000000 0000 SA flags=
2020-01-15 08:05:35 avmike:>r> aggressive mode [IP.der.ES.box] ESDE.2020: V1.0 720 IC a7ce9f854651f766 RC 00000000 0000 SA flags=
2020-01-15 08:05:39 avmike:>r> aggressive mode [IP.der.ES.box] ESDE.2020: V1.0 720 IC a7ce9f854651f766 RC 00000000 0000 SA flags=
2020-01-15 08:05:47 avmike:ESDE.2020: Phase 1 failed (initiator): IKE-Error 0x2027
2020-01-15 08:05:47 avmike:< cb_sa_create_failed(name=ESDE.2020,reason=IKE-Error 0x2027)
2020-01-15 08:05:50 avmike:< create_sa(appl=dsld,cname=ESDE.2020)
2020-01-15 08:05:50 avmike:ESDE.2020: Phase 1 starting
2020-01-15 08:05:50 avmike:>>> aggressive mode [IP.der.ES.box] ESDE.2020: V1.0 720 IC 8e919c669a66d0ec RC 00000000 0000 SA flags=
2020-01-15 08:05:52 avmike:>r> aggressive mode [IP.der.ES.box] ESDE.2020: V1.0 720 IC 8e919c669a66d0ec RC 00000000 0000 SA flags=
2020-01-15 08:05:56 avmike:>r> aggressive mode [IP.der.ES.box] ESDE.2020: V1.0 720 IC 8e919c669a66d0ec RC 00000000 0000 SA flags=
2020-01-15 08:06:04 avmike:ESDE.2020: Phase 1 failed (initiator): IKE-Error 0x2027
2020-01-15 08:06:04 avmike:< cb_sa_create_failed(name=ESDE.2020,reason=IKE-Error 0x2027)
2020-01-15 08:22:04 avmike:<<< 4500 aggressive mode[IP.der.ES.box:18494] ???: V1.0 720 IC e1970a4976a742d1 RC 00000000 0000 SA flags=
2020-01-15 08:22:04 avmike:aggressive mode ESDE.2020: selected lifetime: 3600 sec(no notify)
2020-01-15 08:22:04 avmike:ESDE.2020 receive VENDOR ID Payload: XAUTH
2020-01-15 08:22:04 avmike:ESDE.2020 receive VENDOR ID Payload: DPD
2020-01-15 08:22:04 avmike:ESDE.2020 receive VENDOR ID Payload: NAT-T RFC 3947
2020-01-15 08:22:05 avmike:ESDE.2020: add phase 1 SA: DH2/AES-256/SHA2-512/3600sec id:6
2020-01-15 08:22:05 avmike:>>> aggressive mode 4500[IP.der.ES.box:18494] ESDE.2020: V1.0 588 IC e1970a4976a742d1 RC 1d6ce628b2976484 0000 SA flags=
2020-01-15 08:22:05 avmike:ESDE.2020: Warning: source changed from IP.der.ES.box:500 to IP.der.ES.box:18494
2020-01-15 08:22:05 avmike:<<< 4500 aggressive mode[IP.der.ES.box:18494] ESDE.2020: V1.0 236 IC e1970a4976a742d1 RC 1d6ce628b2976484 0000 HASH flags=e
2020-01-15 08:22:05 avmike:ESDE.2020: Phase 1 ready
2020-01-15 08:22:05 avmike:ESDE.2020: current=IP.der.ES.box new=IP.der.ES.box:18494
2020-01-15 08:22:05 avmike:ESDE.2020: local is behind a nat
2020-01-15 08:22:05 avmike:ESDE.2020: remote is behind a nat
2020-01-15 08:22:05 avmike:ESDE.2020: sending initial contact message
2020-01-15 08:22:05 avmike:>r> infomode 4500[IP.der.ES.box:18494] ESDE.2020: V1.0 124 IC e1970a4976a742d1 RC 1d6ce628b2976484 4ca77713 HASH flags=e
2020-01-15 08:22:05 avmike:ESDE.2020: start waiting connections
2020-01-15 08:22:05 avmike:ESDE.2020: NO waiting connections
2020-01-15 08:37:09 avmike:ESDE.2020: Warning: source changed from IP.der.ES.box:18494 to IP.der.ES.box:18483
2020-01-15 08:37:09 avmike:<<< 4500 quickmode[IP.der.ES.box:18483] ESDE.2020: V1.0 2332 IC e1970a4976a742d1 RC 1d6ce628b2976484 7b257f63 HASH flags=e
2020-01-15 08:37:09 avmike:>>> quickmode 4500[IP.der.ES.box:18483] ESDE.2020: V1.0 380 IC e1970a4976a742d1 RC 1d6ce628b2976484 7b257f63 HASH flags=e
2020-01-15 08:37:09 avmike:ESDE.2020: Warning: source changed from IP.der.ES.box:18494 to IP.der.ES.box:18483
2020-01-15 08:37:09 avmike:<<< 4500 quickmode[IP.der.ES.box:18483] ESDE.2020: V1.0 108 IC e1970a4976a742d1 RC 1d6ce628b2976484 7b257f63 HASH flags=e
2020-01-15 08:37:09 avmike:ESDE.2020: Phase 2 ready
2020-01-15 08:37:09 avmike:NEW Phase 2 SA: ESP-AES-256/SHA2-512 SPI: 6FC75081 LT: 3600 I/O: IN
2020-01-15 08:37:09 avmike:NEW Phase 2 SA: ESP-AES-256/SHA2-512 SPI: C62FC8A5 LT: 3600 I/O: OUT
2020-01-15 08:37:09 avmike:NEW Phase 2 SA: IPComp-LZJH SPI: 2740 LT: 3600 I/O: IN
2020-01-15 08:37:09 avmike:NEW Phase 2 SA: IPComp-LZJH SPI: AF0E LT: 3600 I/O: OUT
2020-01-15 08:37:09 avmike:< cb_sa_created(name=ESDE.2020,id=6,...,flags=0x00032003)
2020-01-15 08:37:09 avmike:ESDE.2020: start waiting connections
2020-01-15 08:37:09 avmike:ESDE.2020: NO waiting connections
2020-01-15 08:37:19 avmike:>>>4500 nat-t-keepalive[IP.der.ES.box:18483]
2020-01-15 08:45:16 avmike:>r> infomode 4500[IP.der.ES.box:18494] ESDE.2020: V1.0 140 IC e1970a4976a742d1 RC 1d6ce628b2976484 99255f89 HASH flags=e
2020-01-15 08:45:23 avmike:>r> infomode 4500[IP.der.ES.box:18494] ESDE.2020: V1.0 140 IC e1970a4976a742d1 RC 1d6ce628b2976484 d61a6100 HASH flags=e
2020-01-15 08:45:31 avmike:>r> infomode 4500[IP.der.ES.box:18494] ESDE.2020: V1.0 140 IC e1970a4976a742d1 RC 1d6ce628b2976484 dda4a24 HASH flags=e
2020-01-15 08:45:47 avmike:< delete_sa(appl=dsld,cname=ESDE.2020,id=0,what=3,reason=Dead Peer Detection)
2020-01-15 08:45:47 avmike:>r> infomode 4500[IP.der.ES.box:18494] ESDE.2020: V1.0 124 IC e1970a4976a742d1 RC 1d6ce628b2976484 a1809cd0 HASH flags=e
2020-01-15 08:45:47 avmike:FreeIPsecSA: spi=6FC75081        protocol=3 iotype=1
2020-01-15 08:45:47 avmike:>r> infomode 4500[IP.der.ES.box:18494] ESDE.2020: V1.0 124 IC e1970a4976a742d1 RC 1d6ce628b2976484 7746e0b4 HASH flags=e
2020-01-15 08:45:47 avmike:FreeIPsecSA: spi=2740        protocol=4 iotype=1
2020-01-15 08:45:47 avmike:>r> infomode 4500[IP.der.ES.box:18494] ESDE.2020: V1.0 124 IC e1970a4976a742d1 RC 1d6ce628b2976484 17f8d815 HASH flags=e
2020-01-15 08:45:47 avmike:FreeIPsecSA: spi=C62FC8A5        protocol=3 iotype=2
2020-01-15 08:45:47 avmike:>r> infomode 4500[IP.der.ES.box:18494] ESDE.2020: V1.0 124 IC e1970a4976a742d1 RC 1d6ce628b2976484 67846ba5 HASH flags=e
2020-01-15 08:45:47 avmike:FreeIPsecSA: spi=AF0E        protocol=4 iotype=2
2020-01-15 08:45:47 avmike:>r> infomode 4500[IP.der.ES.box:18494] ESDE.2020: V1.0 124 IC e1970a4976a742d1 RC 1d6ce628b2976484 c5c07fd5 HASH flags=e
2020-01-15 08:45:47 avmike:ESDE.2020: del phase 1 SA 6
2020-01-15 08:46:19 avmike:< create_sa(appl=dsld,cname=ESDE.2020)
2020-01-15 08:46:19 avmike:ESDE.2020: Phase 1 starting
2020-01-15 08:46:19 avmike:>>> aggressive mode [IP.der.ES.box] ESDE.2020: V1.0 720 IC 5f3394534d87d052 RC 00000000 0000 SA flags=
2020-01-15 08:46:21 avmike:>r> aggressive mode [IP.der.ES.box] ESDE.2020: V1.0 720 IC 5f3394534d87d052 RC 00000000 0000 SA flags=
2020-01-15 08:46:25 avmike:>r> aggressive mode [IP.der.ES.box] ESDE.2020: V1.0 720 IC 5f3394534d87d052 RC 00000000 0000 SA flags=
2020-01-15 08:46:33 avmike:ESDE.2020: Phase 1 failed (initiator): IKE-Error 0x2027
2020-01-15 08:46:33 avmike:< cb_sa_create_failed(name=ESDE.2020,reason=IKE-Error 0x2027)

VPN assocs
----------
/proc/kdsld/dsliface/internet/ipsec/assocs:
MK_IOS: IP.der.DE.box:0.0.0.0 0.0.0.0:192.168.50.202 0 SAs  valid enabled dynlocalip dynremoteip
    permit ip 192.168.0.0 255.255.255.0 host 192.168.50.202
    permit ip 192.168.50.0 255.255.255.0 host 192.168.50.202
    Forbidden Clients: 192.168.179.0/24
MK_Vaio: IP.der.DE.box:0.0.0.0 0.0.0.0:192.168.50.201 0 SAs  valid enabled dynlocalip dynremoteip
    permit ip 192.168.0.0 255.255.255.0 host 192.168.50.201
    permit ip 192.168.50.0 255.255.255.0 host 192.168.50.201
    Forbidden Clients: 192.168.179.0/24
ESDE.2020: IP.der.DE.box:0.0.0.0 IP.der.ES.box:0.0.0.0 0 SAs  valid enabled dynlocalip dynremoteip
    permit ip any 192.168.0.0 255.255.255.0
    permit ip any 192.168.50.0 255.255.255.0
    Forbidden Clients: 192.168.179.0/24

VPN connections
----------
/proc/kdsld/dsliface/internet/ipsec/connections:
MK_IOS: pmtu 0 mtu 1492 dont_filter_netbios
MK_Vaio: pmtu 0 mtu 1492 dont_filter_netbios
ESDE.2020: pmtu 0 mtu 1492 dpd_supported dont_filter_netbios local_nat remote_nat

##### END SECTION vpn

Da war noch permit ip any 192.168.0.0 255.255.255.0 aktiv; habe ich jetzt rausgenommen, aber das hat bislang auch nichts gebracht:

VPN avmike
-------
-rw-r--r--    1 root     root         11259 Jan 15 10:41 /var/tmp/ike.log
-rw-r--r--    1 root     root         20554 Jan 15 10:30 /var/tmp/ike.old
[...]
2020-01-15 10:35:10 avmike:<<< 4500 infomode[IP.der.ES.box:18483] ???: V1.0 140 IC 5477129573d8b581 RC 9881d338b504615e 91504fe HASH flags=e
2020-01-15 10:35:10 avmike:<<< 4500 quickmode[IP.der.ES.box:18483] ???: V1.0 2332 IC 5477129573d8b581 RC 9881d338b504615e e24ba1ca HASH flags=e
2020-01-15 10:35:10 avmike:IP.der.ES.box:18483: quickmode: no neighbour: V1.0 2332 IC 5477129573d8b581 RC 9881d338b504615e e24ba1ca HASH flags=e
2020-01-15 10:35:12 avmike:<<< 4500 quickmode[IP.der.ES.box:18483] ???: V1.0 2332 IC 5477129573d8b581 RC 9881d338b504615e e24ba1ca HASH flags=e
2020-01-15 10:35:12 avmike:IP.der.ES.box:18483: quickmode: no neighbour: V1.0 2332 IC 5477129573d8b581 RC 9881d338b504615e e24ba1ca HASH flags=e
2020-01-15 10:35:15 avmike:<<< 4500 infomode[IP.der.ES.box:18483] ???: V1.0 140 IC 5477129573d8b581 RC 9881d338b504615e 5faf0b34 HASH flags=e
2020-01-15 10:35:16 avmike:<<< 4500 quickmode[IP.der.ES.box:18483] ???: V1.0 2332 IC 5477129573d8b581 RC 9881d338b504615e e24ba1ca HASH flags=e
2020-01-15 10:35:16 avmike:IP.der.ES.box:18483: quickmode: no neighbour: V1.0 2332 IC 5477129573d8b581 RC 9881d338b504615e e24ba1ca HASH flags=e
2020-01-15 10:35:20 avmike:<<< 4500 infomode[IP.der.ES.box:18483] ???: V1.0 140 IC 5477129573d8b581 RC 9881d338b504615e 19fab0f HASH flags=e
2020-01-15 10:35:24 avmike:<<< 4500 infomode[IP.der.ES.box:18483] ???: V1.0 124 IC 5477129573d8b581 RC 9881d338b504615e a5879ee4 HASH flags=e
2020-01-15 10:35:24 avmike:<<< 4500 aggressive mode[IP.der.ES.box:18483] ???: V1.0 720 IC 8ead8cc33bdd1d9 RC 00000000 0000 SA flags=
2020-01-15 10:35:24 avmike:aggressive mode ESDE.2020: selected lifetime: 3600 sec(no notify)
2020-01-15 10:35:24 avmike:ESDE.2020 receive VENDOR ID Payload: XAUTH
2020-01-15 10:35:24 avmike:ESDE.2020 receive VENDOR ID Payload: DPD
2020-01-15 10:35:24 avmike:ESDE.2020 receive VENDOR ID Payload: NAT-T RFC 3947
2020-01-15 10:35:25 avmike:ESDE.2020: add phase 1 SA: DH2/AES-256/SHA2-512/3600sec id:1
2020-01-15 10:35:25 avmike:>>> aggressive mode 4500[IP.der.ES.box:18483] ESDE.2020: V1.0 588 IC 8ead8cc33bdd1d9 RC d8e820e8564ee92 0000 SA flags=
2020-01-15 10:35:25 avmike:ESDE.2020: Warning: source changed from 0.0.0.0:500 to IP.der.ES.box:18483
2020-01-15 10:35:25 avmike:<<< 4500 aggressive mode[IP.der.ES.box:18483] ESDE.2020: V1.0 236 IC 8ead8cc33bdd1d9 RC d8e820e8564ee92 0000 HASH flags=e
2020-01-15 10:35:25 avmike:ESDE.2020: Phase 1 ready
2020-01-15 10:35:25 avmike:ESDE.2020: current=0.0.0.0 new=IP.der.ES.box:18483
2020-01-15 10:35:25 avmike:ESDE.2020: local is behind a nat
2020-01-15 10:35:25 avmike:ESDE.2020: remote is behind a nat
2020-01-15 10:35:25 avmike:ESDE.2020: sending initial contact message
2020-01-15 10:35:25 avmike:>r> infomode 4500[IP.der.ES.box:18483] ESDE.2020: V1.0 124 IC 8ead8cc33bdd1d9 RC d8e820e8564ee92 36755955 HASH flags=e
2020-01-15 10:35:25 avmike:ESDE.2020: start waiting connections
2020-01-15 10:35:25 avmike:ESDE.2020: NO waiting connections
2020-01-15 10:35:25 avmike:<<< 4500 infomode[IP.der.ES.box:18483] ESDE.2020: V1.0 124 IC 8ead8cc33bdd1d9 RC d8e820e8564ee92 f2f316d3 HASH flags=e
2020-01-15 10:35:25 avmike:<<< 4500 infomode[IP.der.ES.box:18483] ESDE.2020: V1.0 124 IC 8ead8cc33bdd1d9 RC d8e820e8564ee92 4ff817b0 HASH flags=e
2020-01-15 10:35:25 avmike:<<< 4500 infomode[IP.der.ES.box:18483] ESDE.2020: V1.0 124 IC 8ead8cc33bdd1d9 RC d8e820e8564ee92 ec18eec6 HASH flags=e
2020-01-15 10:35:25 avmike:<<< 4500 infomode[IP.der.ES.box:18483] ESDE.2020: V1.0 124 IC 8ead8cc33bdd1d9 RC d8e820e8564ee92 827437ec HASH flags=e
2020-01-15 10:35:25 avmike:<<< 4500 infomode[IP.der.ES.box:18483] ESDE.2020: V1.0 124 IC 8ead8cc33bdd1d9 RC d8e820e8564ee92 76c90862 HASH flags=e
2020-01-15 10:35:25 avmike:ESDE.2020: del phase 1 SA 1
2020-01-15 10:35:25 avmike:<<<  aggressive mode[IP.der.ES.box:18486] ???: V1.0 720 IC 88c10b69a54f276b RC 00000000 0000 SA flags=
2020-01-15 10:35:25 avmike:aggressive mode ESDE.2020: selected lifetime: 3600 sec(no notify)
2020-01-15 10:35:25 avmike:ESDE.2020 receive VENDOR ID Payload: XAUTH
2020-01-15 10:35:25 avmike:ESDE.2020 receive VENDOR ID Payload: DPD
2020-01-15 10:35:25 avmike:ESDE.2020 receive VENDOR ID Payload: NAT-T RFC 3947
2020-01-15 10:35:26 avmike:ESDE.2020: add phase 1 SA: DH2/AES-256/SHA2-512/3600sec id:2
2020-01-15 10:35:26 avmike:>>> aggressive mode [IP.der.ES.box:18486] ESDE.2020: V1.0 588 IC 88c10b69a54f276b RC e10774d84e39e863 0000 SA flags=
2020-01-15 10:35:26 avmike:<<< 4500 aggressive mode[IP.der.ES.box:18483] ESDE.2020: V1.0 268 IC 88c10b69a54f276b RC e10774d84e39e863 0000 HASH flags=e
2020-01-15 10:35:26 avmike:ESDE.2020: switching to NAT-T (Responder)
2020-01-15 10:35:26 avmike:ESDE.2020: embedded inital contact message received
2020-01-15 10:35:26 avmike:ESDE.2020: inital contact message ignored
2020-01-15 10:35:26 avmike:ESDE.2020: Phase 1 ready
2020-01-15 10:35:26 avmike:ESDE.2020: current=IP.der.ES.box:18483 new=IP.der.ES.box:18483
2020-01-15 10:35:26 avmike:ESDE.2020: remote is behind a nat
2020-01-15 10:35:26 avmike:ESDE.2020: start waiting connections
2020-01-15 10:35:26 avmike:ESDE.2020: NO waiting connections
2020-01-15 10:35:26 avmike:<<< 4500 quickmode[IP.der.ES.box:18483] ESDE.2020: V1.0 2332 IC 88c10b69a54f276b RC e10774d84e39e863 56a53a93 HASH flags=e
2020-01-15 10:35:26 avmike:>>> quickmode 4500[IP.der.ES.box:18483] ESDE.2020: V1.0 380 IC 88c10b69a54f276b RC e10774d84e39e863 56a53a93 HASH flags=e
2020-01-15 10:35:27 avmike:<<< 4500 quickmode[IP.der.ES.box:18483] ESDE.2020: V1.0 108 IC 88c10b69a54f276b RC e10774d84e39e863 56a53a93 HASH flags=e
2020-01-15 10:35:27 avmike:ESDE.2020: Phase 2 ready
2020-01-15 10:35:27 avmike:NEW Phase 2 SA: ESP-AES-256/SHA2-512 SPI: 10F8711D LT: 3600 I/O: IN
2020-01-15 10:35:27 avmike:NEW Phase 2 SA: ESP-AES-256/SHA2-512 SPI: 10B53791 LT: 3600 I/O: OUT
2020-01-15 10:35:27 avmike:NEW Phase 2 SA: IPComp-LZJH SPI: 72E1 LT: 3600 I/O: IN
2020-01-15 10:35:27 avmike:NEW Phase 2 SA: IPComp-LZJH SPI: 583F LT: 3600 I/O: OUT
2020-01-15 10:35:27 avmike:< cb_sa_created(name=ESDE.2020,id=1,...,flags=0x00022003)
2020-01-15 10:35:27 avmike:ESDE.2020: start waiting connections
2020-01-15 10:35:27 avmike:ESDE.2020: NO waiting connections
2020-01-15 10:41:15 avmike:<<< 4500 infomode[109.193.16.64:64488] MK_Vaio: V1.0 92 IC fb29163fd415a91e RC e07ec04170cbdd15 60bbd6d6 HASH flags=e
2020-01-15 10:41:15 avmike:>r> infomode 4500[109.193.16.64:64488] MK_Vaio: V1.0 92 IC fb29163fd415a91e RC e07ec04170cbdd15 60bbd6d6 HASH flags=e
2020-01-15 10:41:25 avmike:<<< 4500 infomode[109.193.16.64:64488] MK_Vaio: V1.0 92 IC fb29163fd415a91e RC e07ec04170cbdd15 98ca44a8 HASH flags=e
2020-01-15 10:41:25 avmike:>r> infomode 4500[109.193.16.64:64488] MK_Vaio: V1.0 92 IC fb29163fd415a91e RC e07ec04170cbdd15 98ca44a8 HASH flags=e

VPN assocs
----------
/proc/kdsld/dsliface/internet/ipsec/assocs:
MK_IOS: IP.der.DE.box:0.0.0.0 0.0.0.0:192.168.50.202 0 SAs  valid enabled dynlocalip dynremoteip
    permit ip 192.168.0.0 255.255.255.0 host 192.168.50.202
    permit ip 192.168.50.0 255.255.255.0 host 192.168.50.202
    Forbidden Clients: 192.168.179.0/24
MK_Vaio: IP.der.DE.box:0.0.0.0 109.193.16.64:192.168.50.201 1 SAs  valid enabled dynlocalip dynremoteip
    permit ip 192.168.0.0 255.255.255.0 host 192.168.50.201
    permit ip 192.168.50.0 255.255.255.0 host 192.168.50.201
    Forbidden Clients: 192.168.179.0/24
ESDE.2020: IP.der.DE.box:0.0.0.0 IP.der.ES.box:0.0.0.0 1 SAs  valid enabled dynlocalip dynremoteip
    permit ip any 192.168.50.0 255.255.255.0
    Forbidden Clients: 192.168.179.0/24

VPN connections
----------
/proc/kdsld/dsliface/internet/ipsec/connections:
MK_IOS: pmtu 0 mtu 1492 dont_filter_netbios
MK_Vaio: pmtu 0 mtu 1492 dpd_supported dont_filter_netbios remote_nat
ESDE.2020: pmtu 0 mtu 1492 dpd_supported dont_filter_netbios remote_nat

##### END SECTION vpn

Ich hoffe, das alles sagt euch mehr als mir. Ich kann mir nur zusammenreimen, dass die DE-Box unter der IP der ES-Box einen "neighbour" sucht und nicht findet?
Status ist jedenfalls, dass der Tunnel steht (grüner Punkt), aber kein Zugriff auf ES möglich ist (

 

[Micha0815]

Richte doch für diese Zeit den Zugriff via MyFRITZ-Internetzugang ein.

So ganz verkehrt war die generelle Überlegung nicht, da der E3372h wohl auch IPv6 versteht. (Guckst Du hier und hier) Es ist eher fraglich, ob Vodafone-Spanien IPv6 in seinen Mobilfunknetzen als Verbindungsmöglichkeit anbietet? Der bei Docmarten z.Zt. angeklemmte, voicefähige Stick kann sicherlich nur -für VPN notwendiges- IPv4 und aus der Ferne wird es wohl nie so einfach möglich sein, eine IPv4-Verbindung auf IPv6 umzustellen.
LG

 

[PeterPawn]

Ich weiß zwar nicht, was AVM am Ende konkret geändert hat, um die Zusage zu erfüllen, das würde jetzt auch alles mit nur einer öffentlichen IP funktionieren ... auch die gezeigten Protokolle geben da nicht viel her an Ideen diesbezüglich.

Wenn da um 06:44 Uhr eine neue SA für ES eingerichtet wird (btw ... man bräuchte eigentlich die Protokolle von beiden Seiten - vermutlich konfiguriert man das deshalb auch nicht erst dann richtig, wenn man auf die eine Seite nicht mehr vernünftig zugreifen kann, sondern solange man sich dort vor Ort befindet) mit der ID 4, dann stellt sich ja die Frage, wozu es die neue eingehende Verbindung von ES (so interpretiere ich das Protokoll jedenfalls ... "Pfeile" nach links sind ankommender Verkehr, nach rechts dann abgehend) um 07.28 Uhr wohl dienen soll.

Da muß dann ja die Box in ES irgendwie der Ansicht gewesen sein, der Tunnel wäre nicht mehr verfügbar und sie müsse ihn nun erneut aufbauen ... davon steht aber in der Box in DE zumindest mal nichts im Event-Log, denn diese ist ja offenbar der Ansicht, daß der Tunnel seit 03:52 Uhr bestünde und regelmäßig erneuert wurde (sonst wäre "DPD" als Fehlerursache um 08:04 Uhr ja Unsinn).

Warum dann die Box in DE ihrerseits um 08:04 Uhr annimmt, sie könne dann eben selbst eine Verbindung zur Box in ES aufbauen (und das offenbar auch noch genau zur Adresse des CGN-Gateways, wenn da beim Ändern des Protokolls nicht nur die Port-Nummer unter die Räder gekommen ist), obwohl sie doch nach Ansicht der Konfigurationsdatei gar keine Idee haben sollte, wo sich der Peer finden ließe (wenn weder "remoteip" noch "remotehostname" definiert sind), weiß ich auch nicht ... vielleicht ist das ja eine der wundersamen Auswirkungen der Änderungen seitens AVM.

Ich bin also raus ... gestatte mir aber trotzdem noch zwei Bemerkungen/Fragen:

- Warum muß man hier die IP-Adresse der Box in ES überhaupt "anonymisieren"? Wenn die keine öffentlich erreichbare Adresse hat und schon der IPSec-Tunnel immer mit wechselnder Portnummer am Provider-CGN auftaucht, dann kann ohnehin niemand mit diesen Informationen irgendeine eingehende Verbindung erzeugen ... außer zusätzlicher Verwirrung und Unsicherheit beim Leser, ob da nicht am Ende beim Bearbeiten der Protokolldatei irgendwelche zusätzlichen Fehler eingebaut wurden, erreicht man mit solchen Veränderungen also rein gar nichts.

- Dasselbe gilt m.E. für die Adresse(n) des DSL-Anschlusses in Deutschland ... hier gäbe es nur eine (sehr selten anzutreffende) Ausnahme, die solch eine Aktion begründen könnte ... nämlich ein DSL-Anschluß, wo bei jedem Aufbau einer Internet-Verbindung immer wieder dieselbe öffentliche IPv4-Adresse verwendet wird und auch ein "Neu verbinden" im GUI der Box daran nichts ändert. In so einem Falle mag das "Maskieren" der Daten einen Sinn ergeben, in allen anderen ist es Unfug und führt zu demselben Ergebnis (Unlesbarkeit und Zweifel an fehlerfreier Arbeit bei ebendiesem Maskieren), wie im Falle der ES-Adresse oben.

Wer sich an die bisher abgegebenen Empfehlungen zum Aufbau einer eigenen VPN-Konfiguration hält, der kann sogar die IDs für P1 problemlos "im Original" lassen, weil sie dann eben genau keine "echten" FQDN für irgendeinen Anschluß darstellen. Wer hier jedoch wieder hingeht und einfach seine DynDNS-Adressen verwendet (und zwar schon in seiner "vpn.cfg" und ohne diese Verwendung gäbe es wieder gar keine Notwendigkeit, diese ID im Protokoll zu ändern - nur die DynDNS-Adresse der Box in D ist hier etwas, was tatsächlich "statisch" ist und irgendeiner Maskierung bedarf), der eröffnet auch der (bisher eben nicht genau erkundeten) Arbeitsweise des AVM-VPN nach der verkündeten Änderung wieder neue Möglichkeiten, wenn sich eben so eine P1-ID am Ende doch wieder per DNS zu einer IPv4-Adresse auflösen läßt.

Ohne solche Informationen (oder ohne die Annahme, daß im AVM-VPN am Ende dann doch ein dicker Bug steckt, der mit der Änderung Einzug gehalten hat) ist es jedenfalls kaum zu erklären, wieso die Box in D nach dem oben stehenden Protokoll ab 08:04:54 Uhr auf die Idee kommt, ihrerseits ausgehend eine VPN-Verbindung zur "[IP.der.ES.box]" aufbauen zu wollen ... und zwar ohne die Verwendung der (bisher bekannten) Port-Nummer der "outgoing connection" am CGN-Gateway des LTE-Providers.

Bestimmt gibt es irgendwo in diesem Thread auch noch die aktuelle Info, was da jetzt für FRITZ!Box-Modelle mit welcher FRITZ!OS-Version verwendet werden ... nur sollte man es als Hilfesuchender den Antwortwilligen dann auch seinerseits leicht(er) machen und solche Informationen (selbst wenn es "irgendwo" schon stehen sollte) immer noch dazuschreiben. Niemand (der nur seine Hilfe anbietet und seinerseits kein eigenes Problem hat) will erst die ganzen vorhergehenden Seiten auf der Suche nach diesen (Basis-)Informationen abgrasen - und ein kurzer Abschnitt mit den "Fakten" (Modell, Version, IP-Adressen, Internet-Anschluß/-Provider) als Zusammenfassung ist jetzt auch nicht sooo redundant, daß sich irgendjemand (ernsthaft) über "Wiederholungen" aufregen dürfte (oder er begreift den Sinn solcher Informationen dann ohnehin nicht).

===============================================================

Aber/denn auch hier kann das "Vermischen" der Daten aus verschiedenen Quellen oder von verschiedenen Zeitpunkten (im schlechtesten Falle noch kombiniert mit "menschlichem Versagen" beim Maskieren) zu vollkommen falschen Schlußfolgerungen führen ... deshalb auch immer wieder meine (früher desöfteren, heute nur noch sehr selten) zum Ausdruck gebrachte Überzeugung, daß zu einer "ordentlichen Analyse" bei VPN-Problemen immer die Konfiguration (und zwar die aktuell verwendete und nicht irgendeine alte, deren Veränderungen nur in Prosa beschrieben wurden) gehört, ebenso das aktuelle (und zeitgleich zum Peer laufende) Protokoll des "avmike", genauso wie die passenden Eventlog-Messages ... und das obendrein eben noch von beiden Peers und unter der "Bedingung", daß zuvor beide Seiten auch neu gestartet wurden (im Minimum der "avmike", was aber ohne Telnet-Zugriff auf einen Restart der Box hinausläuft), damit man in den Protokollen auch das "Einrichten" der jeweils definierten Verbindungen sieht.

Solange es sich nicht um ein Problem aus der Zusammenarbeit verschiedener VPN-Konfigurationen auf einer einzelnen Box handelt, haben andere VPN-Definitionen mit dem Problem auch nichts zu tun und sind - tunlichst - zu entfernen oder zumindest zu deaktivieren, damit sie keinesfalls in die Protokollierung eingreifen und sei es nur dadurch, daß sie eine aufsteigende "Nummerierung" (z.B. die IDs der SAs) durcheinanderbringen und für den Leser der Protokoll-Datei (wenn/falls der "Editor" sie seinerseits schon ausgefiltert hat beim "Maskieren") das Ganze noch undurchsichtiger machen.

Das oben Geschriebene (zum "kompletten Umfang" der Infos) kann man dann auch als Begründung meinerseits verstehen, warum ich mich hier rausmische ... ich halte es für wenig zielführend (bzw. für Verschwendung von wertvoller Zeit), eine Diagnose einer solchen VPN-Verbindung ausführen zu wollen, wenn man gar keine (funktionierende) Zugriffsmöglichkeit auf den Peer hat. Das wäre die Aufgabe gewesen, solange man dort vor Ort war ... nunmehr wieder in D angekommen, ist es in meinen Augen dafür zu spät und man muß eben warten, bis sich die nächste Gelegenheit ergibt. Aber das ist nur meine persönliche Ansicht ... ich werde den Fortgang gespannt verfolgen und wünsche Dir meinerseits viel Erfolg, auch wenn ich nicht so recht daran glauben mag, daß es am Ende (von D aus) gelingt.

Aber man kann die Zeit bis zu einer solchen Gelegenheit ja auch hier in D nutzen (wie Du Dich vielleicht erinnerst, hatte ich Dir schon beim ersten Anlauf empfohlen, das Ganze zunächst mal hier in D aufzubauen und dann erst - wenn es auch funktioniert - nach ES zu bringen bzw. zu übertragen), um sich eine funktionierende Umgebung mit einer anderen FRITZ!Box aufzubauen, die man dann nur noch "exportieren" muß (Hard- und Software natürlich in diesem Falle) oder ggf. sogar (nach Klärung aller anstehenden Probleme) direkt auf die Konfiguration der derzeit verwendeten Boxen "anwenden" kann.

PS: Man kriegt die IKE-Protokolle meines Wissens auch mit JEDER Support-Datei einer FRITZ!Box - dazu braucht es - anders als oben angetextet - auch nicht das erweiterte Format. Dieses umfaßt (bisher) lediglich die kompletten Konfigurationsinformationen der betreffenden Box (zusätzlich zum "normalen" Inhalt), da diese in dem dann eingeschlossenen Dump der TFFS-Partition(en) abgelegt sind bzw. sich mit den dort enthaltenen Infos auch komplett entschlüsseln lassen (also inkl. aller Kennwörter u.ä.).

 

[Docmarten]

gestatte mir aber trotzdem noch zwei Bemerkungen/Fragen:

- Warum muß man hier die IP-Adresse der Box in ES überhaupt "anonymisieren"? Wenn die keine öffentlich erreichbare Adresse hat und schon der IPSec-Tunnel immer mit wechselnder Portnummer am Provider-CGN auftaucht, dann kann ohnehin niemand mit diesen Informationen irgendeine eingehende Verbindung erzeugen ... außer zusätzlicher Verwirrung und Unsicherheit beim Leser, ob da nicht am Ende beim Bearbeiten der Protokolldatei irgendwelche zusätzlichen Fehler eingebaut wurden, erreicht man mit solchen Veränderungen also rein gar nichts.

Frage der Gewohnheit, nachdem ich andernorts schon öfter zusammengefaltet wurde, wenn ich bloß veröffentlichte, dass die IPs meines Heimnetzes mit 1 beginnen... Da ich sorgfältig vorgehe und nur per S&R in Notepad+ maskiere, gehe ich nicht davon aus, dass zusätzliche Fehler reinkommen. Vermutlich hast Du aber recht, nur kann ich das nicht in jedem Einzelfall sicher beurteilen, daher vorsichtshalber...

- Dasselbe gilt m.E. für die Adresse(n) des DSL-Anschlusses in Deutschland ... hier gäbe es nur eine (sehr selten anzutreffende) Ausnahme, die solch eine Aktion begründen könnte ... nämlich ein DSL-Anschluß, wo bei jedem Aufbau einer Internet-Verbindung immer wieder dieselbe öffentliche IPv4-Adresse verwendet wird und auch ein "Neu verbinden" im GUI der Box daran nichts ändert. In so einem Falle mag das "Maskieren" der Daten einen Sinn ergeben, in allen anderen ist es Unfug und führt zu demselben Ergebnis (Unlesbarkeit und Zweifel an fehlerfreier Arbeit bei ebendiesem Maskieren), wie im Falle der ES-Adresse oben.

Stimmt. Allerdings habe ich an einer Box (Büronetz, von der aus im Protokoll, s.u., die MK_VAIO-Verbindung aufgebaut wird, in der Tat eine feste IP (die allerdings just heute, nach Vertragsumstellung bei Unity, geändert wurde ).

der kann sogar die IDs für P1 problemlos "im Original" lassen,

Was ist P1? Phase 1?

weil sie dann eben genau keine "echten" FQDN für irgendeinen Anschluß darstellen. Wer hier jedoch wieder hingeht und einfach seine DynDNS-Adressen verwendet (und zwar schon in seiner "vpn.cfg" und ohne diese Verwendung gäbe es wieder gar keine Notwendigkeit, diese ID im Protokoll zu ändern - nur die DynDNS-Adresse der Box in D ist hier etwas, was tatsächlich "statisch" ist und irgendeiner Maskierung bedarf), der eröffnet auch der (bisher eben nicht genau erkundeten) Arbeitsweise des AVM-VPN nach der verkündeten Änderung wieder neue Möglichkeiten, wenn sich eben so eine P1-ID am Ende doch wieder per DNS zu einer IPv4-Adresse auflösen läßt.

Ich nutze die myfritz-Adressen nur bei fqdn in den Configs beider Boxen, weil es irgendwo hier mal hieß, dass das egal sei (ich glaube, dass Du das meintest?) Eventuell doch ein Problem und in der DE-Box Fantasienamen einsetzen? Ich meine, das hätte ich aber auch schonmal ohne Erfolg ausprobiert.

Bestimmt gibt es irgendwo in diesem Thread auch noch die aktuelle Info, was da jetzt für FRITZ!Box-Modelle mit welcher FRITZ!OS-Version verwendet werden ... nur sollte man es als Hilfesuchender den Antwortwilligen dann auch seinerseits leicht(er) machen.

Da hast Du Recht:
DE:
7490
seit gestern mit FRITZ!OS: 07.19-74610 BETA, davor (also auch zum Zeitpunkt des vorigen Posts) mit der aktuellen regulären Firmware

ES:
7490
7490 (internationale Version)
FritzOS 7.12
Huawei E1752C verbunden mit HDSPA

ich halte es für wenig zielführend (bzw. für Verschwendung von wertvoller Zeit), eine Diagnose einer solchen VPN-Verbindung ausführen zu wollen, wenn man gar keine (funktionierende) Zugriffsmöglichkeit auf den Peer hat.

Ich habe ja funktionierenden Zugriff auf den Peer, nur halt nicht immer. Es klappt eine Weile, dann bricht die Verindung ab, und mal dauert es kürzer (15 Minuten), mal länger (> 1h) bis sie wieder steht. Es ist mir aber gestern gelungen, nach einem Cut die Supportdateien von beiden Boxen zu ziehen, s.u.

Das wäre die Aufgabe gewesen, solange man dort vor Ort war ... nunmehr wieder in D angekommen, ist es in meinen Augen dafür zu spät und man muß eben warten, bis sich die nächste Gelegenheit ergibt.

Wie beschrieben war ich vor Ort felsenfest überzeugt (bzw. hatte keinerlei Grund, das Gegenteil anzunehmen), dass die Verbindung stand. Dafür hatte ich mehrmals über das Smartphone bei ausgeschaltetem WLAN einen Tunnel zur DE-Box aufgebaut und dann IPs aus dem ES-Netz getestet, wass immer einwandfrei funktionierte. Der erste Aussetzer kam beim Warten am Flughafen auf den Rückflug...

Hier die Dateien von den gestrigen Ausfällen.
Viele Grüße
Martin

Edit: Typos und Zitierung korrigiert

 

[Micha0815]

Ich möchte nicht unken,

 2020-01-16 12:54:06 avmike:ESDE.2020: local is behind a nat
2020-01-16 12:54:06 avmike:ESDE.2020: remote is behind a nat

liest sich, als ob Dein 1und1-Anschluss mit DS-Lite arbeitet? Ich hatte stets die Büro-6490 am Kabelanschluss mit öffentlicher IPv4 im Hinterkopf als Responder?
LG

 

[Docmarten]

Nein, das war schon immer die 1und1-Box am DSL, Büro ist nur der Fernzugrif auf diese.
DS-LITE? Hmm... wäre mir nichts davon bekannt. Woran kann man das noch erkennen? Die Box sagt:

DSL-Version: 1.100.136.39 VDSL2 17a (ITU G.993.2) Line-ID: 1UND1.DEU.DTAG.E0PQK

 

[Micha0815]

https://ipv6-test.com/ sollte dies anzeigen iirc.

Büro ist nur der Fernzugrif auf diese

Wenn die Büro-FB auch via LAN2LAN verbunden ist ... dann solltest Du diese mal deaktivieren (u.U. auf beiden Seiten).
LG

 

[Docmarten]

Nein, die ist per User-Verbindung verbunden. Aber auch wenn die gekappt ist (d.h. nach Feierabend, wenn ich @Home bin), halten die Abbrüche unverändert an. Sollte also nichts damit zu tun haben?

 

[Micha0815]

Iirc kannst Du ja versuchen, über den VDF.es-Account-Cliente nachschauen, ob Deine ES-SIM syncron zu Deinem DE-Zugriff Traffic im Mobilnetz hat/produziert. Wenn Du schreibst, dass Du dort eine Sipgate-Nummer registriert hast, sollte diese auch -u.U. zumindest marginal- Traffic produzieren, auch wenn die VPN-Verbindung unterbrochen ist?
So liesse sich zumindest abschätzen aus der Ferne, dass der Stick/die Mobilfunkverbindung kontinuierlich steht.
Du erwähntest auch mal Web-Cams zw. Überwachung? Da sollte man auch bei div. Modellen u.U. das (heimliche?) Cloud-Verbinden -ggfs. als VPN- im Hinterkopf behalten, da es eher unbekannt ist, wie AVM die Wichtung/Prioritäten bei einer Mobilfunkverbindung und interner VPN->SIP->FB-Clients hierarchisch aufbaut, wenn es mit der Bandbreite eng wird.
Da die SIP-Telefonie/-Registrierung wohl oberste Priorität hat -zumindest wurde da dran gedreht, als seinerzeit VPN bei Vollast die Telefonie in die Knie zwang- empfahl ich nicht ohne Grund stets ein IP-Telefon mit permanenter interner SIP-Registrierung über die VPN-Verbindung anzustreben.
Sollten die VPN-Experten mit/bei aktueller FW 7.19-* andere Ansichten vertreten, lasse ich mich gerne eines Besseren belehren
LG

 

[Docmarten]

Hallo zusammen,
meine Pläne zur Fortführung der Fehlersuche in situ haben sich ja aus bekannten Gründen leider nicht realisieren lassen. Dennoch mal ein Zwischenstand:
Die Situation ist unverändert, trotz der vom AVM Support empfohlenen Updates beider Boxen auf die Laborversion. Ich habe dann auch mal offiziel beim AVM-Support wegen des Problems angefragt und sämtliche erforderlichen Daten mehrmals übermittelt.
Nach einigen ersten irrtümlichen Diagnosen (DSL-Verbindung schlecht) und zahlreichen Mails in beide Richtungen ist der Stand nun, dass man bei AVM eine schlechte/instabile Internetverbindung entweder bei der ES-Box oder bei der DE-Box vermutet:

Erfahrungsgemäß ist das sporadisch und zeitlich begrenzte Auftreten des VPN-Fehlers 0x2027 auf einen nicht konstanten Internetzugang zurückzuführen, wobei mit nicht konstant auch ein zu niedriger Datendurchsatz verstanden werden kann.

Neu war für mich, dass die eine Box es nicht unbedingt gleich mitbekommt, wenn die andere Box die Internet- oder VPN-Verbindung beendet:

Mit der Internetunterbrechung kommt es auch nicht unmittelbar zu einem VPN-Abbruch, erst wenn dieser aktiv genutzt wird oder die Internetverbindung längere Zeit ausgefallen ist, detektiert die andere FRITZ!Box, dass die VPN-Verbindung abgerissen ist (--> Ereigniseintrag).

Ich habe jedenfalls Zeiträume von bis zu sechs Stunden, in denen die DE-Box keine VPN-Verbindung hat, die ES-Box aber hartnäckig davon ausgeht, dass diese durchgängig existiert (oder zumindest nichts ins Ereignisprotokoll schreibt).
Aber vielleicht liegt es ja tatsächlich am alten 1752C-Stick...
Jedenfalls sollte ich dann heute mal Paketmitschnitt und dtrace machen, was ich auch getan habe. Sicher sei es lt. AVM aber nicht, dass hieraus Erkenntnisse gewonnen werden können: die VPN-Verbindung selber könnte so nicht untersucht werden, da diese verschlüsselt sei.

Viele Grüße
Martin

 

[Docmarten]

So, erneutes Feedback vom AVM-Support:

Der Fehler wird durch ein Einbrechen des Uplaods am Anschluss der ES-Box verursacht. Da der Download weiterhin funktioniert, "merkt" die ES-Box nichts vom eigentlichen VPN-Abbruch, da weiterhin Daten von der DE-Box empfangen werden können.

Dieser asynchrone Einbruch des Datendurchsatzes führt dazu, dass nicht erneut detektiert wird, wann eine Uploadbandbreite an der ES-Box wieder verfügbar ist, da eine solche Überprüfung erst mit einem zeitgleichen Einbruch von Down- und Uplaod ausgelöst wird, weil die FRITZ!Box ein solches Ereignis als DSL-Reconnect interpretiert.

Es sei ein Glück gewesen, dass es bei der Datenerstellung zu einem Abbruch kam, sonst hätte man das vermutlich nicht sehen können. Der Huawei-Stick oder dessen Empfangslage wird als ursächlich verdächtigt und ein testweiser Austausch empfohlen. Weitere Vermutung: Eventuell drossele der Anbieter auch den Traffic oder reguliere die verfügbare Bandbreite herunter, wenn diese nicht aktiv genutzt wird.

Insgesamt macht das für mich als Laien Sinn und würde auch erklären, warum die ES-Box stundenlang glaubt, am Ende eines aktiven VPN-Tunnels zu sitzen, während die DE-Box sagt: Nö!

Wie seht Ihr das (falls noch jemand mit mir mitleidet)? Mitte Juli kann ich vermutlich vor Ort Versuche mit dem 3131 machen.
Grüße
Martin

 

[Micha0815]

Abgesehen von dem u.U. betagten 1752 finde ich

trotz der vom AVM Support empfohlenen Updates beider Boxen auf die Laborversion.

doch recht verwegen, gerade wenn Du nicht auf Malle bist. Vorsorglich würde ich mich noch mit modfs und/oder insbesonders dem BM (Boot Manager) belesen, um wenigstens auch aus der Ferne auf eine ältere Version umschalten zu können. Vorort ist das zumeist mühsam, da die Todo-Liste oft lang ist, bei schon bekanntem Rückflugtermin

Persönlich, falls der ES-Mobilfunk-Upload tatsächlich ursächlich ist, wäre ein SIP-Account und ein internes IP-Phone zwischen den FBs ein probates Mittel, um wenigstens durch das erhöhte "Grundrauschen" kontinuierlich Traffic zu erzeugen -auch/besonders im UL- um den Tunnel stabil zu halten. Andere haben es schon mit Dauerping-Scripten versucht, was in Mobilfunknetzen -je nach Provider- auch nicht immer richtig funktioniert.

Abgesehen davon, dürfte Covid19 und der in Spanien ziemlich lange+drastische Lock-Down mit heftiger Ausgangsperre etc. doch die z.T. erheblich schnelleren Mobilfunknetze -im Vergleich zu Schnecken-DSL- doch lokal massgeblich belastet/ausgelastet haben. Zudem -auch wenn Malle und die Kanarischen Inseln über Unterseekabel gut vernetzt sind- kann es schon mal vorkommen, das eine Insel komplett -egal welcher Provider/Anbindung- mal temporär abgehängt ist. Da alle Anbieter Peninsula sitzen, kann das Problem auch z.T. weiterentfernt auftreten.

OT: Bemerkenswert, wo und wie weitreichend dieser Tage z.B. die Telekom-Mobile (USA und EU) Probleme hatte. Ähnliches schien auch neulich die Kabelnetze von Unitymedia/Vodafone von GB bis die Schweiz und etliche EU-Standorte ereilt haben. So wirklich genau rücken die Provider mit der Fehlerbeschreibung eh zumeist nicht raus, wenn sie es nicht gerade auf die bösen Hacker oder andere schieben können
/OT

Derlei Probleme lassen sich z.T. aus der Ferne via VPN nicht immer genau bestimmen, wenn Du nicht spanische Pendants zu "Alle Störungen" o.ä. befragst.

Btw. würde ich Dir anraten, falls die Mobilfunktelefonie im ES-Tarif nebensächlich ist, einen E3372 neben dem E3131 mit ins Gepäck zu packen, da er als LTE-Stick für reine Data-Verbindung von AVM wohl bevorzugt unterstützt wird. Das Aussterben von 3G/UMTS zugunsten 4G/5G wird wohl auch in ES nicht aufzuhalten sein.

LG and my2cent