[Openswan Users] IKE algorithms choice

[Gilles MARION]

Hello everybody,

I encountered a strange behavior with Openswan (I hope it's not due to a
misconfiguration ;)

Below the version of Openswan used :
openswan-2.6.32-20.el6_4.x86_64
(Kernel =>Linux 2.6.32-279.5.2.el6.x86_64 #1 SMP Fri Aug 24 01:07:11 UTC
2012 x86_64 x86_64 x86_64 GNU/Linux)

Globally, I want to define exactly all the ciphers used by IKE and ESP
protocols (eg: aes and sha1 for the example), so, I defined the ike and
phase2alg parameters as described in the ipsec.conf manual :

ike=aes128-sha1;modp2048
phase2alg=aes128-sha1;modp2048

Everything seems to be operationnal (the VPN between the laptop and the
gateway is up and it's possible to access all the resources defined behind
the gateway) but, after a quick test with ike-scan, the result is :

# ike-scan -M 10.4.0.6
Starting ike-scan 1.9 with 1 hosts (
http://www.nta-monitor.com/tools/ike-scan/)
10.4.0.6        Main Mode Handshake returned
        HDR=(CKY-R=f234e754af4f059c)
        SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Seconds
LifeDuration(4)=0x00007080)
        VID=4f4568794c64414365636661
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)

We can see than the SA is defined with 3DES and SHA1 (with group 2 for DH).

PS : I have done the same tests with an IPSec client like "Shrew Soft VPN
Client 2.2.1" and it's also possible to mount a VPN with algorithms others
than AES.

With the "ipsec auto --status", we obtained :

000 using kernel interface: netkey
000 "roadwarrior/0x1": 0.0.0.0/0===10.0.0.6
<10.0.0.6>[MS+S=C]...10.0.0.1---%any[+MC+S=C]===10.0.3.128/29; unrouted;
eroute owner: #0
000 "roadwarrior/0x1":     myip=10.0.3.1; hisip=unset;
000 "roadwarrior/0x1":   ike_life: 10800s; ipsec_life: 3600s; rekey_margin:
540s; rekey_fuzz: 100%; keyingtries: 0
000 "roadwarrior/0x1":   policy:
PSK+ENCRYPT+TUNNEL+DONTREKEY+MODECFGPULL+!IKEv1+IKEv2ALLOW+IKEv2Init+SAREFTRACK+lKOD+rKOD;
prio: 0,29; interface: eth0;
000 "roadwarrior/0x1":   dpd: action:clear; delay:60; timeout:300;
000 "roadwarrior/0x1":   newest ISAKMP SA: #0; newest IPsec SA: #0;
000 "roadwarrior/0x1":   aliases: roadwarrior
000 "roadwarrior/0x1":   IKE algorithms wanted:
AES_CBC(7)_128-SHA1(2)_000-MODP2048(14); flags=-strict
000 "roadwarrior/0x1":   IKE algorithms found:
AES_CBC(7)_128-SHA1(2)_160-MODP2048(14)
000 "roadwarrior/0x1":   ESP algorithms wanted: AES(12)_128-SHA1(2)_000;
pfsgroup=MODP2048(14); flags=-strict
000 "roadwarrior/0x1":   ESP algorithms loaded: AES(12)_128-SHA1(2)_160

We could find here the algorithms defined in the ipsec.conf file.

But, as defines in the ipsec.conf manual page :
"IKE encryption/authentication algorithm to be used for the connection
(phase 1 aka ISAKMP SA). The format is *"cipher-hash;modpgroup,
cipher-hash;modpgroup, ..."* Any left out option will be filled in with all
allowed default options. Multiple proposals are separated by a comma. If an
*ike=* line is specified, no other received proposals will be accepted."

So, I don't understand why it's possible to use 3DES as described in the
ike-scan results.

Do you have any idea ?

Thanks in advance !

Gilles MARION

PS : Sorry for my poor english ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openswan.org/pipermail/users/attachments/20130701/969bdc7f/attachment.html>