1823 (SW 7.7) und Cisco IP Sec. Konzentrator

[CMC]

Hallo!

Ich habe ein Problem mit dem "Zusammenspiel" zwischen einen 1823 (SW. 7.7) und einem Cisco VPN Konzentrator, ist in dieser Sache schon mal einer unterwegs gewesen?

Der 1823 soll per IPSec mit dem Cisco Konzentrator spielen bzw. dynamisch aus dem IP-Pool eine Adresse zugeteilt bekommen!

Thanks

CMC

[backslash]

Hi CMC,

hier taucht immer wieder auf daß das XAUTH im LANCOM nicht mit dem XAUTH von Cisco zusammenspielen will - zwar nur im Zusammenhang mit Cisco-Clients, die sich ins LANCOM einwählen sollen, aber es könnte auch umgekehrt ein Problem sein...

Unter der Annahme, daß das XAUTH dennoch funktioniert, mußt du folgende Einstellungen vornehmen:

1. In der Routing-Tabelle (IP-Router -> Routing -> Routing-Tabelle) eine Route in das gewünschte Netz legen und dort die Maskierung aktivieren (Intranet und DMZ maskieren).

2. In der VPN-Verbindungsliste (VPN -> Allgemein -> Verbindungsliste) für die VPN-Gegenstelle IKE-CFG und XAUTH beide auf Client stellen

3. Die IKE- (VPN -> IKE-Param.) und IPSec-Proposal-Listen (VPN -> IPSec-Param.) für die Gegenstelle so erstellen, daß sie jerweils nur *EIN* Proposal enthalten und als Verschlüsselung 3DES und Hash SHA1 wählen.

4. Bei der Identität (VPN -> IKE-Auth -> IKE-Schlüssel und Identitäten) als lokale Identitäts-Typ Key-ID (Gruppenname) auswählen und als Identität den Gruppennamen eintragen. Als Preshared-Key den Gruppenschlüssel eintragen

5. Die erstellten Proposal-Listen und die Identität faßt du in der Verbindungs-Parameter-Liste (VPN -> Allgemein -> Verbindungs-Parameter) zu einem Eintrag zusammen, den du dann der VPN-Gegenstelle in der VPN-Verbindungsliste zuweist

6. In der PPP-Liste (Kommunikation -> Protokolle -> PPP-Liste) einen Eintrag für die VPN-Gegenstelle einrichten und dort den Username und das Paßwort für XAUTH hinterlegen


Gruß
Backslash

[Bernie137]

Hallo,

ich stehe auch aktuell vor dem Problem, zu einem Cisco Router eine VPN Verbindung hinzubekommen. Welches Cisco Gerät auf der Gegenseite steht, weis ich nicht und ich verwende einen Lancom 1781EF, LCOS 8.82. Dazu habe ich diese Daten erhalten:

crypto ipsec client ezvpn xxxxx
connect auto
group gruppe key schluessel
mode Client
username 0815_user password geheim
peer xxx.xxx.xxx.54
xauth userid mode local
exit

Geht das damit überhaupt? Irgendwie fehlt mir da noch eine Angabe zum Ziel Netzwerk. Richtet man es erst per Assistent ein und passt die Konfig an, oder ist in der Antwort von backslash eine manuelle Einrichtung gemeint?

Viele Grüße
Heiko

[Dr.Einstein]

Für mich sieht das nach einer Clienteinwahlverbindung aus statt einer Side-to-Side VPN Verbindung. Wenn das stimmt, müsstest du den IKE Configmode auf Client stellen in der VPN Verbindung. Desweiteren garantiert Aggressive Mode verwendet. Beim Pre Shared Key sollte es Gruppenname als lokale (evtl auch als entfernte) Identität sein. Der Rest sollte wie gewohnt sein.

Gruß Dr.Einstein

[Bernie137]

Hallo Dr. Einstein,

Für mich sieht das nach einer Clienteinwahlverbindung aus statt einer Side-to-Side VPN Verbindung.

Den Eindruck habe ich auch, obwohl ich darauf hinwies eine Site2Site Verbindung machen zu wollen.

