[Openswan Users] OpenSwan 2.3.0dr4 + Bintec X1200 / X509

[Paul Wouters]

On Thu, 23 Dec 2004, Alain RICHARD wrote:

>> Dec 17 15:06:29 mail pluto[21106]: "duesseldorf" #214: sent MR3, ISAKMP SA 
>> established
>> Dec 17 15:06:29 mail pluto[21106]: "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).

It's hard to know when the other side does something silly and decides to not
finish the ISAKMP.

> 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.

The bintec should not sent any failure message in the clear when a ISAKMP SA
has been established. Honouring any unprotected packet after this ISAKMP SA
has been established would be a big security issue.

> 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).

Right, but the ID's are sent after the ISAKMP SA has been established. Any
failure to match these ID's should be encrypted and protected within the ISAKMP
SA, and not be sent plaintext. This is an error on the bintec side.

> 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=1.2.3.4) and bintec side (Peer IDs fields).
>
> Also be sure to use the last ipsec firmware on the bintec side.

Thanks for this information! Can you tell me which bintec model you were
using?

Paul