Site-to-Site VPN mit LANCOM 1711

[n_Forcer1984]

Hallo,
ich habe bezüglich eines Kundenprojekts die Aufgabe drei Firmenstandorte per Site-to-Site VPN zu vernetzen und den Mitarbeitern im Ausendienst den Zugang über eine Remote-Access Einwahl in die jeweiligen Firmennetze zu ermöglichen.
Hardwareseitig stehen mir drei LANCOM 1711 VPN Router, welche über ein Netgear DM111PB Zugang zum Internet erhalten, zur Verfügung.
Auf der Clientseite kommt der LANCOM Advanced VPN Client zum Einsatz.
Zwecks Sicherheit sollen Zertifikate eingesetzt werden, was leider nicht so ganz klappen will.
Ich habe die benötigten Zertifikate mit OpenSSL nach der Anleitung im LANCOM Referenzhandbuch erstellt und in die VPN-Router hochgeladen (nur die jeweilige *.p12 Containerdatei, worauf unter Experten-Konfiguration/ Status/ Dateisystem folgende Zertifikatsdateien zu fiden sind: root-ca.crt; Geräte.crt; Geräte.key; Geräte.p12). Auf dem Client habe ich die erstellte Client.p12 Datei unter "Zertifikate" gespeichert.
Es funktioniert jedoch weder die Site-to-Site noch die Remote Access Verbindung.
Die Proposals sind auf IKE_RSA_SIG wie im Handbuch beschrieben eingestellt und der Main-Mode ist aktiviert.
Zur besseren Veranschaulichung hier mal das Trace-Log meiner Site-to Site Verbindung:

Code: Alles auswählen

VPN: ruleset installed for GatewayA (xxx.xxx.xxx.xxx)

[VPN-Status] 1900/01/03 15:41:18,130
VPN: start IKE negotiation for GatewayA (xxx.xxx.xxx.xxx)

[VPN-Status] 1900/01/03 15:41:18,140
VPN: rulesets installed

[VPN-Status] 1900/01/03 15:41:18,140
IKE info: Phase-1 negotiation started for peer GatewayA rule isakmp-peer-GatewayB using MAIN mode


[VPN-Status] 1900/01/03 15:41:18,240
IKE info: The remote server xxx.xxx.xxx.xxx:500 peer GatewayB id <no_id> is Enigm                                    

                                          atec IPSEC version 1.5.1
IKE info: The remote server xxx.xxx.xxx.xxx:500 peer GatewayB id <no_id> negotiat                                    

                                          ed rfc-3706-dead-peer-detection


[VPN-Status] 1900/01/03 15:41:18,240
IKE info: Phase-1 remote proposal 1 for peer GatewayB matched with local propos                                      

                                        al 1


[VPN-Status] 1900/01/03 15:41:19,260
IKE log: 154119 Default x509_cert_validate: certificate is not yet valid


[VPN-Status] 1900/01/03 15:41:19,260
IKE log: 154119 Default rsa_sig_decode_hash: received CERT can't be validated


[VPN-Status] 1900/01/03 15:41:19,260
VPN: Error: IKE-I-CERT-NOT-YET-VALID (0x2115) for GatewayB (xxx.xxx.xxx.xxx)

[VPN-Status] 1900/01/03 15:41:19,260
IKE log: 154119 Default rsa_sig_decode_hash: no public key found


[VPN-Status] 1900/01/03 15:41:19,260
IKE log: 154119 Default dropped message from xxx.xxx.xxx.xxx port 500 due to notif                                   

                                           ication type INVALID_HASH_INFORMATION


[VPN-Status] 1900/01/03 15:41:19,260
IKE info: dropped message from peer unknown xxx.xxx.xxx.xxx port 500 due to notifi                                   

                                           cation type INVALID_HASH_INFORMATION


[VPN-Status] 1900/01/03 15:41:19,260
VPN: Error: IKE-I-General-failure (0x21ff) for GatewayB (xxx.xxx.xxx.xxx)

[VPN-Status] 1900/01/03 15:41:26,350
IKE log: 154126 Default ipsec_get_keystate: no keystate in ISAKMP SA 0029d540


[VPN-Status] 1900/01/03 15:41:36,360
IKE log: 154136 Default ipsec_get_keystate: no keystate in ISAKMP SA 0029d540


[VPN-Status] 1900/01/03 15:41:46,370
IKE log: 154146 Default ipsec_get_keystate: no keystate in ISAKMP SA 0029d540


[VPN-Status] 1900/01/03 15:41:48,140
VPN: connection for GatewayB (xxx.xxx.xxx.xxx) timed out: no response

[VPN-Status] 1900/01/03 15:41:48,140
VPN: Error: IFC-I-Connection-timeout-IKE-IPSEC (0x1106) for GatewayB (xxx.xxx.xxx.xxx)

[VPN-Status] 1900/01/03 15:41:48,140
VPN: disconnecting GatewayB (xxx.xxx.xxx.xxx)

[VPN-Status] 1900/01/03 15:41:48,150
VPN: GatewayB (xxx.xxx.xxx.xxx) disconnected

[VPN-Status] 1900/01/03 15:41:48,160
VPN: selecting next remote gateway using strategy eFirst for GatewayB
     => no remote gateway selected

[VPN-Status] 1900/01/03 15:41:48,160
VPN: selecting first remote gateway using strategy eFirst for GatewayB
     => CurrIdx=0, IpStr=>xxx.xxx.xxx.xxx<, IpAddr=xxx.xxx.xxx.xxx, IpTtl=0s