Wenn das stimmt, müsstest du den IKE Configmode auf Client stellen in der VPN Verbindung. Desweiteren garantiert Aggressive Mode verwendet. Beim Pre Shared Key sollte es Gruppenname als lokale (evtl auch als entfernte) Identität sein. Der Rest sollte wie gewohnt sein.

Erkläre es mir bitte genauer. Worauf beziehst Du Dich, auf eine vorkonfigurierte Site2Site Verbindung, die schon mit dem Assistenten eingerichtet wurde? Da weis ich nämlich nicht, was ich fürs entfernte LAN für IP Infos einstellen soll.

Oder ist Deine Aussage gemeint für eine Clientsoftware?

Viele Grüße
Heiko

[Dr.Einstein]

Hm, den Assistenten würde ich für Fremdgeräte nicht verwenden.

IKE/IPSec: IKE + IPSec Proposals anlegen für die Verbindung, vermutlich AES 128 / MD5 - SHA1
IKE Schlüssel/Identitäten: Erhaltenen Schlüssel eintragen, lokale ID als Gruppenname eintragen, entfernte ID das gleiche oder die WAN IP des Ciscos (kommt drauf an, wie es im Cisco hinterlegt ist)
Verbindungs-Parameter: Erstmal DH-2 / DH-2 / erstellte IPSec-IKE Listen nutzen
Verbindungs-Liste: So wie immer mit 9999 + WAN IP, aber mit Aggressive Mode und mit IKE-CFG auf Client.
Routing Tabelle: Ist eine gute Frage, hab das erstmal einmal genutzt zwischen zwei Lancoms und hab dort ja das lokale IP Netz des anderen gekannt und entsprechend eingetragen. Theoretisch kennt ja bei einer Clienteinwahl der Client auch nicht die Subnetze, sondern jeglicher Traffic wird über den Tunnel geleitet. Du könntest testhalber eine weitere Defaultroute mit Rtg-Tag != 0 einrichten, die maskiert auf den Tunnel zeigt.

Das Ganze ist ein Grobauszug aus der Konfig, wird auf viel Tracen und mit dem Admin quatschen hinauslaufen.

Gruß Dr.Einstein

[Bernie137]

Moin,

dank Deiner Hilfe sieht es schon mal gar nicht so schlecht aus. Der Tunnel kommt aber noch nicht zu Stande, weis aber auch nicht so recht, woran es nun hängt.

Ich habe mir nun einen freien 1721VPN LCOS 8.80 zur Hand genommen und damit eine eigene Testumgebung aufgebaut, damit mir nicht beim Tracen ungewolltes Zeugs unter kommt. Allerdings bin ich mit der kompletten manuellen VPN Einrichtung gescheitert und habe den Assistenten genommen und dann alles wie vorgeschlagen abgeändert. Ich habe das verwendet:

crypto ipsec client ezvpn tkhcs -> keine Ahnung was das ist?
connect auto
group VPN_Group_Name key schluessel
mode Client
username Mein_Username password geheim
peer xxx.xxx.xxx.54
xauth userid mode local
exit

1. Bei Kommunikation -> Gegenstellen -> PPP-Liste habe ich "username Mein_Username password geheim" verwendet.

2.

IKE/IPSec: IKE + IPSec Proposals anlegen für die Verbindung, vermutlich AES 128 / MD5 - SHA1

Habe ich alles vom Assistenten gelassen.

3.

IKE Schlüssel/Identitäten: Erhaltenen Schlüssel eintragen, lokale ID als Gruppenname eintragen, entfernte ID das gleiche oder die WAN IP des Ciscos (kommt drauf an, wie es im Cisco hinterlegt ist)

Habe ich gemacht. Nachdem ich die WAN IP vom Cisco genommen habe, waren einige Fehlermeldungen verschwunden.

4.

Verbindungs-Parameter: Erstmal DH-2 / DH-2 / erstellte IPSec-IKE Listen nutzen

Alles vom Assistenten gelassen

5.

Verbindungs-Liste: So wie immer mit 9999 + WAN IP, aber mit Aggressive Mode und mit IKE-CFG auf Client.

Ist erledigt.

6.

