Sorry, da kann einfach etwas nicht stimmen.
Die Angabe von "255.255.255.255" für "remoteip" im "add"-Eintrag der "ike.log" zeigt normalerweise an, daß da gerade nicht die passive Rolle als "responder" konfiguriert wurde.
Das ist - bei allen mir zugänglichen Boxen jedenfalls - ganz im Gegenteil ein Zeichen dafür, daß dort die IP-Adresse nicht bekannt ist und erst über DNS-Abfragen der "remotehostname" zu einer Adresse führt.
Wenn da am Ende im DNS eine andere Angabe steht, als die vom Gegenüber (man könnte es auch "peer" nennen) derzeit verwendete IPv4-Adresse und die FRITZ!Box dann bei der nächsten Abfrage feststellt, daß diese Adressen nicht übereinstimmen (und solche Abfragen finden regelmäßig statt, damit ein Wechsel der IP-Adresse auch in einem Szenario mit zwei dynamischen Adressen bemerkt wird), dann kann man (bzw. ich) am Ende nur noch "selbst schuld" konstatieren.
Eine Wiederholung der "Empfehlung", dann auf der "responder"-Seite die Angaben zu "remoteip" und "remotehostname" zu entfernen, wäre die einzige "Lösung", die mir hier einfiele ... allerdings wüßte ich auch keine Begründung, warum das bei einer solchen Wiederholung dann eher wahrgenommen werden sollte.
Es würde zumindest die DNS-Abfrage verhindern und damit wohl auch die Feststellung, daß da im DNS eine ganz andere Adresse steht als diejenige, von der dieser Request kommt. Wenn man schon eine VPN-Verbindung auf diese Art konfiguriert, muß man eben parallel auch dafür sorgen, daß der DNS-Name auf die aktuelle IP-Adresse (des Telekom-Anschlusses) zeigt - ansonsten läßt man diesen Namen als "remotehostname" einfach weg. Punkt. Damit ist man zumindest mal den Fehler 0x203E los ... was dann an weiteren Problemen auftaucht, kann man logischerweise erst feststellen, wenn man das erste aus dem Weg geräumt hat.
Wenn es sich in der Gegenrichtung bei dem "unknown remote peer" um die 6490 handeln sollte, die da ihrerseits bei der 7490 "anklopft" (durch das Maskieren einer IPv4-Adresse mit "6490.domain" blickt da vermutlich nur noch der Verfasser wirklich durch), würde das zumindest wieder nahelegen, daß der DynDNS-Eintrag für "7490.myfritz.net" stimmt ... dann sollte das aber auch genau der DNS-Name sein, der bei "remotehostname" in der Konfiguration der 6490 steht und dann wird der Fehler 0x203E vollends unverständlich. Daher tippe ich eher darauf, daß da andere Peers (oder wenigstens einer) nicht auch deaktiviert wurden und nun fleißig ihrerseits versuchen, eine Verbindung zur 7490 aufzubauen.
Wie wäre es denn mal mit den verwendeten Konfigurationsdateien und die dann vielleicht auch noch so "maskiert", daß wenigstens noch der Unterschied zwischen einem DNS-Namen (aka FQDN) und einer IPv4-Adresse erkennbar ist. Das eine läßt sich zwar in das andere überführen, aber bei dynamisch vergebenen Adressen ist auch das eine Einbahnstraße. Auch wäre es hilfreich, wenn Du Dich bei der Beschreibung einmal darauf festlegst, daß Host A eine 7490 ist und Host B eine 6490 und dann danach nur noch von Host A oder B die Rede ist ... bei derart nahe beieinanderliegenden Bezeichnern ist schnell auch mal ein simpler Tippfehler eingebaut, der das dann komplett durcheinanderwürfelt. Nicht ganz umsonst verwendet man bei der Beschreibung von kryptographischen Szenarien einfach zwei verschiedene Namen (üblich sind "Alice" und "Bob") für die Peers, deren Eigenschaften man dann einmal beschreibt und gut ist's ... dann ist auch klar, was eine Nachricht von Alice an Bob bedeutet für die Richtung der Kommunikation und daß eine Antwort von Bob an Alice in der Gegenrichtung erfolgt. Es macht am Ende solche "Beschreibungen" sehr viel verständlicher ...
@Shirocco88:
Ich lese im (hoffentlich en bloc kopierten) Protokoll einen Fehler 0x20
3E und der steht für etwas anderes:
http://service.avm.de/help/de/FRITZ-Box-Fon-WLAN-7490/017p1/hilfe_syslog_122
; es lebe die "Servicewüste Deutschland";
