[Openswan Users] OpenSwan 2.3.0dr4 + Bintec X1200 / X509
alain.richard at equation.fr
Thu Dec 23 09:34:06 CET 2004
Le 17 déc. 04, à 15:10, Jörg Bartz a écrit :
> I am kinda stuck in some problems here, I want to establish a tunnel
> between a X1200 and OpenSwan 2.3.0dr4 - the certificates seem to be
> imported ok to the bintec and Openswan.
> I configured close to the documentation on the bintec website (for
> freeswan) - but somehow I'm stuck - logfile attached...
I have already setup x1200/x509 (firmware 6.x) and openswan (1.x and
2.x) tunnels successfully.
> Dec 17 15:06:29 mail pluto: "duesseldorf" #214: sent MR3,
> ISAKMP SA established
> Dec 17 15:06:29 mail pluto: "duesseldorf" #214: Informational
> Exchange message must be encrypted
As you may see on the openswan side, all is going ok and the openswan
side of the isakmp tunnel is successfully setup (the "ISAKMP SA
established" means only that the openswan side is ok, but not the
bintec side; I think this message must be modified because people
thinks that the full negociation of the ISAKMP tunnel is ok).
On the over side, the certificate that is sent by openswan is probably
rejected, so the negociation fails. I don't know the details of the
ISAKMP negociation, but probably the Informal Exchange message not
encrypted is the indication from bintec to openswan of the fail.
To see what is going on, you may open the serial port of the bintec and
enter a "debug all" to see the messages on the bintec side.
On the bintec side, I have encountered two main reasons for that kind
of fail :
- the clock is not properly setup : the default date is in 1970 and the
certificate is rejected because it is out of its date of validity.
Simple to correct : just ensure your bintec router has got a good
date/time and synchronize it to a SNTP time source.
- the certificate is good and properly recognized by the bintec side
(with the ca certificate for example), but it is rejected because its
ID to not match the ID you have indicated in the connection description
on the bintec (the Peer IDs field).
For this second case, I have never managed to use the ASN1 ID that is
the default if you do not specify an other ID and on your case, the log
indicate that this is this ID that you try to use ("Main mode peer ID
is ID_DER_ASN1_DN: 'C=DE, O=<censored>, OU=Duesseldorf,
CN=<censored>'"). So I think this is why it fails.
To correct such problems, I have setup my certs in order to contains an
ip address as altSubject and I use that ip address as ID to match on
the openswan (left|rightid=220.127.116.11) and bintec side (Peer IDs fields).
Also be sure to use the last ipsec firmware on the bintec side.
More information about the Users