Routing Tabelle: Ist eine gute Frage, hab das erstmal einmal genutzt zwischen zwei Lancoms und hab dort ja das lokale IP Netz des anderen gekannt und entsprechend eingetragen. Theoretisch kennt ja bei einer Clienteinwahl der Client auch nicht die Subnetze, sondern jeglicher Traffic wird über den Tunnel geleitet. Du könntest testhalber eine weitere Defaultroute mit Rtg-Tag != 0 einrichten, die maskiert auf den Tunnel zeigt.

Hab ich erst mal so eingestellt mit Routing-Tag=1. Da der Tunnel noch nicht steht, ist es erst mal noch nicht das nächste Problem.

Der Trace dazu sieht wie folgt aus und ich kann jetzt nicht erkennen, woran es scheitert:

Code: Alles auswählen

[VPN-Status] 2013/11/15 10:06:20,531  Devicetime: 2013/11/15 10:06:20,630
VPN: connecting to KIDICAP (xxx.xxx.xxx.54)

[VPN-Status] 2013/11/15 10:06:20,750  Devicetime: 2013/11/15 10:06:20,650
VPN: start IKE negotiation for KIDICAP (xxx.xxx.xxx.54)

[VPN-Status] 2013/11/15 10:06:20,750  Devicetime: 2013/11/15 10:06:20,650
IKE info: Phase-1 negotiation started for peer KIDICAP rule isakmp-peer-KIDICAP using AGGRESSIVE mode

[VPN-Status] 2013/11/15 10:06:20,750  Devicetime: 2013/11/15 10:06:20,710
IKE log: 100620.000000 Default ipsec_validate_id_information: dubious ID information accepted
IKE info: The remote server xxx.xxx.xxx.54:500 (UDP) peer KIDICAP id <no_id> supports draft-ietf-ipsec-isakmp-xauth
IKE info: The remote server xxx.xxx.xxx.54:500 (UDP) peer KIDICAP id <no_id> negotiated rfc-3706-dead-peer-detection
IKE info: The remote server xxx.xxx.xxx.54:500 (UDP) peer KIDICAP id <no_id> supports NAT-T in mode draft
IKE info: The remote server xxx.xxx.xxx.54:500 (UDP) peer KIDICAP id <no_id> supports NAT-T in mode draft
IKE info: The remote server xxx.xxx.xxx.54:500 (UDP) peer KIDICAP id <no_id> supports NAT-T in mode draft

[VPN-Status] 2013/11/15 10:06:20,750  Devicetime: 2013/11/15 10:06:20,710
IKE info: Phase-1 remote proposal 1 for peer KIDICAP matched with local proposal 1

[VPN-Status] 2013/11/15 10:06:20,812  Devicetime: 2013/11/15 10:06:20,910
IKE info: Phase-1 [inititiator] for peer KIDICAP between initiator id VPN_Group_Name, responder id  xxx.xxx.xxx.54 done
IKE info: SA ISAKMP for peer KIDICAP encryption aes-cbc authentication sha1
IKE info: life time ( 108000 sec/ 0 kb)

[VPN-Status] 2013/11/15 10:06:20,812  Devicetime: 2013/11/15 10:06:20,910
IKE info: Phase-1 SA Rekeying Timeout (Soft-Event) for peer KIDICAP set to 86400 seconds (Initiator)

[VPN-Status] 2013/11/15 10:06:20,812  Devicetime: 2013/11/15 10:06:20,910
IKE info: Phase-1 SA Timeout (Hard-Event) for peer KIDICAP set to 108000 seconds (Initiator)

[VPN-Status] 2013/11/15 10:06:20,812  Devicetime: 2013/11/15 10:06:20,930
IKE info: IKE-CFG: Received REQUEST message with id 0 from peer KIDICAP
IKE info: IKE-CFG:   Attribute XAUTH_TYPE               len 2 value XAUTH_TYPE_GENERIC received
IKE info: IKE-CFG:   Attribute XAUTH_USER_NAME          len 0 value (none) received
IKE info: IKE-CFG:   Attribute XAUTH_PASSWORD           len 0 value (none) received
IKE info: IKE-CFG:   Attribute XAUTH_MESSAGE            len 28 value Enter Username and Password. received

