<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
I have a vague feeling that one of the fixes applied sometime ago
was to remove the strict flag. I never used it as I could control
the algorithm from my 3rd party router and Openswan would accept
anything I gave it.<br>
<br>
<div class="moz-cite-prefix">On 01/07/2013 17:14, Leto wrote:<br>
</div>
<blockquote
cite="mid:BA49E433-DC27-47CF-BF6F-7DD77C27C767@gmail.com"
type="cite">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div>there was a strict flag bug. I don't know if the new openswan
maintainer applied it or not. <br>
<br>
sent from a tiny device </div>
<div><br>
On 2013-07-01, at 11:36, Nick Howitt <<a
moz-do-not-send="true" href="mailto:n1ck.h0w1tt@gmail.com">n1ck.h0w1tt@gmail.com</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<p>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.</p>
<p>Regards,</p>
<p>Nick</p>
<p>On 2013-07-01 16:10, Leto wrote:</p>
<blockquote type="cite" style="padding-left:5px;
border-left:#1010ff 2px solid; margin-left:5px"><!-- html ignored --><!-- head ignored --><!-- meta ignored -->
<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 </div>
<div><br>
On 2013-07-01, at 9:22, Gilles MARION <<a
moz-do-not-send="true" href="mailto:psiouf2@gmail.com">psiouf2@gmail.com</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite" style="padding-left:5px;
border-left:#1010ff 2px solid; margin-left:5px">
<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 =>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)</div>
<div> </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
moz-do-not-send="true"
href="http://www.nta-monitor.com/tools/ike-scan/">http://www.nta-monitor.com/tools/ike-scan/</a>)<br>
10.4.0.6 Main Mode Handshake returned<br>
HDR=(CKY-R=f234e754af4f059c)<br>
SA=(Enc=3DES Hash=SHA1 Auth=PSK
Group=2:modp1024 LifeType=Seconds
LifeDuration(4)=0x00007080)<br>
VID=4f4568794c64414365636661<br>
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.</div>
<div> </div>
</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
moz-do-not-send="true"
href="http://0.0.0.0/0===10.0.0.6">0.0.0.0/0===10.0.0.6</a><10.0.0.6>[MS+S=C]...10.0.0.1---%any[+MC+S=C]===<a
moz-do-not-send="true"
href="http://10.0.3.128/29">10.0.3.128/29</a>;
unrouted; eroute owner: #0<br>
000 "roadwarrior/0x1": myip=10.0.3.1;
hisip=unset;<br>
000 "roadwarrior/0x1": ike_life: 10800s;
ipsec_life: 3600s; rekey_margin: 540s;
rekey_fuzz: 100%; keyingtries: 0 <br>
000 "roadwarrior/0x1": policy:
PSK+ENCRYPT+TUNNEL+DONTREKEY+MODECFGPULL+!IKEv1+IKEv2ALLOW+IKEv2Init+SAREFTRACK+lKOD+rKOD;
prio: 0,29; interface: eth0; <br>
000 "roadwarrior/0x1": dpd:
action:clear; delay:60; timeout:300; <br>
000 "roadwarrior/0x1": newest ISAKMP SA:
#0; newest IPsec SA: #0; <br>
000 "roadwarrior/0x1": aliases:
roadwarrior <br>
000 "roadwarrior/0x1": IKE algorithms
wanted:
AES_CBC(7)_128-SHA1(2)_000-MODP2048(14);
flags=-strict<br>
000 "roadwarrior/0x1": IKE algorithms
found:
AES_CBC(7)_128-SHA1(2)_160-MODP2048(14)<br>
000 "roadwarrior/0x1": ESP algorithms
wanted: AES(12)_128-SHA1(2)_000;
pfsgroup=MODP2048(14); flags=-strict<br>
000 "roadwarrior/0x1": 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.</div>
<div> </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 <em>"cipher-hash;modpgroup,
cipher-hash;modpgroup, ..."</em> Any
left out option will be filled in with all
allowed default options. Multiple
proposals are separated by a comma. If an
<strong>ike=</strong> 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 ;)</div>
<div><br>
<br>
<br>
<br>
<br>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<blockquote type="cite" style="padding-left:5px;
border-left:#1010ff 2px solid; margin-left:5px">
<div><span>_______________________________________________</span><br>
<span><a moz-do-not-send="true"
href="mailto:Users@lists.openswan.org">Users@lists.openswan.org</a></span><br>
<span><a moz-do-not-send="true"
href="https://lists.openswan.org/mailman/listinfo/users">https://lists.openswan.org/mailman/listinfo/users</a></span><br>
<span>Micropayments: <a moz-do-not-send="true"
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 moz-do-not-send="true"
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></div>
</blockquote>
<!-- html ignored --><br>
<pre>_______________________________________________
<a moz-do-not-send="true" href="mailto:Users@lists.openswan.org">Users@lists.openswan.org</a>
<a moz-do-not-send="true" href="https://lists.openswan.org/mailman/listinfo/users">https://lists.openswan.org/mailman/listinfo/users</a>
Micropayments: <a moz-do-not-send="true" href="https://flattr.com/thing/38387/IPsec-for-Linux-made-easy">https://flattr.com/thing/38387/IPsec-for-Linux-made-easy</a>
Building and Integrating Virtual Private Networks with Openswan:
<a moz-do-not-send="true" 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>
</pre>
</blockquote>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span><a moz-do-not-send="true"
href="mailto:Users@lists.openswan.org">Users@lists.openswan.org</a></span><br>
<span><a moz-do-not-send="true"
href="https://lists.openswan.org/mailman/listinfo/users">https://lists.openswan.org/mailman/listinfo/users</a></span><br>
<span>Micropayments: <a moz-do-not-send="true"
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 moz-do-not-send="true"
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>
</blockquote>
<br>
</body>
</html>