[Gelöst] LAN-To-LAN-Kopplung zwischen 7580 und 6890 funktioniert seit Fritz!OS 7 nur noch kurzzeitig

[Adsubia]

Ich habe eine Fritzbox 7580 mit Fritz!OS 7.10 und eine Fritzbox 6890 LTE, deren Netzwerke ich über eine LAN-To-LAN-Kopplung miteinander verbunden habe.

FB 7580: DSL-Anschluss mit öffentlicher IP als Responder
FB 6890: Mobilfunkverbindung (SIM von Mobilcom Debitel im Vodafone-Netz) mit nur privater IP als Initiator

Ich hatte ca. 1/2 Jahr lang die hier im Forum bekannte Konfiguration mittels zweier Einstellungsdateien erfolgreich am Laufen, die über die UI eingespielt worden sind.

Irgendwann kamen dann die Updates auf Fritz!OS 7 und seitdem baut sich - egal, ob über die GUI oder über den Weg mit den Einstellungsdateien und auch egal mit welcher Firmware auf der 6890 - das VPN zwar auf und läuft auch für eine Weile (gefühlt ein paar Stunden) und danach ist die Verbindung weg. Das heißt, obwohl die beiden Boxen eine aktive VPN-Verbindung anzeigen (Button grün), ist das jeweils andere Netz nicht mehr erreichbar (auch nicht über Pings) und kurz nach so einem gescheiterten Zugriffsversuch bekomme ich in der Responderbox die folgenden Meldungen im Log:

VPN-Fehler: McPom, IKE-Error 0x2027
VPN-Verbindung zu McPom wurde getrennt. Ursache: 9 Dead Peer Detection

Im Log der Initiator-Box stehen keine Auffälligkeiten - diese glaubt munter weiterhin verbunden zu sein, was ja offensichtlich nicht der Fall ist. Der Button in der Responderbox wird kurz danach grau, nach einer Weile aber wieder grün und das Log der 7580 zeigt wieder eine aufgebaute VPN-Verbindung an. Trotzdem kein Zugriff von einem ins andere Netz. Ich bekomme den Zugriff nur wieder kurzzeitig nach einem Neustart der Initiatorbox hin.

Ich habe wie gesagt die hier im Board bekannte Art der Konfiguration erfolgreich und stabil am Laufen gehabt bis Fritz!OS 7 kam. Danach habe ich auf Anraten des AVM-Supports das VPN über die GUI eingerichtet nach dieser Anleitung:

IPSec-VPN zwischen zwei FRITZ!Box-Netzwerken einrichten | FRITZ!Box 7590

So verbindest du zwei FRITZ!Boxen per VPN | Frag FRITZ! 10 Mit IPSec können Sie zwei FRITZ!Box-Netzwerke an unterschiedlichen Standorten über eine sicher verschlüsselte VPN-Verbindung über das Internet miteinander verbinden (LAN-LAN-Kopplung). Dadurch können Sie auf alle Geräte im entfernten...

avm.de

Das Fehlerbild ist unabhängig vom Konfigurationsweg immer identisch. Für die 6890 habe ich es auch schon mit unterschiedlichen Firmwareversionen versucht - ebenfalls ohne Erfolg. Mit AVM haben wir deswegen schon sehr lange Kontakt, aber bisher kam auch nach mehrfachem Bereitstellen der Supportdateien beider Boxen nichts dabei rum.

Weiß hier evtl. jemand mehr bzw. kennt das Fehlerbild?

 

[Adsubia]

Fällt dazu wirklich niemandem etwas ein? Ich poste hier einfach noch mal die Konfigurationen der beiden Boxen:

Spoiler: Konfiguration Initiator

