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

[Alain RICHARD]

Le 23 déc. 04, à 12:40, Paul Wouters a écrit :

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

you are probably right, bintec implementation is probably bad (altough 
we need a more accurate description to open a case at bintec).

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

I have used several bintec firmware and some of them have very broken 
beaviours. The good news is that bintec is constantly fixing the 
problems. Currently you may encounter two major versions of firmware :

- versions 6.x are the common ones. I have experienced several problems 
some of the interim versions, but the current one, version 6.3.4 patch 
level 15 works ok for me. This platform is not any longer actively 
developped as it is replace by the next one. I have tested this one 
mostly with Bintec X1200 models. Please note that most of the bintec 
1xxx models must stay with that firmware version because they don't 
have enougth flash and ram.

- version 7.x : this is the new generation with new capabilities (for 
ipsec they implement notably Nat-T). This is a very new firmware and so 
I have encountered a lot of instabilities with the vpn-5 model and 
firmware 7.1. The good news is that firmware 7.1.6 patch rev 3 has 
solved my difficulties on the vpn5. I don't know for the over models 
(for example the X1200 II has got a 7.1.10 firmware that was available 
several weeks before the one for the vpn 5...).

-- 
Alain RICHARD <mailto:alain.richard at equation.fr>
EQUATION SA <http://www.equation.fr/>
Tel : +33 477 79 48 00	 Fax : +33 477 79 48 01
Applications client/serveur, ingénierie réseau et Linux