7
IPSec-Tunnel zu OfficeConnect-Router mit Win-Client
Hallo zusammen,
ich ärgere mich nun schon seit zwei Tagen über einen primitiven IPSec-Tunnel zu einem 3Com OfficeConnect (3CR858) Router. Weder mit NCP noch mit Greenbow kommt der Tunnelbau über Phase I hinaus, meist wird noch nicht einmal die erfolgreich durchlaufen. Statt sinnvoller Fehlermeldungen läuft das Ganze in einen Timeout und dann war's das.
Hat jemand hier speziell mit den 3Com-Routern bereits IPSec-Erfahrungen? Ich dachte immer, die alten Netgear ProSafe-Router waren etwas picky was die VPN-Konfiguration angeht, aber das muss ich nun wohl mal überdenken.
ich ärgere mich nun schon seit zwei Tagen über einen primitiven IPSec-Tunnel zu einem 3Com OfficeConnect (3CR858) Router. Weder mit NCP noch mit Greenbow kommt der Tunnelbau über Phase I hinaus, meist wird noch nicht einmal die erfolgreich durchlaufen. Statt sinnvoller Fehlermeldungen läuft das Ganze in einen Timeout und dann war's das.
Hat jemand hier speziell mit den 3Com-Routern bereits IPSec-Erfahrungen? Ich dachte immer, die alten Netgear ProSafe-Router waren etwas picky was die VPN-Konfiguration angeht, aber das muss ich nun wohl mal überdenken.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 71962
Url: https://administrator.de/contentid/71962
Printed on: April 19, 2024 at 23:04 o'clock
7 Comments
Latest comment
Leider schreibst du nicht von WO der IPsec Tunnel aufgebaut wird 
Ist der IPsec Client auch hinter einem NAT Router erzwingt das ein Port Forwarding für IPsec auf diesem Router und die Verwendung des ESP Modus, da der IPsec AH Modus nicht über NAT Router übertragbar ist.
Ist der IPsec Client auch hinter einem NAT Router erzwingt das ein Port Forwarding für IPsec auf diesem Router und die Verwendung des ESP Modus, da der IPsec AH Modus nicht über NAT Router übertragbar ist.
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.
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.
Jetzt wäre es noch interessant gewesen zu erfahren ob der direkt angeschlossene PC den VPN Tunnel aufbauen konnte oder ob es in beiden Möglichkeiten (direkt am DSL oder hinter Router) scheiterte ?!
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.
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.
Hast du dem 3Com auch die aktuellste Firmware verpasst ??
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...
Das könnte auch sein. Provider wie z.B. Arcor filtern outbound IPsec Verbindungen in ihrem eigenen Netz. Inbound Verbindungen komischerweise nicht.
Das solltest du parallel unbedingt klären sonst suchst du dir einen Wolf. Oder eben per Labor Aufbau überprüfen...
Das solltest du parallel unbedingt klären sonst suchst du dir einen Wolf. Oder eben per Labor Aufbau überprüfen...
