<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>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<br><br>sent from a tiny device&nbsp;</div><div><br>On 2013-07-01, at 9:22, Gilles MARION &lt;<a href="mailto:psiouf2@gmail.com">psiouf2@gmail.com</a>&gt; wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div><div><div><div><div>Hello everybody,<br><br></div>I encountered a strange behavior with Openswan (I hope it's not due to a misconfiguration ;)<br><br></div><div>Below the version of Openswan used :<br>
openswan-2.6.32-20.el6_4.x86_64<br>(Kernel =&gt;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)<br></div><div><br></div>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 :<br>
<br>ike=aes128-sha1;modp2048<br>phase2alg=aes128-sha1;modp2048<br><br></div>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 :<br>
<br># ike-scan -M 10.4.0.6<br>Starting ike-scan 1.9 with 1 hosts (<a href="http://www.nta-monitor.com/tools/ike-scan/">http://www.nta-monitor.com/tools/ike-scan/</a>)<br>10.4.0.6&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Main Mode Handshake returned<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; HDR=(CKY-R=f234e754af4f059c)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; VID=4f4568794c64414365636661<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)<br><br>
We can see than the SA is defined with 3DES and SHA1 (with group 2 for DH).<br><br></div><div>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.<br>
</div><div></div><br></div>With the "ipsec auto --status", we obtained :<br><br>000 using kernel interface: netkey<br><div><div><div><div><div><div>000 "roadwarrior/0x1": <a href="http://0.0.0.0/0===10.0.0.6">0.0.0.0/0===10.0.0.6</a>&lt;10.0.0.6&gt;[MS+S=C]...10.0.0.1---%any[+MC+S=C]===<a href="http://10.0.3.128/29">10.0.3.128/29</a>; unrouted; eroute owner: #0<br>
000 "roadwarrior/0x1":&nbsp;&nbsp;&nbsp;&nbsp; myip=10.0.3.1; hisip=unset;<br>000 "roadwarrior/0x1":&nbsp;&nbsp; ike_life: 10800s; ipsec_life: 3600s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0 <br>000 "roadwarrior/0x1":&nbsp;&nbsp; policy: PSK+ENCRYPT+TUNNEL+DONTREKEY+MODECFGPULL+!IKEv1+IKEv2ALLOW+IKEv2Init+SAREFTRACK+lKOD+rKOD; prio: 0,29; interface: eth0; <br>
000 "roadwarrior/0x1":&nbsp;&nbsp; dpd: action:clear; delay:60; timeout:300; <br>000 "roadwarrior/0x1":&nbsp;&nbsp; newest ISAKMP SA: #0; newest IPsec SA: #0; <br>000 "roadwarrior/0x1":&nbsp;&nbsp; aliases: roadwarrior <br>
000 "roadwarrior/0x1":&nbsp;&nbsp; IKE algorithms wanted: AES_CBC(7)_128-SHA1(2)_000-MODP2048(14); flags=-strict<br>000 "roadwarrior/0x1":&nbsp;&nbsp; IKE algorithms found:&nbsp; AES_CBC(7)_128-SHA1(2)_160-MODP2048(14)<br>000 "roadwarrior/0x1":&nbsp;&nbsp; ESP algorithms wanted: AES(12)_128-SHA1(2)_000; pfsgroup=MODP2048(14); flags=-strict<br>
000 "roadwarrior/0x1":&nbsp;&nbsp; ESP algorithms loaded: AES(12)_128-SHA1(2)_160<br><br></div><div>We could find here the algorithms defined in the ipsec.conf file.<br></div><div><br></div><div>But, as defines in the ipsec.conf manual page :<br>
"IKE encryption/authentication algorithm to be used for the connection (phase 1 aka ISAKMP SA). The format is <i>"cipher-hash;modpgroup,
cipher-hash;modpgroup, ..."</i> Any left out option will be filled in with all allowed default options. Multiple proposals are separated by a comma. If an
<b>ike=</b> line is specified, no other received proposals will be accepted."<br><br></div><div>So, I don't understand why it's possible to use 3DES as described in the ike-scan results.<br><br></div><div>Do you have any idea ?<br>
<br></div><div>Thanks in advance !<br><br></div><div>Gilles MARION<br><br></div><div>PS : Sorry for my poor english ;)<br></div><div><br><br><br><br><br><br></div></div></div></div></div></div></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span><a href="mailto:Users@lists.openswan.org">Users@lists.openswan.org</a></span><br><span><a href="https://lists.openswan.org/mailman/listinfo/users">https://lists.openswan.org/mailman/listinfo/users</a></span><br><span>Micropayments: <a href="https://flattr.com/thing/38387/IPsec-for-Linux-made-easy">https://flattr.com/thing/38387/IPsec-for-Linux-made-easy</a></span><br><span>Building and Integrating Virtual Private Networks with Openswan:</span><br><span><a href="http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155">http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155</a></span><br></div></blockquote></body></html>