[Openswan Users] IKE algorithms choice

[Leto]

it is fine. the Ike scan starts a new blanc negotiation with no limits. your auto status shows aes and strict, so 3des would get refused

sent from a tiny device 

On 2013-07-01, at 9:22, Gilles MARION <psiouf2 at gmail.com> wrote:

> 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 ;)
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Users at lists.openswan.org
> https://lists.openswan.org/mailman/listinfo/users
> Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
> Building and Integrating Virtual Private Networks with Openswan:
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openswan.org/pipermail/users/attachments/20130701/b10836bc/attachment.html>