Ab dem IPSec Image 7.1.1 kann man für die Phase1 und die Phase2 unterschiedliche Profile anlegen. Damit lassen sich einige Peers mit PreSharedKeys und andere mit Zertifikaten konfigurieren (Details zur Konfiguration finden Sie in den Release Notes 7.1.1).

Phase 1 Profil	Authentication Mode	IP-Adresse (Initiator)	Ergebnis
aggressive	PSKs	dynamisch	O.K.
aggressive	PSKs	statisch	O.K.
id-protect	PSKs	dynamisch	nicht O.K. *
id-protect	PSKs	statisch	O.K.
aggressive	Zertifikate	dynamisch	O.K.
aggressive	Zertifikate	statisch	O.K.
id-protect	Zertifikate	dynamisch	O.K.
id-protect	Zertifikate	statisch	O.K.

* Der "Responder" kann die Authentifikation nicht erfolgreich abschließen, da die IP-Adresse des Initiators dynamisch ist und die ID verschlüsselt übertragen wird. Damit schlägt der Verbindungsaufbau fehl.

Probleme bei der Authentifikation von Peers können dann auftreten, wenn die Peers mit unterschiedlichen Proposals (AES, 3DES, Blowfish, ...) und/oder unterschiedlichen Modes (id-protect, aggressive) konfiguriert wurden. Folgende IPSec-Meldung wird im Fehlerfall am Router ausgegeben (Beispiel):
11:32:45 INFO/IPSEC: P1: peer 1 (PSKs) sa 5306 (I): failed id der_asn1_dn(any:0,[0..99]=C=de, ST=Bavaria, L=Nuremberg, O=Support, CN=R1200) -> ip 111.222.111.222 (No proposal chosen)

Lösung bei Nutzung von unterschiedlichen Modes (id-protect, aggressive):
Konfigurieren Sie unter „IKE (Phase 1) Defaults" ein Profil, das als Mode „id-protect" enthält.

Lösung bei Nutzung unterschiedlicher Proposals im Mode „id-protect":
Sie müssen eine Verkettung der konfigurierten Proposals vornehmen. Das geht nur über die MIB-Tabellen: in der Tabelle "ikeProposalTable" müssen Sie den Parameter "NextChoice(rw)" so konfigurieren, daß er auf das nächste konfigurierte Proposal (Profil) verweist.

rh