Ich bin erst einmal schon extrem verblüfft, daß in der FRITZ!Box für Phase1 keine "remoteid" erforderlich ist, denn wir reden hier ja über "conntype_lan". (Auch bei conntype_user fällt in der FRITZ!Box ja eher die localid weg, während die remoteid als "keyid" benutzt wird.)
Ich hätte eher erwartet, daß damit schon die richtige Verbindung in Phase1 nicht identifiziert werden kann in der FRITZ!Box, denn nach meiner (bisherigen) Überzeugung wird die Kombination aus "localid" und "remoteid" (die ja im "aggressive mode" benötigt werden, um den korrekten PSK zu finden) gebraucht.
Es kann ja sein, daß es einer der beiden Kommunikationspartner nicht so genau damit nimmt ... oder hast Du da eventuell zuviel in der Konfigurationsdatei der FRITZ!Box gelöscht?
Erwischt. Danke für das Bemerken.
Das habe ich jetzt behoben.
Andererseits fällt mir noch auf, daß nach meinem Verständnis (ohne genaue Kenntnisse des Bintec-Gerätes) die Verbindung im Moment eigentlich nur von der FRITZ!Box-Seite aufgebaut werden kann, da das Bintec-Gerät die Adresse der Gegenstelle nicht kennt (ich vermute mal, bei "Peer-Adresse" kann entweder eine Adresse oder ein Name eingetragen werden?).
Auch erwischt. Das hatte ich später dann geändert, ohne dran zu denken, das hier nochmal zu posten.
Welche Proposals sich bei einer FRITZ!Box tatsächlich hinter den Angaben in "phase1ss" und "phase2ss" verbergen, findest Du auf der FRITZ!Box in der Datei /etc/default.$CONFIG_PRODUKT/$OEM/ipsec.cfg. Ein Blick lohnt auf alle Fälle, ggf. auch die Auswahl eines "weniger ausführlichen" Sets. Seit 06.20 unterstützt die FRITZ!Box bei passender "phase1ss" auch "bessere" DH-Gruppen, den richtigen Selektor findest Du wieder in der ipsec.cfg. Auch kennt die Box meines Wissens für Phase2 nur Proposals mit einer oder acht Stunden "Lebensdauer" eines Schlüsselsets, wenn Du das Bintec-Gerät in Phase2 entsprechend anpaßt, ist eine weitere mögliche Fehlerquelle (theoretisch sollte zwar der kleinere Wert ausgehandelt werden, das klappt aber nicht immer reibungslos) aus dem Weg.
So, und da verlierst du mich jetzt erst einmal. Ich habe keine Ahnung, wie ich auf der Fritzbox in das Verzeichnis komme und da nachsehe. Hier hatte ich gehofft, dass jemand das schonmal richtig eingestellt hat und es nennen kann. Ich habe auch kein Problem, da beim Herausfinden mitzuwirken, nur scheitere ich im Moment daran, in das Verzeichnis zu kommen. Ob ich dann in den Dateien etwas erkenne/verstehe, steht auf einem anderen Blatt.
Mich (persönlich) würde noch interessieren, was sich auf dem Bintec-Gerät hinter "AES" für eine Schlüssellänge verbirgt, wenn das üblicherweise/meist beim AES ohne Schlüssellängenangabe assoziierte "Blocklänge == Schlüssellänge" extra als "AES-128" aufgeführt ist. Die Bedeutung des fehlenden "aktiviert" beim jeweils ersten Proposal erschließt sich mir auch nicht so richtig. Ist das ein Fehler (off by one) im Bintec-GUI oder ist das erste Proposal automatisch immer aktiviert und nur die weiteren können deaktiviert werden? Kann man diese Liste dann auch umsortieren oder legt schon die Reihenfolge beim Erstellen des Profils den ersten Eintrag für immer fest?
Umsortieren kann ich es nicht. Zumindest nicht intuitiv "schieben", sondern könnte sie so umsortieren, indem ich in der Auswahlliste oben hinsetze, was ich oben haben will. Alle Zeilen haben die gleichen Auswahlmöglichkeiten. Ob darin allerdings eine Priorisierung enthalten ist, weiß ic nicht.
Du mußt halt mit den im Bintec-Gerät eingestellten Verfahren (das AES128/MD5 für Phase1 würde ich gleich verwerfen) in der ipsec.cfg von AVM auf die Suche gehen, ob die im ausgewählten Set für die jeweilige Phase auch enthalten sind.
Warum verwerfen? Im Moment scheint mir AES/SHA1 genau der Treffer zu sein, mit dem es geht. Ist in Phase 1 und 2 angezeigt im Bintec.
Gibt es einen Grund, warum Du (wenn meine Interpretation der Bintec-Einstellungen stimmt) dort DPD ausgeschaltet hast? Auch bei der Kompression würde ich mich an den möglichen Proposals der FRITZ!Box orientieren ... wenn Du da ein Set ohne Kompression findest, ist es - zumindest anfangs - sicherlich hilfreich, die zusätzliche Paket-Transformation erst einmal wegzulassen. Das klappt aber am besten, wenn es beide Seiten auch tatsächlich so wollen, ansonsten würde ich auch auf der Bintec-Seite eine Kompression aktivieren (der Paketaufbau ändert sich dadurch, deshalb müssen das beide Seiten wirklich gleich interpretieren).
Ich habe diese Empfehlung
hierher. Ausgeschaltet ist es nur in Phase 2, denn hier habe ich nur "Heartbeats" als Auswahlmöglichkeit, was wenn ich das richtig verstehe, ein Proprietäres Bintec-Ding ist.
Letztendlich ist - bei der FRITZ!Box - der Inhalt der Datei /var/tmp/ike.log noch hilfreich bei der Suche. Dort werden zumindest irgendwelche Erfolge in Phase1 vermeldet, ebenso wie die verwendeten Ports (NAT-T oder nicht) und sonstige vom Peer angebotenen Optionen. Das Bintec-Protokoll kenne ich nicht, aber eine zeitgleiche Gegenüberstellung beider Protokolle sollte zumindest Anhaltspunkte liefern können, wo es klemmt.
Auch hier weiß ich nicht, wie ich zu dieser Datei komme, daher kann ich das noch nicht ansehen.
Daß das ohne Angabe einer "keepalive_ip" in der FRITZ!Box-Konfiguration auch seitens der FRITZ!Box nur eine "on demand"-Verbindung ist, die also nur "bei Bedarf" (so im Bintec-Interface) aufgebaut wird, sei nur am Rande bemerkt. Damit schlägt aber ein Zugriff von der Bintec-Seite bei nicht aufgebauter VPN-Verbindung zuverlässig fehl (sie kann auch selbst keine Verbindung aufbauen) und auch auf der FRITZ!Box-Seite geht in aller Regel "der erste Kontakt" in die Hose, weil erst einmal der Tunnel aufgebaut werden muß, wenn keine Verbindung besteht. Zwar werden die Pakete seitens der FRITZ!Box erst einmal "eingefroren", wenn der Absender aber ungeduldiger ist als die FRITZ!Box, stellt der schon früher fest, daß er keine Antwort erhält. Ob das am Ende tatsächlich Deine Absicht ist, kann ich natürlich nicht einschätzen, aber eine solche Information (also ein einseitiger Verbindungsaufbau und dann auch noch "on demand") gehört schon zu den "Grundentscheidungen" bei einer VPN-Verbindung, die ich in #3 meinte. Das kann man zwar auch mit entsprechenden Einstellungen dokumentieren, da weiß Dein Leser aber am Ende nicht, ob das Absicht oder nur "stand schon so da" ist. Andererseits ist es bei der FRITZ!Box nach bisherigen Erfahrungen nicht unbedingt eine schlechte Idee, wenn man tatsächlich nur einen einseitigen Verbindungsaufbau zuläßt, da es ansonsten (wenn beide Peers gleichzeitig einen Verbindungsaufbau versuchen) wohl immer wieder zu Kollisionen kommt, bei denen dann eine vom Peer schon erfolgreich aufgebaute Verbindung wieder in den Abgrund gerissen wird, wenn der eigene Verbindungsversuch anschließend noch ein Timeout erzeugt.
Okay, das sollte sich durch das Eintragen der Gegenstelle nun ja so geändert haben, dass beide Seiten die Verbindung aufbauen kann. Sie soll eigentlich immer bestehen bleiben, wobei sie auch weg sein dürfte, sofern sie sofort wieder da sein kann.
Ich bin nun an dem Punkt, dass ich die Fritzbox nun nicht mehr mit user_fqdn, sondern nur noch mit fqdn füttere, und hier auch reine remoteid eingetragen habe. Und jetzt steht die Verbindung schon mal länger als vorhin.
Somit also ein herzliches Danke bis hierher für die vielen Tipps und Gedanken und das Finger-in-die-Wunde-Legen.
Ich muss noch eine weitere Fritzbox reinhängen, da kann ich das erlernte ja gleich noch verifizieren.
Am liebsten wäre mir, wenn die Verschlüsselung in der Fritzbox einigermaßen ressourcenschonend vonstatten geht. Ich habe nämlich das Problem, dass bei 1,2 MB/s über den VPN-Tunnel der Prozessor auf 100% glüht und noch nicht mal Telefonie noch funktioniert, geschweige denn das Interface der Fritzbox erscheint. Würde es bei der Aushandlung eine Möglichkeit geben, das so zu wählen, dass entweder mehr Durchsatz möglich ist oder bei gleichem Durchsatz noch Platz für VoIP wäre, wäre das schön. Dafür kenne ich aber die Feinheiten der Fritzbox nicht genug. Es scheint auf jeden Fall ein Problem der FritzBox-Software zu sein, dass dann das Interface und Telefonie nicht mehr geht, ich habe es gemeldet und man sagte mir, es würde in der nächsten Fassung vermutlich schon behoben sein.
Viele Grüße
Thomas
... friss oder stirb). 