[VPN-Status] 2013/11/15 10:06:20,812  Devicetime: 2013/11/15 10:06:20,940
IKE info: IKE-CFG: Creating REPLY message with id 0 for peer KIDICAP
IKE info: IKE-CFG:   Attribute XAUTH_MESSAGE            len 0 skipped
IKE info: IKE-CFG:   Attribute XAUTH_PASSWORD           len 8 value * added
IKE info: IKE-CFG:   Attribute XAUTH_USER_NAME          len 11 value Mein_Username added
IKE info: IKE-CFG:   Attribute XAUTH_TYPE               len 2 value XAUTH_TYPE_GENERIC added
IKE info: IKE-CFG: Sending message

[VPN-Status] 2013/11/15 10:06:20,937  Devicetime: 2013/11/15 10:06:21,000
IKE info: IKE-CFG: Received REQUEST message with id 0 from peer KIDICAP
IKE info: IKE-CFG:   Attribute XAUTH_TYPE               len 2 value XAUTH_TYPE_GENERIC received
IKE info: IKE-CFG:   Attribute XAUTH_USER_NAME          len 0 value (none) received
IKE info: IKE-CFG:   Attribute XAUTH_PASSWORD           len 0 value (none) received
IKE info: IKE-CFG:   Attribute XAUTH_MESSAGE            len 28 value Enter Username and Password. received

[VPN-Status] 2013/11/15 10:06:20,937  Devicetime: 2013/11/15 10:06:21,000
IKE info: IKE-CFG: Creating REPLY message with id 0 for peer KIDICAP
IKE info: IKE-CFG:   Attribute XAUTH_MESSAGE            len 0 skipped
IKE info: IKE-CFG:   Attribute XAUTH_PASSWORD           len 8 value * added
IKE info: IKE-CFG:   Attribute XAUTH_USER_NAME          len 11 value Mein_Username added
IKE info: IKE-CFG:   Attribute XAUTH_TYPE               len 2 value XAUTH_TYPE_GENERIC added
IKE info: IKE-CFG: Sending message

[VPN-Status] 2013/11/15 10:06:20,937  Devicetime: 2013/11/15 10:06:21,070
IKE info: IKE-CFG: Received REQUEST message with id 0 from peer KIDICAP
IKE info: IKE-CFG:   Attribute XAUTH_TYPE               len 2 value XAUTH_TYPE_GENERIC received
IKE info: IKE-CFG:   Attribute XAUTH_USER_NAME          len 0 value (none) received
IKE info: IKE-CFG:   Attribute XAUTH_PASSWORD           len 0 value (none) received
IKE info: IKE-CFG:   Attribute XAUTH_MESSAGE            len 28 value Enter Username and Password. received

[VPN-Status] 2013/11/15 10:06:20,937  Devicetime: 2013/11/15 10:06:21,070
IKE info: IKE-CFG: Creating REPLY message with id 0 for peer KIDICAP
IKE info: IKE-CFG:   Attribute XAUTH_MESSAGE            len 0 skipped
IKE info: IKE-CFG:   Attribute XAUTH_PASSWORD           len 8 value * added
IKE info: IKE-CFG:   Attribute XAUTH_USER_NAME          len 11 value Mein_Username added
IKE info: IKE-CFG:   Attribute XAUTH_TYPE               len 2 value XAUTH_TYPE_GENERIC added
IKE info: IKE-CFG: Sending message

[VPN-Status] 2013/11/15 10:06:21,155  Devicetime: 2013/11/15 10:06:21,180
IKE info: Delete Notification received for Phase-1 SA isakmp-peer-KIDICAP peer KIDICAP cookies [cadbfbdfee3fa195 7f66ddbd23ef2a9b]

[VPN-Status] 2013/11/15 10:06:21,155  Devicetime: 2013/11/15 10:06:21,180
IKE info: Phase-1 SA removed: peer KIDICAP rule KIDICAP removed

[VPN-Status] 2013/11/15 10:06:21,155  Devicetime: 2013/11/15 10:06:21,180
VPN: KIDICAP (xxx.xxx.xxx.54)  disconnected

[VPN-Status] 2013/11/15 10:06:21,155  Devicetime: 2013/11/15 10:06:21,200
selecting next remote gateway using strategy eFirst for KIDICAP
     => no remote gateway selected