vpncfg {
connections {
enabled = yes;
conn_type = conntype_lan;
name = "7580.dyndns.net";
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 = "7580.dyndns.net";
keepalive_ip = 192.168.111.1;
localid {
fqdn = "FeWo";
}
remoteid {
fqdn = "7580.dyndns.net";
}
mode = phase1_mode_aggressive;
phase1ss = "all/all/all";
keytype = connkeytype_pre_shared;
key = "sichererkey";
cert_do_server_auth = no;
use_nat_t = yes;
use_xauth = no;
use_cfgmode = no;
phase2localid {
ipnet {
ipaddr = 192.168.44.0;
mask = 255.255.255.0;
}
}
phase2remoteid {
ipnet {
ipaddr = 192.168.111.0;
mask = 255.255.255.0;
}
}
phase2ss = "esp-all-all/ah-none/comp-all/pfs";
accesslist = "permit ip any 192.168.111.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";
}

Spoiler: Konfiguration Responder

vpncfg {
connections {
enabled = yes;
conn_type = conntype_lan;
name = "FeWo";
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 = "";
keepalive_ip = 0.0.0.0;
localid {
fqdn = "7580.dyndns.net";
}
remoteid {
fqdn = "FeWo";
}
mode = phase1_mode_aggressive;
phase1ss = "all/all/all";
keytype = connkeytype_pre_shared;
key = "sichererkey";
cert_do_server_auth = no;
use_nat_t = yes;
use_xauth = no;
use_cfgmode = no;
phase2localid {
ipnet {
ipaddr = 192.168.111.0;
mask = 255.255.255.0;
}
}
phase2remoteid {
ipnet {
ipaddr = 192.168.44.0;
mask = 255.255.255.0;
}
}
phase2ss = "esp-all-all/ah-none/comp-all/pfs";
accesslist = "permit ip any 192.168.44.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";
}

 

[Micha0815]

Sicher dass Du Responder<->Initiator-Seite nicht verwechselt hast?
Initiator sollte imho die 6890/Mobilfunkseite/FeWo sein mit "allways_renew= yes" und die public-IPv4-Seite Responder.
Kontrolliere/vergleiche das nochmals in aller Ruhe und hoffentlich nicht zu früh ohne Kaffee für mich
LG

 

[Adsubia]

Hallo @Micha0815,

ich dachte eigentlich, das passt so. Der Initiator (6890 ohne öffentliche IP) verbindet sich mit dem Remote-Host 7580.dyndns.net mit keepalive_ip = 192.168.111.1 und der Responder (also die 7580) hat einen leeren Remote-Host und keepalive_ip = 0.0.0.0, weil er ja einfach nur die Füße still halten und nicht seinerseits die Verbindung aufbauen soll, da die 6890 aus dem Internet nicht direkt erreichbar ist.

 

[PeterPawn]

@Adsubia:
Die Konfigurationsdateien sehen für mich soweit gut aus ... ich hätte nur für die P1-ID "FeWo" auch ein Format gewählt, das tatsächlich einem FQDN (Fully Qualified Domain Name) entspricht.

Es kann aber auch nichts schaden, wenn in der Konfiguration auf der 7580 ebenfalls eine "keepalive_ip" konfiguriert ist (wenn es keine Volumenbeschränkungen beim Traffic gibt), denn dann wird in der Gegenrichtung auch zumindest das ICMP-Echo-Paket erzeugt (und bei aufgebautem Tunnel auch gesendet) ... ansonsten wäre diese Richtung beim "Offenhalten" des Verbindungswegs darauf angewiesen, daß die ICMP-Echo-Pakete von der Gegenseite mit einem ICMP-Reply-Paket beantwortet werden, was ggf. irgendwelche Firewall-Einstellungen verhindern könnten (ich weiß gerade nicht, ob die "Firewall im Stealth Mode" auch für ICMP-Pakete gilt, die über einen VPN-Tunnel reinkommen).

----------------------------------------------------------------------------------------------

AVM hat ja - nach eigenem Bekunden - beim VPN deutlich mehr geändert, als ansonsten üblich:

Internet:
- Verbesserung Für VPN-Verbindungen können nun Domain-Namen festgelegt werden, die über den Tunnel aufgelöst werden
- Verbesserung Bei VPN-Verbindungen wird nun auch nach Verbindungsende das entfernte Netz in der Übersicht angezeigt
- Verbesserung Für VPN-Verbindungen können nun beliebige Bezeichnungen festgelegt werden
- Verbesserung Eine VPN-Verbindung kann nun den gesamten Netzwerkverkehr übertragen (VPN Full Tunneling, Default Route über VPN Tunnel)
- Verbesserung Verbesserung der VPN-Verbindungsaushandlung
- Verbesserung VPN LAN-LAN Kopplung einer FRITZ!Box am DS-Lite-Anschluss zu IPv4-Gegenstellen ermöglicht
- Verbesserung Beim Importieren einer VPN-Einstellungsdatei erfolgten diverse Überarbeitungen
- Behoben Aus dem Fenster für VPN-Einstellungen konnten Einstellungen nicht kopiert werden
- Behoben VPN LAN-LAN-Kopplung zu festen IP-Adressen war nicht funktional (IKE-Error 0x2005)

Welche Auswirkungen das jetzt auf den Verbindungsaufbau hat (insb. der Punkt mit DS-Lite vs. IPv4, der vermutlich eher CGN vs. IPv4 ist und damit beim Mobilfunk i.d.R. auch zuschlägt), muß man erst mal in aller Ruhe ermitteln, wenn man da irgendwelche Tipps geben will.

Bisher war es so, daß der AVM-Daemon ständig die DynDNS-Adresse abfragt, um Änderungen an dieser Stelle zeitnah zu erkennen und dann die Verbindung zur geänderten Adresse aufzubauen. Sowie auf einer Seite ein "remotehostname" gesetzt war, kam auch diese DNS-Abfrage zum Einsatz. Das ist auch der Grund, warum es nur mit handgemachten Konfigurationen funktionierte, denn der GUI-Editor trug bisher IMMER den entfernten Hostnamen bei P1-Remote-ID UND bei "remotehostname" ein. Nach meinen bisherigen (aber nur spontanen und nicht systematischen) Beobachtungen hat sich an der Art und Weise der Konfiguration aber auch bei der 07.10 nichts geändert ... es werden immer noch beide Werte mit der angegebenen Adresse des Gegenübers gesetzt. Wenn es da also Unterschiede gibt, dann liegen diese nicht in der Art und Weise der Konfiguration (mit dem GUI), sondern in der Auswertung dieser Konfigurationsdateien durch den IKE-Daemon.

Die Option "VPN-Verbindung dauerhaft halten" schaltet hingegen die "keepalive_ip" in der lokalen Konfiguration ein bzw. aus ... als Ziel wird die erste Adresse innerhalb des entfernten Netzwerk-Segments verwendet - "always_renew" setzt AVM nach meinen bisherigen Beobachtungen nicht selbst (zumindest nicht beim LAN2LAN).

Wenn sich also in den Konfigurationsdateien nichts wichtiges geändert hat, muß es an Änderungen im Daemon liegen ... bisher war es ja so (zumindest konnte man das aus Beobachtungen und Protokollen schließen), daß in der normalen Konfiguration (beide Seiten haben "remotehostname" gesetzt) auch beide Seiten einen Verbindungsaufbau versuchen (sowie Daten für den Tunnel vorliegen, die natürlich auch aus dem ICMP-Generator für die "keepalive"-Pakete stammen können) und dabei in einer Konfiguration, wo nur eine der beiden Seiten eingehende Verbindungen entgegennehmen kann, die Seite mit der öffentlichen IP-Konfiguration zwar normal auf den Verbindungswunsch von ihrem Peer reagiert, dieser aber natürlich nicht auf ihren eigenen ... damit kam es dort dann zum Timeout und beim Abräumen der SAs für diesen, zum Scheitern verurteilten Verbindungsversuch, wurde die (funktionierende) Verbindung von der Gegenseite gleich mit abgeräumt.

Wenn AVM da jetzt geändert hat und vor dem Versuch des eigenen Verbindungsaufbaus erst einmal überprüft, ob die Gegenrichtung bereits aufgebaut ist und funktioniert (wie das bisher beim passiven Responder ja auch war, nur konnte diese Box da ihrerseits halt keine Verbindung aufbauen) und in diesem Falle auf den eigenen Versuch verzichtet, fällt zumindest dieses komplette Abräumen (in den meisten Fällen) weg, weil es kein Timeout beim eigenen Versuch der Verbindungsaufnahme gibt.

Andererseits könnte AVM auch beim erwähnten "Abräumen" der alten SAs etwas selektiver vorgehen und tatsächlich nur die betroffenen SPI löschen - das würde dann ggf. wieder darauf hinauslaufen, daß der Peer mit der öffentlichen IP zwar immer wieder die Verbindungsaufnahme versucht, aber bei einem Fehler halt nicht alles in den Abgrund gerissen wird.

Am besten wäre es wohl, wenn AVM beides kombiniert hätte ... wobei es da dann auch schon wieder komplizierter wird. Wenn man sich z.B. den Umstand, daß die Gegenseite nicht erreichbar ist, für längere Zeit merken wollte, damit man gar nicht erst mehr als einmal versucht, einen dieser, zum Scheitern verurteilten, Verbindungsversuche zu starten, weiß man anhand des Ergebnisses "Timeout" halt nicht, ob das nun an der falschen Adresse, auf die der DynDNS-Name im Moment auflöst, an einer "Unpäßlichkeit" der Gegenstelle (z.B. ein Restart) oder eben doch an der Art des entfernten Anschlusses liegt.

Rein theoretisch wäre es ja sogar denkbar, daß AVM noch eigene Erweiterungen in das Protokoll eingebaut hat (erlaubt ist das nach dem RFC, wenn man das irgendwie als Vendor ID verschickt) und nun der Gegenseite mitteilt, daß man selbst an einem DS-Lite- (oder generell CGN-)Anschluß hängt (oder in einer Kaskade) und keine eigene öffentliche IPv4-Adresse hat, damit die Gegenstelle gar nicht erst versucht, den Tunnel in Gegenrichtung selbst aufzubauen. Das würde dann wieder nur mit einer FRITZ!Box (mit FRITZ!OS 07.10 oder höher) als Gegenstelle auch funktionieren ... denkbar, daß AVM beim Vorsatz:

VPN LAN-LAN Kopplung einer FRITZ!Box am DS-Lite-Anschluss zu IPv4-Gegenstellen ermöglicht

nun genau die bisher hier praktizierte Lösung mit dem passiven Responder dank fehlender "remotehostname"-Angabe (und die funktionierte ja in den letzten Jahren - mind. seit 06.20 - auch ziemlich gut ) ins Abseits schießt - aber auch das muß man erst mal austesten.

Das alles kriegt man erst raus, wenn man sich mal die Mühe macht, den Verbindungsaufbau mitzuschneiden und zu analysieren, ebenso die Protokolle beim Rekeying. Für den Verbindungsaufbau könnte das zwar jeder Interessierte tatsächlich selbst machen und dann sicherlich auch ein paar Erkenntnisse gewinnen, aber ob und was das mit Deinem ganz konkreten Problem zu tun hat, kannst Du nur selbst ermitteln ... vor allem gehören dazu eben die passenden Protokolle. Nur anhand der "Symptome" kann man zwar einen Verdacht haben und eine Diagnose stellen, aber die wird eher selten zutreffen - zumindest dann, wenn es um geändertes Verhalten geht, was hier mit hoher Wahrscheinlichkeit ja vorliegt, und man mit altbekannten Ratschlägen dann auch nicht mehr weiterkommt.

Du brauchst also in jedem Falle die Protokolle von beiden Seiten und zwar auch jeweils nach einem sauberen Neustart (Responder zuerst) - bis hin zu dem Zeitpunkt, wo das Problem dann auftritt (besser zweimal ziehen, sonst sind die Infos vom Start nach "mehreren Stunden" schon wieder verschwunden). Je nachdem, was AVM da wie geändert hat, ist es garantiert immer noch nicht ausgeschlossen, daß sich das jetzt "miteinander verhakt", was AVM geändert hat und was Du selbst - im Rahmen der "Selbsthilfe", um eine Funktion benutzen zu können, die ja nach AVM-Lesart gar nicht unterstützt wurde bisher - in den Dateien eingetragen hast. Vielleicht hilft es sogar schon, wenn man auf die passive Responder-Rolle bei der 6890 verzichtet (wenn deren Firmware-Version >= 07.10 ist) - aber auch das kannst Du nur selbst probieren und über die Protokolle kontrollieren.

Die hohe Schule wäre dann halt der Paketmitschnitt, der den ersten Verbindungsaufbau (der ja wohl funktioniert) mit dem nächsten vergleicht und die Unterschiede ermittelt ... die Beschreibung, daß es nach dem ersten Verbindungsversuch nicht erneut funktioniert, läßt - zumindest bei mir - den Verdacht aufsteigen, daß AVM tatsächlich bei einer Verbindung zwischen zwei FRITZ!Boxen irgendwie das "Ich bin nicht erreichbar." signalisiert und das dann beim zweiten Versuch fälschlicherweise dazu führt, daß die Transformationen nicht wieder korrekt eingerichtet werden, auf welcher Seite auch immer. Welche aktiv sind, kann man (a) dem Protokoll entnehmen und (b) dem "procfs"-Interface, wenn man Shell-Zugriff hat.

 

[Adsubia]

Hallo @PeterPawn,

danke für deine ausführlichen Hinweise!

Lt. AVM liegt der Hund hier begraben: Der Initiator kann den Tunnel nur aufrechterhalten, sofern ein Client in dessen Netz regelmäßig Anfragen ins Netz des Responders sendet. Passiert das nicht, geht die Verbindung vonseiten des Initiators irgendwann flöten und wird auch nicht wieder neu aufgebaut, solange kein Client eine Anfrage sendet, die nur durch den Neuaufbau des Tunnels bearbeitet werden kann.

Angeblich sei das schon immer so gewesen. AVM dementiert strikt, dass das jemals anders gewesen ist. Wir wissen es hier aber besser, denn mit dem Prinzip des passiven Responders hat es ja lange funktioniert.

Hilft dir die Aussage von AVM in irgendeiner Form weiter, um meine Situation weiter zu beurteilen? Der Responder hat mittlerweile Fritz!OS 7.11 und der Initiator die aktuellste Labor-Version.

 

[PeterPawn]

Es gab zwischendrin bei AVM irgendwo mal Probleme mit dem Keepalive-Generator ... da wurden dann plötzlich keine Pakete mehr generiert, nachdem es eine Zeitlang funktionierte.

Wenn das hier tatsächlich das Problem sein sollte, dann würde der bereits am Beginn von #5 erwähnte Eintrag mit der "keepalive_ip" auch in der 7580-Konfiguration (also in der Konfiguration AUF der 7580, nicht die für die Verbindung ZUR 7580) dagegen vielleicht schon helfen, wenn der Generator in der 7580 nicht denselben Fehler hat. Zumindest halbiert das die Wahrscheinlichkeit des Fehlers, wenn der einigermaßen reproduzierbar ist.

Ansonsten bliebe noch die Option mit dem Dummy-Telefon ... dabei wird die eine FRITZ!Box bei der anderen als SIP-Client angemeldet und die dabei regelmäßig ausgetauschten Pakete zur Registrierung halten dann den Tunnel ebenfalls offen.

 

[Adsubia]

Das mit dem Dummy-Telefon, da bin ich nicht sicher, ob ich das richtig verstanden habe. Ich muss für die Initiator-Box einfach eine SIP-Nummer beantragen, z. B. von SipGate, und diese als Internetrufnummer im Initiator anlegen, allerdings als Registrar die LAN-IP des Responders eintragen, damit die Registrierung der Nummer hübsch durch den Tunnel geht. Richtig so oder mache ich einen Denkfehler?

Oder brauche ich nicht mal eine "real existierende" Telefonnummer dafür? Muss ich auch ein "Telefon" anlegen oder reicht nur die Internetrufnummer? Falls ein LAN/WLAN Telefon angelegt werden muss, muss das auch "physikalisch" vorhanden sein oder reicht nur das Anlegen in der Initiatorbox? Muss in der Responderbox dann auch noch was konfiguriert werden für das "Dummy Telefon"?

Ich weiß, Fragen über Fragen... So ganz verstanden habe ich das wohl noch nicht... Vor Allem, weil ich mit Telefonie hinsichtlich Fritzbox noch rein gar nix gemacht habe - das kam immer automatisch über unseren Provider rein. Wäre nett, wenn du mir das mit der Konfiguration dieses "Dummy Telefons" mal etwas ausführlicher erklären könntest...

 

[PeterPawn]

In der 7580 ein IP-Telefon als Endgerät anlegen und in der 6890 dann eine "Eigene Rufnummer" einrichten, die dieses IP-Telefon in der 7580 als Registrar benutzt ... das ist allerdings wirklich mehrfach (hier, bei AVM in der Knowledge Base, in anderen Blogs und Boards) beschrieben; das muß man nicht noch einmal durchkauen.

Ich würde es ohnehin zuerst mit der zweiten "keepalive_ip" in der 7580 versuchen - die SIP-Lösung war nur die Alternative, wenn das nichts helfen sollte.

 

[Adsubia]

Mir geht es nicht um jeden Einzelschritt, nur um das Prinzip - also was ich in welcher Box konfigurieren muss. Und ob ich real existierende Telefonnummern und Telefone dazu brauche. Es heißt ja Dummy-Telefon und mir ist nicht klar, was als Dummy genügt und was real existieren muss.

Das mit keepalive hat nämlich nicht genügt...

 

[PeterPawn]

Wie gesagt ... es gibt sogar bei AVM KB-Artikel, wie man eine FRITZ!Box bei einer anderen als SIP-Client registriert. Das kann man mit der eigenen Nacherzählung kaum übertreffen - kennt man aus dem Deutsch-/Literatur-Unterricht (oder -Seminar), daß die "Analyse" immer deutlich weniger spannend zu lesen ist, als das originale Werk.

Das mit keepalive hat nämlich nicht genügt...

Wobei mich das dann - angesichts der Beschreibung in #1, wo noch davon die Rede war, daß das Problem erst nach "gefühlt ein paar Stunden" auftreten würde - schon verblüfft. Ich hoffe mal, daß AVM den Keepalive-Generator nicht dahingehend geändert hat, daß der nur noch dann Pakete erzeugt, wenn die Verbindung nach Ansicht des Daemons auch aktiv ist.

 

[Adsubia]

Gut, dann sag mir nur noch eins: Genügt es wenn ich die 6890, also den Initiator, bei der 7580 (Responder) als SIP-Client anmelde oder muss ich das auch mit in die umgekehrte Richtung machen?

 

[Adsubia]

In der 7580 ein IP-Telefon als Endgerät anlegen und in der 6890 dann eine "Eigene Rufnummer" einrichten, die dieses IP-Telefon in der 7580 als Registrar benutzt ...

Ich habe vorhin genau das getan mit Hilfe dieser Anleitung:

FRITZ!Box zum Telefonieren über andere FRITZ!Box einrichten | FRITZ!Box 7490

Wenn Sie über zwei FRITZ!Boxen verfügen, können Sie diese so einrichten, dass die an der mit dem Anschluss verbundenen FRITZ!Box (Router) eingerichteten Rufnummern auch an der zweiten FRITZ!Box (IP-Client) zur Verfügung stehen. So können Sie auch an der zweiten FRITZ!Box Telefongespräche führen...

avm.de

1. IP Telefon in der 7890 anlegen
Hier habe ich noch freie Nummern, von der ich eine für ein- und ausgehende Gespräche zugewiesen habe. Also brauche ich wohl gar keine extra Nummer von irgendeinem SIP-Anbieter dafür. Die interne Nummer ist 620.

2. Eigene Rufnummer in der 6890 anlegen
Überall, wo eine Rufnummer verlangt wird, habe ich die interne Nummer des in 1. angelegten IP Telefons (also 620) angegeben. Als Registrar die LAN IP der 7580. Benutzerdaten wie in 1. selbst vergeben. Die Registrierung der Nummer schlug zwar fehl nach dem Abschließen der Konfiguration, aber kurz danach wurde der Tunnel trotzdem erst mal wieder aufgebaut.

Mittlerweile, mehr als 1h später, ist der Tunnel trotz des "Dummy Telefons" wieder zusammengebrochen - keine Verbindung mehr vom Netz des Responders in das des Initiators.

Hat irgendwer noch einen Tipp, was ich vielleicht falsch gemacht haben könnte?

 

[PeterPawn]

Dir ist schon klar, wofür diese Einrichtung von SIP-Rufnummer und SIP-Client dienen soll?

Diese Kombination soll dafür sorgen, daß regelmäßig Traffic zwischen den beiden Standorten übertragen werden muß (weil die ICMP-Echo-Pakete des Keepalive vielleicht fehlen - auch das kann man ja einfach mal mit einem Mitschnitt überprüfen).

Wenn eine Registrierung einer SIP-Nummer fehlschlägt, probiert die FRITZ!Box das zwar am Beginn noch mehrmals in relativ kurzen Abständen ... aber nach kurzer Zeit schaltet sie dann auf deutlich längere Wartezeiten zwischen zwei Versuchen um (man sieht es an den Fehlermeldungen, wenn die Registrierung wieder einmal gescheitert ist).

Es reicht also nicht, einfach nur irgendwelche Clients und auf der anderen Seite einen neuen Registrar zu konfigurieren ... die müssen auch noch funktionieren und einander verstehen. Ohne eine erfolgreiche Registrierung wird auch der benötigte, regelmäßige Traffic zwischen den Standorten gar nicht erst erzeugt - dann kann man sich das auch gleich schenken.

Das heißt also im Umkehrschluß dann wohl auch, daß Du in jedem Falle erst einmal sicherstellen mußt, daß am Beginn der Konfigurationsversuche die VPN-Verbindung auch tatsächlich bereits besteht oder zumindest verläßlich aufgebaut werden kann - sonst wirst Du wohl nie wissen, ob/wann diese Registrierung erfolgreich war und damit in regelmäßigen Abständen (aus dem Kopf bin ich bei 210 Sekunden, würde mich aber nicht darauf festnageln lassen) erneuert wird. Treten mehrere Fehler auf, schaltet die FRITZ!Box einen Gang zurück ... weil es keinen Sinn macht, einen SIP-Provider mit ohnehin fehlschlagenden Registrierungsversuchen in Endlos-Schleife (mit kurzer Dauer) zu belästigen.

Selbst wenn ein (ungültiger) Registrierungsversuch den in #13 beschriebenen Tunnelaufbau vielleicht ausgelöst hat, heißt das noch lange nicht, daß danach auch in den benötigten, kurzen Abständen weiterer Traffic erzeugt wird, wie das bei einer erfolgreichen Registrierung der Fall wäre.

Ansonsten erinnere ich noch einmal daran, daß ich schon weiter vorne auf die Protokolle der FRITZ!Box hinsichtlich des IKE-Daemons hingewiesen habe. Mit denen kann man dann wenigstens auch anstelle der "ungefähren" Angaben, wie lange der Tunnel nun gehalten hat und wann/ob er überhaupt aufgebaut werden konnte, deutlich konkretere Erkenntnisse gewinnen - vielleicht sogar mal sehen, wo nun das Problem tatsächlich liegt. Bisher lautet die Diagnose ja eigentlich nur "geht nicht" ... ohne irgendeine Idee, WAS da eigentlich nicht geht bzw. woran das Rekeying (wenn es wirklich nach ~1 Stunde auftritt) am Ende scheitert.

 

[Adsubia]

Ja, das ist mir alles klar, wofür das gut ist. Ich hatte gehofft, dass das mit der Registrierung vielleicht etwas dauern kann. Genauso wie mit dem Einrichten der Internetverbindung: Beim Bestätigen der Einstellungen "Verbindung fehlgeschlagen", aber als ich dann später nach paar anderen Einstellungen zurück in die Übersicht ging, war der Status auf Online. Deswegen hatte ich erstmal auf so ein Phänomen spekuliert.

Ich hatte die SIP-Konfigurationen vollkommen richtig hinterlegt! Nur war in den Mobilfunkeinstellungen die Telefonie übers Internet nicht freigegeben ! Seitdem ich das dann gemacht habe, "lebt" der Tunnel nun!

Danke für die vielen Hinweise! Ich helfe gerne noch zur weiteren Analyse, denn ich wüsste selbst gern, wieso das alles auf einmal nicht mehr ohne Traffic aus dem Netz ohne öffentliche IP geht. Du brauchst die Supportdaten von beiden Boxen. Richtig? Dann schmeiße ich das Dummy Phone vorübergehend wieder raus bzw. nur das Flag, das die Registrierung der Nummer auch zulässt, warte bis der Tunnel zusammenbricht und ziehe dann die Supportdaten. Ganz am Anfang würde ich beide Boxen noch mal neustarten.

 

[PeterPawn]

Du brauchst die Supportdaten von beiden Boxen. Richtig?

Ich tue mich immer etwas schwer mit solchen Versprechen, daß ich mir das dann irgendwann mal genauer ansehen würde.

Solange es nicht mein Problem ist und kein anderer akut unter einem solchen Problem "leidet", ist es zwar (in Grenzen) spannend, was da genau passiert und man müßte es wahrscheinlich auch genauer analysieren, wenn man wieder auf den "aktuellen Stand" der Erkenntnisse hinsichtlich des AVM-VPN kommen will ... aber i.d.R. fehlt am Ende doch immer die Zeit für die eingehendere Analyse und eigentlich wäre das ja auch der Job von AVM und nicht von uns hier.

Wenn Du die Dateien also tatsächlich erstellen möchtest, weil Du ein eigenes Interesse an der Suche nach der Ursache hast, dann mache das ... wenn Du sie hier einstellst, werfe ich vermutlich auch mal einen Blick hinein.

Aber ich möchte nicht, daß mir eine "Verpflichtung" daraus erwächst, daß Du die Daten extrahierst ... meine "Aufforderungen", diese Daten zurate zu ziehen, sind eher als Anleitung im Rahmen einer Hilfe zur Selbsthilfe zu sehen bzw. als Hinweis, welche Infos man noch bräuchte, um einem (weiterhin bestehenden) Problem auf den Leib zu rücken. Wenn der "Druck" erst mal weg ist, weil es einen funktionierenden Workaround gibt, habe ich i.d.R. kein eigenes Interesse mehr an dem Problem.

Aber das Bereitstellen der Infos kann auch nichts schaden (mal vom versehentlichen Veröffentlichen schützenswerter Details abgesehen) ... vielleicht interessiert sich ja auch ein anderer für die Details des Problems und analysiert daher die von Dir bereitgestellten Dateien. Wie gesagt: Ich bin (mäßig) interessiert, möchte damit aber keine Verpflichtung in der Richtung: "Du wolltest die Daten doch haben, nun schau auch rein und äußere Dich zu dem, was Du da sehen kannst." eingehen. Wenn DU die Daten bereitstellen möchtest, dann mach' das ... ansonsten lass' es.

-------------------------------------------------------------------------------------------------------------------

Zum Vorgehen beim Erstellen der Support-Daten:

- Beide Boxen neu starten, Responder zuerst, aber bei inaktivem Initiator (damit dessen Neustart nicht erst nach dem erneuten Aufbau der Verbindung erfolgt) - dazu kann man z.B. die VPN-Verbindung einfach mal deaktivieren.
- VPN-Verbindung starten (erst nach dem Einstellen der korrekten Uhrzeit auf beiden Boxen, damit die Zeitstempel im Protokoll synchron sind) und ca. 5 Minuten nach dem Aufbau des Tunnels die Supportdaten von beiden Boxen ziehen.
- Dann laufen lassen und ca. 10 Minuten, nachdem das Problem aufgetreten ist, erneut die Supportdaten von beiden Boxen ziehen.
- Der Zugriff auf die (Supportdaten der) Box hinter dem CGN ist u.U. etwas knifflig, wenn man nicht vor Ort ist ... solange eine IPv6-Verbindung möglich ist, hilft diese ggf. beim (externen) Zugriff auf das GUI.
- Die 10 Minuten nach dem Auftreten des Problems sind ein Schätzwert ... AVM hatte zwischendrin ja eine Erneuerung der SAs (Rekeying) nach 90% der vereinbarten Lifetime eingebaut, warum hat man m.W. nie wirklich "angesagt". Damit startet(e) der erste Versuch des Rekeyings eben nach 54 anstatt nach 60 Minuten und das Protokoll sollte möglichst beide Zeitpunkte enthalten, weil bsiher nicht klar ist, wann der Tunnel keine Daten mehr transportiert. Notfalls braucht es auch hier noch einmal zweimaliges Auslesen der Supportdaten.
- ALLE Supportdateien gut weglegen und auch noch aufheben, wenn Teile davon schon hier veröffentlicht wurden - manchmal ergeben sich aus dem Inhalt der Protokolle noch Fragen zu anderen Punkten aus der Supportdatei, die bis dahin nicht veröffentlich wurden und trotzdem zu den anderen Daten passen müssen (also nicht einfach aus einer anderen Datei stammen können).
- Zunächst mal nur die VPN-Protokolle beider Seiten (also mind. 4 Dateien) hier einstellen ... dabei die Daten (mit Augenmaß) maskieren.

-------------------------------------------------------------------------------------------------------------------

Mit Augenmaß meint, daß es nicht sinnvoll ist, jedes "verräterische" Detail durch dieselben Zeichenketten (meinetwegen "xxx.xxx.xxx.xxx" für eine IPv4-Adresse) zu ersetzen, weil dann niemand mehr sehen kann, ob das nun die lokale oder die entfernte oder was auch immer für eine Adresse ist. Das Maskieren soll die (permanenten) privaten Daten betreffen (ggf. auch MAC-Adressen, weil AVM die gerne an anderen Stellen zur Identifikation einsetzt ... ohne diesen Ansatz von AVM wäre für die MAC-Adressen aber ohnehin am nächsten Router Feierabend, auch wenn das nicht für die Adressen von WLAN-APs gilt), mit denen der eigene Router/Anschluß identifiziert werden kann.

Dabei sollten die Zeichen zum Maskieren so gewählt werden, daß man immer noch erkennen kann, ob es sich bei zwei solchermaßen maskierten Zeichenketten ursprünglich um denselben oder um verschiedene Inhalte handelt(e). Ob man eine öffentliche IP(v4)-Adresse überhaupt maskieren muß, hängt u.a. auch davon ab, ob der eigene Provider beim nächsten Verbindungsaufbau eine neue per DHCP oder IPCP zuweist oder immer dieselbe verwendet wird. Denn wenn ersteres der Fall ist, kann man einfach eine neue Adresse beziehen und spart sich so jede Menge Arbeit und Risiko, am Ende doch zuviel unkenntlich zu machen.

Vodafone gab da bis vor kurzem (zumindest an meinem Kabelanschluß) ziemlich unrühmlich den Vorreiter und wies praktisch seit Jahren dieselbe IPv6-Adresse (/64) und auch denselben IPv6-Präfix (/62) bei jedem neuen Start meiner 6490 zu - das macht einen dann erst so richtig schön "trackbar" im Internet (zumindest den Anschluß), wenn man das weiß und davon ausgehen kann, daß alle Zugriffe von der Adresse, die unter eine /62-Maske fallen, auch von demselben "Kunden" von Vodafone kommen und das über Monate und Jahre. Mal sehen, ob sich das jetzt geändert hat, denn am 10.06.2019 habe ich tatsächlich (nach > 2 Jahren) mal einen neuen Präfix erhalten - allerdings gab es da auch eine langandauernde Störung im BK-Netz von Vodafone, die über die üblichen Zeiträume für eine Erneuerung hinaus brauchte.

Aber zurück zum Thema "Maskieren von Supportdaten" ... bei IPv6-Adressen ist das häufiger notwendig/plausibel, zumindest dann, wenn der Host-Teil einer IPv6-Adresse (die "Interface-ID") wieder anhand der MAC-Adresse gebildet wurde. Dort muß man dann beim Maskieren aber auch besonders aufpassen ... erstens erwischen viele dabei auch mal eine Portnummer mit (z.B. in der "netstat"-Ausgabe), die man eigentlich bräuchte und zweitens sind die Adressen manchmal nur in einem Bit unterschiedlich, was dann eben trotzdem einen erheblichen Unterschied bewirkt, aber vom Menschen schnell mal überlesen wird und dann hat man am Ende wieder zwei IPv6-Adressen, die nach dem Maskieren nicht mehr zu unterscheiden sind.

 

[Adsubia]

Für mich ist es selbstverständlich, dass jede Analyse hier aus dem Willen nach Hilfestellung oder auch aus eigenem Interesse / persönlicher Neugier erfolgt und das ohne jede Verpflichtung. Das sollte auf keinen Fall anders rüberkommen.

Auch ich kenne die Problematik mit der fehlenden Zeit für sowas zur Genüge. Ich würde diese Thematik gern komplett auseinandernehmen - schon aus purem Interesse, aber zeitnah werde ich das auf keinen Fall packen. Ich denke, bis ich die Daten so maskiert habe, dass alles "Private" unkenntlich ist, habe ich schon 10x selbst einen Blick dort reingeworfen. Du hast mir ja genau erklärt, wann genau ich Daten ziehen muss und somit habe ich nun ja auch schon einen sehr guten Ansatzpunkt, wie der Abgleich am Vernünftigsten zu bewerkstelligen ist. Ich schlage daher vor, dass ich - sollte ich wirklich irgendwann dazu kommen - dann hier nur die Inhalte poste, die mir auffällig erscheinen. Dann muss ich nämlich auch nur das maskieren. Wenn dann noch weitere Log-Einträge zur Beurteilung benötigt werden, können diese ja dann nachgeliefert werden.

Ich bin jedenfalls jetzt erst mal heilfroh, dass ich weiter mit den AVM Produkten arbeiten kann und mich nicht Alternativen umsehen muss. Da wären wir wieder beim Thema Zeitdefizit ... Vielen Dank jedenfalls für Alles! Ich sehe dann zu, dass ich diesen Thread auf gelöst setze.