IPSec-Tunnel zu OfficeConnect-Router mit Win-Client

Er soll hinter einem NAT-Router initiiert werden, um das als Fehlerquelle auszuschliessen, habe ich die Tests jedoch mit einer Direktanwahl bei dem Provider gefahren, an dessen SDSL-Anschluss auch der OfficeConnect hängt (hinter einem als transparente Bridge konfiguriertem Speedtouch)
ESP wird exklusiv verwendet. Da die Clients road warrior sein werden und überwiegend nicht über einen DynDNS-Eintrag oder "Besseres" verfügen, habe ich den Aggressive Mode gewählt.

Naja, ich habe ja geschrieben, dass die Tests mit einem direkt am DSL-Modem angeschlossenen WinXP-Rechner (mit deaktivierter FW, man weiss ja nie...) gefahren wurden, um NAT- und sonstige Routingprobleme auszuschliessen. Es geht so oder so nicht.
Heute abend werde ich den Router noch mal abstöpseln, wenn ich alleine im Arbeitszimmer bin, habe das Problem inzwischen sozusagen zur Privatsache zwischen mir und dem 3Com gemacht %)

UPDATE: Nun kann ich auch noch mit dem SSH-Sentinel Nichtfunktion attestieren. Der Sentinel hängt am Anfang von Phase 2 mit 5 re-transmits und gibt dann auf, allerdings habe ich hierfür auch die SA geändert, da ich auf die Schnelle nur IPV4 als ID-Type benutzen konnte. Ergebnis: "Something wrong" im Log vom 3Com, wie gehabt also.

Na sicher doch. Inzwischen habe ich noch einen Client mehr (Safenet), mit dem es ebenfalls nicht funktioniert. Der war allerdings gesprächiger und hat mir mitgeteilt, dass die ID Type des Routers als user name übertragen wird statt FQDN. Dies abzugleichen bringt aber auch keine Änderung. Nächste Woche wollen wir mal zwei von den Kisten miteinander VPNen lassen, mal sehen, ob das klappt. Nicht dass doch noch irgendwas im Provider-Netz hakt, die Inbetriebnahme des SDSL-Anschlusses fing ja schon damit an, dass unsere statischen IPs sonstwohin geroutet wurden...