[VPN-Status] 2013/11/15 10:06:21,155  Devicetime: 2013/11/15 10:06:21,200
selecting first remote gateway using strategy eFirst for KIDICAP
     => CurrIdx=0, IpStr=>xxx.xxx.xxx.54<, IpAddr=xxx.xxx.xxx.54, IpTtl=0s

[VPN-Status] 2013/11/15 10:06:21,155  Devicetime: 2013/11/15 10:06:21,200
VPN: installing ruleset for KIDICAP (xxx.xxx.xxx.54)

[VPN-Status] 2013/11/15 10:06:21,155  Devicetime: 2013/11/15 10:06:21,210
VPN: rulesets installed

Viele Grüße
Heiko

[Dr.Einstein]

Beim Trace sieht man es eigentlich schön das der Lancom es macht, aber hast du in der Verbindungsliste XAUTH auf Client gestellt ? Auf den ersten Blick ist der VPN schon relativ weit. Muss also aktuell an Benutzername / Passwort scheitern, die in der PPP-Liste hinterlegt sind. Die ablehnende Meldung für XAUTH kommt aktuell vom Cisco.

Gruß Dr.Einstein

[Bernie137]

Xauth und auch IKE-CFG steht auf Client.

Egal was ich bei 1. (PPP-Liste) für Username/Passwort reinschreibe (Bockwurst, Senf oder leer lassen) - der Trace ändert sich nie.

Bei 3. kann ich die entfernte Identität leer lassen, oder die WAN-IP angeben, dann geht es so weit wie im Trace zu sehen. Alles andere scheitert. Der Gruppen-Name + Key haut hin. Wenn ich etwas abändere, meldet er sonst gleich Fehler.

Ich finde das noch merkwürdig?

Code: Alles auswählen

[VPN-Status] 2013/11/15 10:06:20,750  Devicetime: 2013/11/15 10:06:20,710
IKE log: 100620.000000 Default ipsec_validate_id_information: dubious ID information accepted

Viele Grüße
Heiko

[Dr.Einstein]

Ab jetzt benötigt man so langsam die Glaskugel, wenn kein Zugriff auf den Cisco möglich ist (oder zumindest jemand der raufguckt) :-\

[Bernie137]

Ich werde am Montag versuchen, die Glaskugel zu erreichen.

Vielen Dank schon mal bis hierher.
Heiko

[Bernie137]

Hallo,

nachdem ich heute mit der Gegenseite endlich telefonieren konnte, wurde mir gesagt dass sie noch gar nicht den Xauth User angelegt hatten. Nachdem das erledigt war, baut sich der Tunnel trotzdem nicht auf. Laut der Gegenseite sollte der Tunnel stehen, da wir eingewählt angezeigt würden. Auf meine Frage hin, welche Proposal Konfiguration denn noch notwendig sei, bekam ich nur ständig wiederholend 3DES zur Antwort. Mehr konnte oder wollte man mir nicht sagen, nur dass es keinen Support für Kundenrouter gibt, es sei denn wir kaufen einen Cisco.
In einem mir heute noch übermittelten Dokument steht folgende Passage:

Da die Verbindungen des VPN-Dienstes über Ressourcen des Internet aufgebaut werden, sind
Mechanismen zur Sicherung der zu übertragenden Daten zwingend erforderlich:

• Der Aufbau eines IPsec-Tunnels erfolgt erst nach erfolgreicher Authentifizierung.
• Die Authentifizierung erfolgt verschlüsselt. (Message Digest 5 MD5)
• Im IPSec-Tunnel werden die Datenpakete mit 3DES Encryption verschlüsselt.
Alle zur Authentifizierung erforderlichen Daten werden durch einen eingeschränkten Kreis von Administratoren vergeben. Die Erstellung eines Usernamen, Gruppennamen und dem dazugehörigen Passwort werden nach bestimmten Standards generiert. z.B. Group = VPN_XXXXXXXXX_XXX min. 12 Zeichen Key = **************** min. 16 Zeichen User = XXXXXXX min. 7 Zeichen Passwort = ******** min. 8 Zeichen Die Passwörter werden nach dem Zufallsprinzip durch einen Passwort-Generator erstellt. Sie bestehen aus Buchstaben, Zahlen und Sonderzeichen.

