Ich verstehe/sehe zwar gerade den Zusammenhang nicht, aber wenn ich für die Tests mit den neuen FRITZ!OS-Versionen dann die Boxen schon passend konfiguriert und verkabelt habe, ist ein (zusätzlicher) Test mit älteren Versionen auch kein Problem mehr und irgendwie ja sogar "Pflicht", wenn man Unterschiede zwischen 07.1x und 07.2x auch "sicher" erkennen/nachweisen/protokollieren will. Bei der Gelegenheit schaue ich dann auch noch mal nach den ICMP-Pakete, die sich aus der "keepalive_ip" ableiten sollten - warum die bei Dir nicht ankommen sollten, kann ich gerade nicht nachvollziehen und da kann man einfach noch zu viel falsch konfigurieren, als daß ich das jetzt "auf Verdacht hin" mit jemandem durchkauen wollte.
Wenn eine IP im LAN beim Peer dort angegeben ist, sollte der ICMP-Generator auch angeworfen werden ... und bisher war dieses Paket auch immer der Grund, warum überhaupt direkt eine VPN-Verbindung eingerichtet wurde (nicht mit "konfiguriert" oder "eingeschaltet/gestartet" zu verwechseln - das sind alles Zustände, bei denen die Verbindung noch nicht hergestellt wurde), da es als Traffic für das LAN beim Peer daherkam. Wenn die Verbindung auch ohne sonstigen Traffic aufgebaut wird (also nicht "on demand", wenn jemand anderes zugreifen will), dann muß es dafür ja irgendeine Ursache geben und wenn als IP-Adresse nicht die der Box selbst angegeben wurde, MUSS das Paket eigentlich ausgeliefert werden. Und das wäre auch der nächste Ansatzpunkt ... es mag noch viele Gründe geben, warum das ICMP-Paket nicht im FRITZ!Box-eigenen Mitschnitt auftaucht - u.a. wäre es denkbar, daß es nach dem Entschlüsseln an einer Stelle "eingespeist" wird, wo es nicht länger an der "Protokollierung" vorbeikommt. Aber spätestens auf dem adressierten Ziel im entfernten LAN sollte es sich dann in den Netzwerk-Paketen finden lassen ... es gibt also noch genug andere Möglichkeiten, das Problem zu untersuchen.
Nur habe ich echt keinen Bock, das im Moment ausführlich zu klären bzw. auch nur zu überlegen, woran es am Ende scheitern könnte - das oben sind nur "erste Ideen" und die haben mit einer systematischen Fehlersuche nichts zu tun.
Entweder Du entwickelst selbst die notwendige Phantasie, um das Problem weiter zu untersuchen - z.B. wäre es sogar noch einen Test wert, ob der "ICMP-Generator" tatsächlich nur Adressen aus dem entfernten LAN akzeptiert bzw. nur die Pakete generiert, wenn das Ziel auch dort liegt oder ob er sogar diese Pakete ins eigene LAN senden würde, wenn da als "keepalive_ip" eine Adresse aus seinem eigenen LAN angegeben ist. Klappt das, bräuchte man für die Klärung, wie häufig die gesendet werden und wie groß sie sind/welche Daten sie enthalten, nicht mal die aufgebaute VPN-Verbindung,.
Ohne die eigene Phantasie bzw. die daraus resultierenden Versuche mußt Du halt warten, bis ich wieder mal die Zeit dafür finde. Aber im Moment muß ich erst mal ein paar Sachen zum Ende bringen (jetzt kommen die 07.20-Versionen ja so langsam tatsächlich "in Sicht") und kann mich nicht (schon wieder) von anderen Dingen davon ablenken lassen, sonst wird das nie etwas, weil sich dann fast wieder das Warten auf das nächste Release von AVM und die dort enthaltenen Überraschungen lohnt.
Die Frage, was AVM am VPN gemacht hat und wie sich das (a) auf die Geschwindigkeit und (b) auf den generierten Traffic auswirkt, sind jedenfalls bei mir erst einmal Nebensache - höchstens die Frage, wie die Crypto-Hardware eingebunden wurde, ist noch interessant, wenn es um die Frage der "Nachnutzung" in anderen Programmen (vom SSH- über andere VPN- bis hin zum HTTPS-Server) geht. Aber das AVM-VPN ist da erst mal nur "Studienobjekt" und nicht das primäre Ziel meiner eigenen Neugierde.
