[Openswan Users] IKE algorithms choice

Mon Jul 1 16:14:10 UTC 2013

there was a strict flag bug. I don't know if the new openswan maintainer applied it or not. 

sent from a tiny device 

On 2013-07-01, at 11:36, Nick Howitt <n1ck.h0w1tt at gmail.com> wrote:

> I am not sure that is correct and the man pages do not descriibe the observed behaviour. Whenever I've tested, irrespective of what I've specified I've been able to make a connection with some other cipher and protocol. When I've queried this I've been told it is a bug and you have to use the strict flag (!) to enforce your policy. e.g, if I've specified 3des, sha1 and modp1024 I've been able to connect with aes256, sha1 and modp2048.
> 
> Regards,
> 
> Nick
> 
> On 2013-07-01 16:10, Leto wrote:
> 
>> 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
>> 
>> _______________________________________________
>> 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
> _______________________________________________
> 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/ad07d316/attachment.html>