Nun hoffe ich, dass mir hier jemand einen heißen Tipp geben kann was ich im IPSEC-Proposal (angefügte Abbildung) noch probieren kann bzgl. des folgenden Trace:

Code: Alles auswählen

[VPN-Status] 2013/11/19 21:10:35,868  Devicetime: 2013/11/19 21:10:36,370
VPN: connecting to KIDICAP (149.211.153.54)

[VPN-Status] 2013/11/19 21:10:36,087  Devicetime: 2013/11/19 21:10:36,390
VPN: start IKE negotiation for KIDICAP (xxx.xxx.xxx.54)

[VPN-Status] 2013/11/19 21:10:36,087  Devicetime: 2013/11/19 21:10:36,390
IKE info: Phase-1 negotiation started for peer KIDICAP rule isakmp-peer-KIDICAP using AGGRESSIVE mode

[VPN-Status] 2013/11/19 21:10:36,087  Devicetime: 2013/11/19 21:10:36,450
IKE log: 211036.000000 Default ipsec_validate_id_information: dubious ID information accepted
IKE info: The remote server xxx.xxx.xxx.54:500 (UDP) peer KIDICAP id <no_id> supports draft-ietf-ipsec-isakmp-xauth
IKE info: The remote server xxx.xxx.xxx.54:500 (UDP) peer KIDICAP id <no_id> negotiated rfc-3706-dead-peer-detection
IKE info: The remote server xxx.xxx.xxx.54:500 (UDP) peer KIDICAP id <no_id> supports NAT-T in mode draft
IKE info: The remote server xxx.xxx.xxx.54:500 (UDP) peer KIDICAP id <no_id> supports NAT-T in mode draft
IKE info: The remote server xxx.xxx.xxx.54:500 (UDP) peer KIDICAP id <no_id> supports NAT-T in mode draft

[VPN-Status] 2013/11/19 21:10:36,087  Devicetime: 2013/11/19 21:10:36,450
IKE info: Phase-1 remote proposal 1 for peer KIDICAP matched with local proposal 1

[VPN-Status] 2013/11/19 21:10:36,149  Devicetime: 2013/11/19 21:10:36,650
IKE info: Phase-1 [inititiator] for peer KIDICAP between initiator id VPN_Group_Name, responder id  xxx.xxx.xxx.54 done
IKE info: SA ISAKMP for peer KIDICAP encryption aes-cbc authentication sha1
IKE info: life time ( 108000 sec/ 0 kb)

[VPN-Status] 2013/11/19 21:10:36,149  Devicetime: 2013/11/19 21:10:36,650
IKE info: Phase-1 SA Rekeying Timeout (Soft-Event) for peer KIDICAP set to 86400 seconds (Initiator)

[VPN-Status] 2013/11/19 21:10:36,149  Devicetime: 2013/11/19 21:10:36,650
IKE info: Phase-1 SA Timeout (Hard-Event) for peer KIDICAP set to 108000 seconds (Initiator)

[VPN-Status] 2013/11/19 21:10:36,149  Devicetime: 2013/11/19 21:10:36,680
IKE info: IKE-CFG: Received REQUEST message with id 0 from peer KIDICAP
IKE info: IKE-CFG:   Attribute XAUTH_TYPE               len 2 value XAUTH_TYPE_GENERIC received
IKE info: IKE-CFG:   Attribute XAUTH_USER_NAME          len 0 value (none) received
IKE info: IKE-CFG:   Attribute XAUTH_PASSWORD           len 0 value (none) received
IKE info: IKE-CFG:   Attribute XAUTH_MESSAGE            len 28 value Enter Username and Password. received

[VPN-Status] 2013/11/19 21:10:36,149  Devicetime: 2013/11/19 21:10:36,680
IKE info: IKE-CFG: Creating REPLY message with id 0 for peer KIDICAP
IKE info: IKE-CFG:   Attribute XAUTH_MESSAGE            len 0 skipped
IKE info: IKE-CFG:   Attribute XAUTH_PASSWORD           len 8 value * added
IKE info: IKE-CFG:   Attribute XAUTH_USER_NAME          len 9 value User_Name added
IKE info: IKE-CFG:   Attribute XAUTH_TYPE               len 2 value XAUTH_TYPE_GENERIC added
IKE info: IKE-CFG: Sending message

