<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)<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 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.<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><10.0.0.6>[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": 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.<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>