1821 VPN Zugang mit Fremdhersteller-VPN-CLIENT

[terror4tec]

Liebe Gemeinde,
folgende Herausforderung gilt es zu lösen: Ein LANCOM 1821 ADSL ist mit 2 weiteren LANCOM 1821 ADSL über VPN verbunden. Ein nomadisierender Client will sich nun
A.) mit jedem Router in diesem WAN per VPN via Internet (NAT/PAT!) direkt verbinden können
B.) die Router sollen gleichzeitig ihre Verbindung untereinander beibehalten
C.) Der Nomade Kann/darf/will nur einen CISCO VPN-Client einsetzen (Campus-Policy).

Wie muss der LANCOM 1821 konfiguriert werden um den schlichteren Cisco-Client zu akzeptieren. Da der 1821 ultra flexibel ist und der Cisco VPN Client sich gar nicht einstellen lässt, liegt es auf der Hand den Lancom anzupassen.

Aber woran liegt es nun? Oder kann ich nur mit dem Lancom Advanced VPN Client auf den 1821 Router ? Wo kann ich die VPN-Group (mit PW) einrichten auf der Lancom Seite ?

So sieht das LOG des Clients beim Versuch des Logins aus:

4 12:50:41.156 06/23/05 Sev=Info/4 CM/0x63100002 Begin connection process

5 12:50:41.171 06/23/05 Sev=Info/4 CVPND/0xE3400001 Microsoft IPSec Policy Agent service stopped successfully

6 12:50:41.171 06/23/05 Sev=Info/4 CM/0x63100004 Establish secure connection using Ethernet

7 12:50:41.171 06/23/05 Sev=Info/4 CM/0x63100024 Attempt connection with server "XXX.XXX.XXX.XXX"

8 12:50:42.171 06/23/05 Sev=Info/6 IKE/0x6300003B Attempting to establish a connection with XXX.XXX.XXX.XXX.

9 12:50:42.187 06/23/05 Sev=Info/4 IKE/0x63000013 SENDING >>> ISAKMP OAK AG (SA, KE, NON, ID, VID(Xauth), VID(dpd), VID(Nat-T), VID(Frag), VID(Unity)) to XXX.XXX.XXX.XXX

10 12:50:42.187 06/23/05 Sev=Info/4 IPSEC/0x63700008 IPSec driver successfully started

11 12:50:42.187 06/23/05 Sev=Info/4 IPSEC/0x63700014 Deleted all keys

12 12:50:47.656 06/23/05 Sev=Info/4 IKE/0x63000021 Retransmitting last packet!

13 12:50:47.656 06/23/05 Sev=Info/4 IKE/0x63000013 SENDING >>> ISAKMP OAK AG (Retransmission) to XXX.XXX.XXX.XXX

14 12:50:52.656 06/23/05 Sev=Info/4 IKE/0x63000021 Retransmitting last packet!

15 12:50:52.656 06/23/05 Sev=Info/4 IKE/0x63000013 SENDING >>> ISAKMP OAK AG (Retransmission) to XXX.XXX.XXX.XXX

16 12:50:57.656 06/23/05 Sev=Info/4 IKE/0x63000021 Retransmitting last packet!

17 12:50:57.656 06/23/05 Sev=Info/4 IKE/0x63000013 SENDING >>> ISAKMP OAK AG (Retransmission) to XXX.XXX.XXX.XXX

18 12:51:02.656 06/23/05 Sev=Info/4 IKE/0x63000017 Marking IKE SA for deletion (I_Cookie=6124AE80A1A16E6D R_Cookie=0000000000000000) reason = DEL_REASON_PEER_NOT_RESPONDING

19 12:51:03.156 06/23/05 Sev=Info/4 IKE/0x6300004A
Discarding IKE SA negotiation (I_Cookie=6124AE80A1A16E6D R_Cookie=0000000000000000) reason = DEL_REASON_PEER_NOT_RESPONDING

20 12:51:03.156 06/23/05 Sev=Info/4 CM/0x63100014
Unable to establish Phase 1 SA with server "XXX.XXX.XXX.XXX" because of "DEL_REASON_PEER_NOT_RESPONDING"
***
Danke für die Unterstützung in diesen warmen Tagen...

[backslash]

Hi terror4tec

Wo kann ich die VPN-Group (mit PW) einrichten auf der Lancom Seite ?

Gar nicht - und genau da liegt das Problem: Der CISCO-Client fordert immer XAUTH - nur leider unterstützt das LANCOM kein XAUTH.

Daher wird es mit dem CISCO-Client auch nicht funktionieren.

Btw. XAUTH ist ein massives Sicherheitsrisiko und sollte daher niemals verwendet werden. Der Grund dafür ist, daß jeder, der den Gruppen-Key kennt (oder das Gruppen-Zertifikat hat), vorgaukeln kann, er wäre der Server und somit die im XAUTH übermittelten Usernamen- und Paßwörter im Klartext mitlesen kann.

Daher genügt es nicht, wenn z.B. ein Mitarbeiter die Firma verläßt, einfach nur den Usernamen dieses Mitarbeiters aus der Datenbank zu löschen - er könnte vorher problemlos andere Usernamen und Paßwörter ausspioniert haben. Daher muß in diesem Fall für alle Mitarbveiter ein neuer Gruppen-Key (oder ein neues Gruppen-Zertifikat) vergeben werden (und genau das wollte man ja eigentlich mit XAUTH vermeiden...)

Daher: Für alle Mitarbeiter eigene Pre-Shared-Keys oder Zertifikate vergeben und auf XAUTH gänzlich verzichten

Gruß
Backslash