[VPN-Status] 2013/11/19 21:10:36,227  Devicetime: 2013/11/19 21:10:36,720
IKE info: IKE-CFG: Received SET message with id 0 from peer KIDICAP
IKE info: IKE-CFG:   Attribute XAUTH_STATUS             len 2 value OK received

[VPN-Status] 2013/11/19 21:10:36,227  Devicetime: 2013/11/19 21:10:36,720
IKE info: IKE-CFG: Creating ACK message with id 0 for peer KIDICAP
IKE info: IKE-CFG:   Attribute XAUTH_STATUS             len 0 skipped
IKE info: IKE-CFG: Sending message

[VPN-Status] 2013/11/19 21:10:36,227  Devicetime: 2013/11/19 21:10:36,720
IKE info: IKE-CFG: Creating REQUEST message for peer KIDICAP
IKE info: IKE-CFG:   Id 62193 added
IKE info: IKE-CFG:   Attribute INTERNAL_IP4_ADDRESS     len 0 added
IKE info: IKE-CFG:   Attribute INTERNAL_IP4_DNS         len 0 added
IKE info: IKE-CFG:   Attribute INTERNAL_IP4_NBNS        len 0 added
IKE info: IKE-CFG:   Attribute INTERNAL_IP6_ADDRESS     len 0 added
IKE info: IKE-CFG:   Attribute INTERNAL_IP6_DNS         len 0 added
IKE info: IKE-CFG:   Attribute INTERNAL_IP6_NBNS        len 0 added

[VPN-Status] 2013/11/19 21:10:36,227  Devicetime: 2013/11/19 21:10:36,760
IKE info: IKE-CFG: Received REPLY message with id 0 from peer KIDICAP
IKE info: IKE-CFG: Expected message id 62193, ignoring ID mismatch
IKE log: 211036.000000 Default cfg_initiator_recv_ATTR: cfg packet ID 0000 did not match expected ID f2f1!
IKE info: IKE-CFG:   Attribute INTERNAL_IP4_ADDRESS     len 4 value xxx.xxx.xxx.117 received
IKE info: IKE-CFG:   Attribute INTERNAL_IP4_DNS         len 4 value xxx.xxx.xxx.212 received

[VPN-Status] 2013/11/19 21:10:36,415  Devicetime: 2013/11/19 21:10:36,800
IKE info: NOTIFY received of type RESPONDER_LIFETIME for peer KIDICAP

[VPN-Status] 2013/11/19 21:10:36,415  Devicetime: 2013/11/19 21:10:36,800
IKE info: NOTIFY received of type NO_PROPOSAL_CHOSEN for peer KIDICAP

[VPN-Status] 2013/11/19 21:10:36,415  Devicetime: 2013/11/19 21:10:36,800
IKE info: Delete Notification received for Phase-1 SA isakmp-peer-KIDICAP peer KIDICAP cookies [a9be98a3d2959d19 4de5d29e528763f0]

[VPN-Status] 2013/11/19 21:10:36,415  Devicetime: 2013/11/19 21:10:36,800
IKE info: Phase-1 SA removed: peer KIDICAP rule KIDICAP removed

[VPN-Status] 2013/11/19 21:10:36,415  Devicetime: 2013/11/19 21:10:36,800
policy manager error indication: KIDICAP (xxx.xxx.xxx.54), cause: 12546

[VPN-Status] 2013/11/19 21:10:36,415  Devicetime: 2013/11/19 21:10:36,800
VPN: Error: IPSEC-I-No-proposal-matched (0x3102) for KIDICAP (xxx.xxx.xxx.54)

[VPN-Status] 2013/11/19 21:10:36,415  Devicetime: 2013/11/19 21:10:36,810
VPN: KIDICAP (xxx.xxx.xxx.54)  disconnected

[VPN-Status] 2013/11/19 21:10:36,415  Devicetime: 2013/11/19 21:10:36,830
selecting next remote gateway using strategy eFirst for KIDICAP
     => no remote gateway selected

[VPN-Status] 2013/11/19 21:10:36,415  Devicetime: 2013/11/19 21:10:36,830
selecting first remote gateway using strategy eFirst for KIDICAP
     => CurrIdx=0, IpStr=>xxx.xxx.xxx.54<, IpAddr=xxx.xxx.xxx.54, IpTtl=0s

