vpn-verbindung von cisco 1841 zu 1611+

[muempf]

Hallo

ich habe ein Problem, eine VPN-Strecke zwischen der oben genannten 'eierlegenden Wollmilchsau' von Cisco und einem 1611+ herzustellen.

Der 1611+ ist ueber eine statische IP-Adresse erreichbar, wohin gegen die Cisco auf der Gegenseite, nur ueber eine dynamische IP-Adresse verfuegt, welche nicht aufloesbar ist (DynDNS o. a.). Folglich muss die Gegenstelle eine Verbindung zum 1611+ iniziieren, was soweit auch funktioniert.
Wenn ich den Verbindungsaufbau 'trace', bekomme ich folgende Ausgabe:

Code: Alles auswählen

[VPN-Status] 2007/10/18 09:17:40,670
IKE info: The remote server 84.177.44.59:500 peer def-main-peer id <no_id> supports NAT-T in mode draft
IKE info: The remote server 84.177.44.59:500 peer def-main-peer id <no_id> supports NAT-T in mode draft

[VPN-Status] 2007/10/18 09:17:40,670
IKE info: phase-1 proposal failed: remote No 1 encryption algorithm = 3DES_CBC <-> local No 1 encryption algorithm = AES_CBC
IKE info: phase-1 proposal failed: remote No 1 encryption algorithm = 3DES_CBC <-> local No 2 encryption algorithm = AES_CBC
IKE info: phase-1 proposal failed: remote No 1 encryption algorithm = 3DES_CBC <-> local No 3 encryption algorithm = BLOWFISH_CBC
IKE info: phase-1 proposal failed: remote No 1 encryption algorithm = 3DES_CBC <-> local No 4 encryption algorithm = BLOWFISH_CBC
IKE info: Phase-1 remote proposal 1 for peer def-main-peer matched with local proposal 5

[VPN-Status] 2007/10/18 09:17:40,760
IKE info: The remote server 84.177.44.59:500 peer def-main-peer id <no_id> supports NAT-T in mode draft
IKE info: The remote server 84.177.44.59:500 peer def-main-peer id <no_id> negotiated rfc-3706-dead-peer-detection
IKE info: The remote server 84.177.44.59:500 peer def-main-peer id <no_id> supports NAT-T in mode draft
IKE info: The remote server 84.177.44.59:500 peer def-main-peer id <no_id> supports draft-ietf-ipsec-isakmp-xauth

[VPN-Status] 2007/10/18 09:17:40,840
IKE info: no preshared secret found for peer isakmp-peer-def-main-peer

[VPN-Status] 2007/10/18 09:17:40,840
IKE log: 091740 Default ike_auth_get_key: no key found for peer "isakmp-peer-def-main-peer"or local ID "(null)"

[VPN-Status] 2007/10/18 09:17:40,850
IKE log: 091740 Default ipsec_get_keystate: no keystate in ISAKMP SA 00a211e0

[VPN-Status] 2007/10/18 09:17:50,850
IKE log: 091750 Default ipsec_get_keystate: no keystate in ISAKMP SA 00a211e0

[VPN-Status] 2007/10/18 09:18:00,850
IKE log: 091800 Default ipsec_get_keystate: no keystate in ISAKMP SA 00a211e0

Ich persoenlich seh das so, dass der Verbindungsaufbau nicht ueber die Phase1 hinaus kommt. Wobei mir nicht klar ist, welche 'preshared secret' hier angesprochen wird.

Wie immer, habe ich keinen Zugriff auf die Cisco-Seite, habe aber einen Auszug der 'running-config' fuer etwaige Fehleranalyse vorliegen.

Fuerr alle Hilfen, ausserst dankbar.

freundlichst
muempf

[backslash]

Hi muempf

Ich persoenlich seh das so, dass der Verbindungsaufbau nicht ueber die Phase1 hinaus kommt. Wobei mir nicht klar ist, welche 'preshared secret' hier angesprochen wird.

Du verwendest offenbar Main-Mode mit preshared Key. Das kann nur dann funktionieren, wenn beide Seiten statische (bzw. per dynDNS auflösbare) Adressen haben, da die IP-Adresse Teil der Identity ist, anhand derer der preshared Key gesucht wird.

Da der Cisco aber eine dynamische (nicht auflösbare) Adresse hat mußt du entweder Main-Mode mit Zertifikaten oder Aggressive-Mode mit preshared Key verwenden. In beiden Fällen wird eine "eigene" Identity übermittelt, anhand derer entweder der preshared Key gesucht bzw. das Zertifikat geprüft wird.

Vom Aggressive-Mode mit preshared Key ist aber aus Sicherheitsgründen abzuraten, weil diese Kombination "offline" angreifbar ist.


Gruß
Backslash

[muempf]

Hallo

Alle Annahmen sind korrekt. Im moment is noch 'MainMode' mit 'preshared Key' in den Verbindungseinstellungen eingetragen. Dies erklaert nun auch, warum hier keine Verbindung zustande kommt, wirft aber im gleichen Zug eine weitere Frage auf.

Eigentlich sollte doch eine Verbindung zustande kommen, wenn ich unter

VPN -> IKE Auth. -> IKE keys and identities

die momentane IP-Adresse meiner Gegenstelle als Identitaet hinterlege. Dies ist allerdings nicht der Fall.

Alternativ muesste, wenn 'MainMode' mit 'preshared Key' verwendet werden soll, die IP-Adresse auf Cisco-Seite ueber DynDNS o. a. aufloesbar sein, oder ich muesste auf 'AggressivMode' mit Zertifikaten wechseln.

freundlichst
muempf

[backslash]

Hi muempf

Eigentlich sollte doch eine Verbindung zustande kommen, wenn ich unter

VPN -> IKE Auth. -> IKE keys and identities

die momentane IP-Adresse meiner Gegenstelle als Identitaet hinterlege.

nein!
Du hast hier ein Henne un Ei Problem. Die IP-Adresse der Gegenseite ist impliziter Bestandteil der Identity. Erst wenn die IP-Adresse bekannt ist kann die "erweiterte" Identity aus der von dir genannten Liste ausgewertet werden (i.A. wird bei Main-Mode mit preshared Key dort "keine Identität" werwendet)

Wenn du wirklich Main-Mode mit preshared Key machhen willst, dann mußt du die jeweils aktuelle IP-Adresse der Gegenstelle als "Entfentes Gateway" in der Verbindungsliste eintragen

Gruß
Backslash

[muempf]

Hallo

Klasse, wieder was dazu gelernt. Als ich dann die oeffentiche IP-Adresse der Cisco-Seite als Gateway in die VPN-Verbindung eingetragen und diese bei der Gegenstelle auch identifiziert hab, kam sofort eine Verbindung zustande.

Allerdings bruet ich jetzt an der angeratenen Moeglichkeit mit den Zertifikaten im 'AggressivMode'.

freundlichst
muempf

[ittk]

Hi,

das kannst du getrost vergessen. Bei Zertifikaten ist der Mainmode massgebend.

[muempf]

Hallo

boeser Verschreiber. Ich moechte das ganze jetzt so umbauen, wie 'backslash' das angeraten hat. Mit dem 'AggressivMode' war meinerseits schon der 'MainMode' gemeint.

Aber wenn jemand ein relativ leicht verstaendliches HowTo zum Thema 'VPN-Zertifikate-Lancom//ggf-auch-noch-Cisco' weiss, waere ich sehr dankbar.

freundlichst
muempf