[VPN-Status] 1900/01/03 15:41:48,160
VPN: installing ruleset for GatewayB (xxx.xxx.xxx.xxx)

[VPN-Status] 1900/01/03 15:41:48,170
VPN: rulesets installed

Sieht für mich so aus, als ob irgendwas mit den Zertifikaten nicht stimmt, blos was? Ach ja beim Erstellen hab ich in der OpenSSL.cnf nur [CA_default]
nur das dir-Verzeichnis angepasst sonst nichts, muss ich hier vielleicht noch mehr konfigurieren?
Als lokale und entfernte Identität hab ich unter IKE-Schlüssel folgendes angegebn:
GatewayA:
Lokal: CN=GatewayA
Entfernt: CN=GatewayB
Bei GatewayB eben entsprechend umgekehrt.

Bin für jede Antwort dankbar.

[eddia]

Hallo n_Forcer1984,

[VPN-Status] 1900/01/03 15:41:19,260
IKE log: 154119 Default x509_cert_validate: certificate is not yet valid

verfügen Deine Lancoms über eine aktuelle Systemzeit?

Edit: Oh man - ich kann Fragen stellen. Steht ja im Log.

Gruß

Mario

[n_Forcer1984]

Yippie jetzt gehts , war an der Systemuhrzeit gelegen. Danke!

[n_Forcer1984]

Hab mich wohl etwas zu früh gefreut.
Die Verbindung zwischen den drei Standorten steht jetzt.
Aber wenn ich versuche mich von einem Advanced VPN-Client einzuwählen klappt das nicht.
Hier mal das Trace-Log:

Code: Alles auswählen

[VPN-Status] 2007/04/21 11:33:52,120
IKE info: The remote server xxx.xxx.xxx.xxx:500 peer GatewayB id <no_id> supports N                                                                           

   AT-T in mode draft
IKE info: The remote server xxx.xxx.xxx.xxx:500 peer GatewayB id <no_id> supports N                                                                           

   AT-T in mode draft
IKE info: The remote server xxx.xxx.xxx.xxx:500 peer GatewayB id <no_id> supports N                                                                           

   AT-T in mode draft
IKE info: The remote server xxx.xxx.xxx.xxx:500 peer GatewayB id <no_id> supports N                                                                           

   AT-T in mode rfc
IKE info: The remote server xxx.xxx.xxx.xxx:500 peer GatewayB id <no_id> negotiated                                                                           

    rfc-3706-dead-peer-detection
IKE info: The remote client xxx.xxx.xxx.xxx:500 peer GatewayB id <no_id> is NCP LAN                                                                           

   COM Serial Number Protocol 1.0 with serial number 0
IKE info: The remote server xxx.xxx.xxx.xxx:500 peer GatewayB id <no_id> supports N                                                                           

   AT-T in mode rfc


[VPN-Status] 2007/04/21 11:33:52,130
IKE info: Phase-1 remote proposal 1 for peer GatewayB matched with local proposa                                                                              

l 1


[VPN-Status] 2007/04/21 11:33:52,750
IKE info: Phase-1 failed for peer GatewayB: received ID DER_ASN1_DN:/CN=Client !                                                                              

= expected ID DER_ASN1_DN:010GatewayB


[VPN-Status] 2007/04/21 11:33:52,750
VPN: Error: IKE-R-ID-type-mismatch (0x2208) for GatewayB (xxx.xxx.xxx.xxx)

[VPN-Status] 2007/04/21 11:34:21,910
IKE info: Phase-1 failed for peer GatewayB: received ID DER_ASN1_DN:/CN=Client != expected ID DER_ASN1_DN:010GatewayB


[VPN-Status] 2007/04/21 11:34:21,910
VPN: Error: IKE-R-ID-type-mismatch (0x2208) for GatewayB (xxx.xxx.xxx.xxx)

[VPN-Status] 2007/04/21 11:34:51,000
IKE info: NOTIFY received of type ISAKMP_NOTIFY_DPD_R_U_THERE for peer GatewayB Seq-Nr 0x382ee336, expected 0x382ee336


[VPN-Status] 2007/04/21 11:34:51,000
IKE info: ISAKMP_NOTIFY_DPD_R_U_THERE_ACK sent for Phase-1 SA to peer GatewayB, sequence nr 0x382ee336

Was mich wundert ist, dass beim Verbindungsaufbau im Log GatewayB aufgeführt wird, obwohl ich mich eigentlich mit der IP von GatewayA verbinden wollte.
Muss der Client auf allen drei Gateways bekannt gemacht werden?
Bezüglich den IKE-Schlüsseleinstellungen hab ich auf GatewayB folgende Identitäten eingetragen:
Lokal: CN=GatewayB
Entfernt: CN=Client
Sollte doch eigentlich passen, oder?
Ach ja bezüglich der Adressvergabe verwende ich den IKE-Config- Mode.

[n_Forcer1984]

So, das Problem konnte ich jetzt endgültig lösen.
Der Fehlergrund war, dass der VPN Client hinter einem der Site-to-Site VPN Gateways war.
Macht ja wenig sinn von dort aus eine Remote-Access-Verbindung sozusagen über eine Site-to-Site Verbindung aufzubauen.
Als ich Testweise die Verbindung zwischen den Site-to-Site Endpunkten gekappt hatte, erfolgte die Einwahl des VPN-Clients in das entfernte Netz korrekt.