[VPN-Status] 2013/11/19 21:10:36,415  Devicetime: 2013/11/19 21:10:36,830
VPN: installing ruleset for KIDICAP (xxx.xxx.xxx.54)

[VPN-Status] 2013/11/19 21:10:36,415  Devicetime: 2013/11/19 21:10:36,840
VPN: rulesets installed

vg Heiko

[Dr.Einstein]

Nur so als Tipp, die Meldung kann auch aus den Netzbeziehungen zwischen den beiden Routern entstehen. Weißt du jetzt das Subnet, was am anderen Standort ist ?

[Bernie137]

Nein, ich kenne nicht wirklich die Netzbeziehungen, aber da steht was in dem Dokument, was ich noch nicht ganz verstehe...

3.2 CISCO-VPN-Hardware-Client (End-to-Site-Net)...
Anders bei einer Remote-Access-Verbindung mit einem VPN-Router. Die Verschlüsselung der Daten
erfolgt ausschließlich zwischen dem Kunden-Router und dem HP-VPN-Gateway. Wie bei der Software-
Lösung läuft der gesamte Datenverkehr vom Kunden bidirektional zur HP. Eine Kommunikation
zwischen den Kunden ist nicht zugelassen. Auf ihrem Weg durch die lokalen Netze von den
Gateways bis zu den Endgeräten bleiben die Informationen unverschlüsselt. Die Standorte können für
die lokale Netzwerkarchitektur interne IP-Adressen verwenden. Nur die Gateways müssen eine
offizielle Adresse besitzen. Sie führen zudem eine "Address Translation" durch und verbergen
dadurch die interne IP-Adressstruktur der Kunden. Das VPN ist somit für die beteiligten internen Netze
und Endgeräte transparent. Diese können deshalb auf eine VPN-Clientsoftware verzichten, was den
Aufwand für die Verwaltung des VPN senkt.
Die Authentifizierung der VPN-Router am HP-

so weit das bla bla und dann steht noch...

5 HP VPN Security Management (End-to-Site-Net)
Aus Sicherheitsgründen ist zwischen Internet und Intranet beziehungsweise den Netzen der VPN-Teilnehmer eine Firewall platziert. Die HP Firewall erlaubt nur auf bestimmten Ports (UDP 500 und TCP 10000) den Zugriff auf den HP-VPN-Gateway und somit auch auf das HP-Netz. Wobei nur die zwei folgenden Adressbereiche zum Kunden geroutet werden. xxx.xxx.87.244/32 Host xxx.xxx.89.0/24 Serversysteme Den Kunden wird empfohlen Ihr Netz gegenüber dem Internet mit einer Firewall zu schützen. Die von Hewlett-Packard installierten Router werden grundsätzlich mit Access-Listen konfiguriert. Diese erlauben nur die Verbindung zum HP-VPN-Gateway. Cisco Secure protokolliert täglich, welche Clients sich im HP-Netz authentifizieren.

D.h. ich habe "xxx.xxx.89.0/24" Serversysteme das mal als Netzbeziehung hergenommen. Das sind aber öffentliche IPs, vermutlich eine Art DMZ in die man mittels VPN erst zugreifen kann. Jedenfalls mit der Route funktioniert es nicht. Ich habe das Gefühl, ich bin kurz vorm Ziel und scheitere an irgend einer Kleinigkeit. Vielleicht resette ich nochmal den Lancom Router und fange von vorne an...

Aber noch eine prinzipielle Frage: Wenn es heißt 3DES für IPSEC, dann ist das immer 168Bit oder kann das auch mal anders sein und der Cisco macht, keine Ahnung 1024 Bit weil der Cisco so toll ist?

vg Heiko

Edit: Mit der Route xxx.xxx.87.244/32 Host kann ich nichts direkt anfangen. Ich vermute, diese ist für VPN Software Clients gedacht?

[MariusP]

Hi,
Haben die keine Beispielsconfig für sowas wie http://linux.die.net/man/5/ipsec.conf ?
Von so einer könnte man sicher besser Rückschlüsse ziehen.
Gruß