Standartclient und LCOS 5.0
Moderator: Lancom-Systems Moderatoren
Standartclient und LCOS 5.0
Hallo
obwohl schon mal vor einiger Zeit hier behandelt, möchte ich noch mal nachfragen, ob mittlerweile einer eine Lösung für das Problem gefunden hat, das mit dem Wechsel von 3.52 auf eine höhere Version die Standartclients nicht mehr connecten (6011, 7011). ein rücksprung auf die 3.52 behebt das problem, ist aber in meinen Augen nicht wirklich eine Lösung.
Der Protokollmitschnitt zeigt zwar im Prinzip das Problem - der Client antwortet angeblich nicht, nachdem eigentlich alles o.k. ist, jedoch hat keine Maßnahme bisher zum Erfolg geführt, ihn zum Antworten zu bringen.
Hat die DPD was damit zu tun? Ist hier eine Implementierungsfehler?
Merkwürdigerweise klappt es alle 5-10 mal einmal.
hat jemand eine gute Idee?
Goermet
Protokoll:
[VPN-Status] 2005/08/10 20:08:17,860
VPN: installing ruleset for HESS2 (192.168.15.211)
[VPN-Status] 2005/08/10 20:08:17,910
VPN: ruleset installed for HESS2 (192.168.15.211)
[VPN-Status] 2005/08/10 20:08:17,910
VPN: wait for IKE negotiation from HESS2 (192.168.15.211)
[VPN-Status] 2005/08/10 20:08:30,540
IKE info: Phase-1 remote proposal 1 for peer HESS2 matched with local proposal 1
[VPN-Status] 2005/08/10 20:08:30,960
IKE info: Phase-1 [responder] for peer HESS2 between initiator id 192.168.15.21
1, responder id 194.120.145.3 done
IKE info: SA ISAKMP for peer HESS2 encryption 3des-cbc authentication md5
IKE info: life time ( 20000 sec/ 0 kb)
[VPN-Status] 2005/08/10 20:08:31,130
IKE info: Phase-2 remote proposal 1 for peer HESS2 matched with local proposal 1
[VPN-Status] 2005/08/10 20:08:47,930
VPN: connection for HESS2 (192.168.15.211) timed out: no response
[VPN-Status] 2005/08/10 20:08:47,930
VPN: Error: IFC-R-Connection-timeout-IKE-IPSEC (0x1206) for HESS2 (192.168.15.21
1)
[VPN-Status] 2005/08/10 20:08:47,930
VPN: disconnecting HESS2 (192.168.15.211)
[VPN-Status] 2005/08/10 20:08:47,950
IKE info: Delete Notificaton sent for Phase-1 SA to peer HESS2
[VPN-Status] 2005/08/10 20:08:47,950
IKE info: Phase-1 SA removed: peer HESS2 rule HESS2 removed
obwohl schon mal vor einiger Zeit hier behandelt, möchte ich noch mal nachfragen, ob mittlerweile einer eine Lösung für das Problem gefunden hat, das mit dem Wechsel von 3.52 auf eine höhere Version die Standartclients nicht mehr connecten (6011, 7011). ein rücksprung auf die 3.52 behebt das problem, ist aber in meinen Augen nicht wirklich eine Lösung.
Der Protokollmitschnitt zeigt zwar im Prinzip das Problem - der Client antwortet angeblich nicht, nachdem eigentlich alles o.k. ist, jedoch hat keine Maßnahme bisher zum Erfolg geführt, ihn zum Antworten zu bringen.
Hat die DPD was damit zu tun? Ist hier eine Implementierungsfehler?
Merkwürdigerweise klappt es alle 5-10 mal einmal.
hat jemand eine gute Idee?
Goermet
Protokoll:
[VPN-Status] 2005/08/10 20:08:17,860
VPN: installing ruleset for HESS2 (192.168.15.211)
[VPN-Status] 2005/08/10 20:08:17,910
VPN: ruleset installed for HESS2 (192.168.15.211)
[VPN-Status] 2005/08/10 20:08:17,910
VPN: wait for IKE negotiation from HESS2 (192.168.15.211)
[VPN-Status] 2005/08/10 20:08:30,540
IKE info: Phase-1 remote proposal 1 for peer HESS2 matched with local proposal 1
[VPN-Status] 2005/08/10 20:08:30,960
IKE info: Phase-1 [responder] for peer HESS2 between initiator id 192.168.15.21
1, responder id 194.120.145.3 done
IKE info: SA ISAKMP for peer HESS2 encryption 3des-cbc authentication md5
IKE info: life time ( 20000 sec/ 0 kb)
[VPN-Status] 2005/08/10 20:08:31,130
IKE info: Phase-2 remote proposal 1 for peer HESS2 matched with local proposal 1
[VPN-Status] 2005/08/10 20:08:47,930
VPN: connection for HESS2 (192.168.15.211) timed out: no response
[VPN-Status] 2005/08/10 20:08:47,930
VPN: Error: IFC-R-Connection-timeout-IKE-IPSEC (0x1206) for HESS2 (192.168.15.21
1)
[VPN-Status] 2005/08/10 20:08:47,930
VPN: disconnecting HESS2 (192.168.15.211)
[VPN-Status] 2005/08/10 20:08:47,950
IKE info: Delete Notificaton sent for Phase-1 SA to peer HESS2
[VPN-Status] 2005/08/10 20:08:47,950
IKE info: Phase-1 SA removed: peer HESS2 rule HESS2 removed
-
- Beiträge: 36
- Registriert: 09 Jul 2005, 17:10
-
- Beiträge: 36
- Registriert: 09 Jul 2005, 17:10
Hallo goermet,
ich kann die Aussage von eddia bestätigen. Der Standard-Client läuft bei mir auf W2k-Workstation und XP-Workstation über Router bzw. direkte DFÜ-Einwahl.
Als Router sind 1611, 1621, 1711, 1811 und 1821 im Einsatz. Einige davon sind "gewachsene" Systeme. Ein 1711 ist nagelneu, also gleich mit aktueller FW eingerichtet. Hier gab es nur ein Problem: In der VPN-Verbindungsliste wurde durch den Assistenten IKE-CFG auf <Server> gestellt. Erst als der Wert auf <aus> verändert wurde funktionierte es wie bei den "alten Systemen".
Gruß clarice
ich kann die Aussage von eddia bestätigen. Der Standard-Client läuft bei mir auf W2k-Workstation und XP-Workstation über Router bzw. direkte DFÜ-Einwahl.
Als Router sind 1611, 1621, 1711, 1811 und 1821 im Einsatz. Einige davon sind "gewachsene" Systeme. Ein 1711 ist nagelneu, also gleich mit aktueller FW eingerichtet. Hier gab es nur ein Problem: In der VPN-Verbindungsliste wurde durch den Assistenten IKE-CFG auf <Server> gestellt. Erst als der Wert auf <aus> verändert wurde funktionierte es wie bei den "alten Systemen".
Gruß clarice
-
- Beiträge: 36
- Registriert: 09 Jul 2005, 17:10
-
- Beiträge: 36
- Registriert: 09 Jul 2005, 17:10
Also,
um es kurz zu machen. Es gibt sozusagen einen Workaround um dieses Verhalten (bis auf wenige Ausnahmen) zu klären:
1. Update den Router auf 5.0
2. Scripte dir dann die entsprechend Notwendigen konfigurationsdaten einzeln aus (WAN, VPN, IP-Router, NETBIOS, peers, pptp, ppp) Warum einzel? Ein gesamtes zurückziehen schlug einfach gesagt fehl!
3. Resete das Teil
4. Führe die Schripte aus
5. Geht (bis auf folgende Ausnahmen: Lancom zu Lancom Verbindungen schlugen immer dann fehl, wenn auf der gegenseite eine feste IP Adresse vergeben war. Warum weiß ich auch nicht so genau, da es bei uns nur zwei waren, hab ich sie der der Einfachhalt halber einfach neu gemacht. Im Nachhinein denke ich, as ich die gegenstellen vielleicht mit hätte scripten sollen. Sonstiges, selbst exotisches wie Netgear, Cisco PIX oder Checkpointverbindungen klappen problemlos). Zwei der Standartverbinungen gingen nicht, warum weiß ich noch nicht, die LKaptops hab ich erst nächste Woche drin.
Goermet
um es kurz zu machen. Es gibt sozusagen einen Workaround um dieses Verhalten (bis auf wenige Ausnahmen) zu klären:
1. Update den Router auf 5.0
2. Scripte dir dann die entsprechend Notwendigen konfigurationsdaten einzeln aus (WAN, VPN, IP-Router, NETBIOS, peers, pptp, ppp) Warum einzel? Ein gesamtes zurückziehen schlug einfach gesagt fehl!
3. Resete das Teil
4. Führe die Schripte aus
5. Geht (bis auf folgende Ausnahmen: Lancom zu Lancom Verbindungen schlugen immer dann fehl, wenn auf der gegenseite eine feste IP Adresse vergeben war. Warum weiß ich auch nicht so genau, da es bei uns nur zwei waren, hab ich sie der der Einfachhalt halber einfach neu gemacht. Im Nachhinein denke ich, as ich die gegenstellen vielleicht mit hätte scripten sollen. Sonstiges, selbst exotisches wie Netgear, Cisco PIX oder Checkpointverbindungen klappen problemlos). Zwei der Standartverbinungen gingen nicht, warum weiß ich noch nicht, die LKaptops hab ich erst nächste Woche drin.
Goermet
Goermet (LCS)