[Openswan Users] phase2alg confusedly

Ozai ozai.tien at gmail.com
Mon Jul 23 01:59:40 EDT 2012


Dear Sirs,

Thank's for your responses.
I do not know that remote endpoint support Phase2 auto negotiation or not.I 
found the openswan phase1 negotiation also have the same situation.So I 
adjust the configuration as below.It seem to work fine.My openswan version 
is 2.6.38. Is it the known issue on this version?So do I need to add 
character '!' into my ipsec.conf necessarily?

<configuration>
ike=3des-md5;modp1024!
phase2alg=aes256-hmac_sha1!


Best Regards,
Ozai
----- Original Message ----- 
From: "Nick Howitt" <n1ck.h0w1tt at gmail.com>
To: "Daniel Cave" <dan.cave at me.com>
Cc: "Ozai" <ozai.tien at gmail.com>; <users at lists.openswan.org>
Sent: Friday, July 20, 2012 9:27 PM
Subject: Re: [Openswan Users] phase2alg confusedly


>I believe there is also an issue (minor) with Openswan and the docs are 
>slightly wrong. The docs say that if you specify an algorithm or list of 
>algorithms only those will be used. I've shown in the past that is not the 
>case. I think you can force it with a ! either before or after the 
>algorithm (but I can't remember which). I had the issue with phase1 where I 
>tried forcing AES128 but the connection negotiated 3DES as that was all the 
>third party remote router supported. In my experimenting I forced the 
>algorithm with a ! and got no connection (which was when I found out the 
>remote router only supported AES128 for phase2).
> Paul Wouters indicated they might do something about it sometime.
> If you want, have a look at your logs to see what was finally negotiated 
> for the two phases.
>
> Regards,
>
> Nick
>
> On 20/07/2012 14:15, Daniel Cave wrote:
>> Hi Ozai.
>>
>> What you're seeing is that (I believe)  that once you've presented a 
>> matching Phase 1 key exchange at authentication level using the same 
>> algorithm , the remote endpoint appears to have auto-negoticated Phase 2 
>> using aes256-hmac_Sha1 which your OpenSwan server has presented so both 
>> ends match.
>>
>> Do you know which device the remote end point is?  It maybe that your 
>> remote endpoint support Phase2 auto negotiation -  if you look at your 
>> logs again, you'll see the IKE  & ESP  handshaking and see that it's 
>> connected correctly.
>>
>> Hope this helps
>>
>> Dan
>>
>>   On 20 Jul 2012, at 11:25, Ozai wrote:
>>
>>> Dear Sirs,
>>>
>>> I  used the openswan to connect another system.The algorithm are as 
>>> below.I am very confused.Why the tunnel can be up and we can ping peer 
>>> to peer PC.
>>> Originally I think if use different algorithms,the tunnel should not 
>>> work.But the final result is different.I have no idea in this 
>>> question.Please help very thank's.
>>>
>>> <openswan>
>>> phase1=3des-md5;modp1024
>>> phase2= aes256-hmac_sha1
>>>
>>> <other system>
>>> phase1=3des-md5;modp1024
>>> phase2= 3des-md5;modp1024
>>>
>>> Best Regards,
>>> Ozai
>>>
>>>
>>> # cat ipsec.conf
>>> config setup
>>>                nat_traversal=no
>>>                oe=off
>>>                protostack=netkey
>>>                interfaces=%defaultroute
>>>
>>> conn t1
>>>                left=172.17.21.88
>>>                leftsubnet=192.168.1.0/24
>>>                rightsubnet=192.168.6.0/24
>>>                connaddrfamily=ipv4
>>>                right=172.17.21.87
>>>                pfs=yes
>>>                keyexchange=ike
>>>                ike=3des-md5;modp1024
>>>                salifetime=480m
>>>                phase2=esp
>>>                phase2alg=aes256-hmac_sha1
>>>                ikelifetime=60m
>>>                type=tunnel
>>>                authby=secret
>>>                auto=add
>>> #
>>>
>>> # ipsec auto --status
>>> 000 using kernel interface: netkey
>>> 000 interface lo/lo ::1
>>> 000 interface lo/lo 127.0.0.1
>>> 000 interface br0/br0 192.168.1.254
>>> 000 interface eth0.1/eth0.1 172.17.21.88
>>> 000 %myid = (none)
>>> 000 debug none
>>> 000
>>> 000 virtual_private (%priv):
>>> 000 - allowed 0 subnets:
>>> 000 - disallowed 0 subnets:
>>> 000 WARNING: Either virtual_private= is not specified, or there is a 
>>> syntax
>>> 000          error in that line. 'left/rightsubnet=vhost:%priv' will not 
>>> work!
>>> 000 WARNING: Disallowed subnets in virtual_private= is empty. If you 
>>> have
>>> 000          private address space in internal use, it should be 
>>> excluded!
>>> 000
>>> 000 algorithm ESP encrypt: id=2, name=ESP_DES, ivlen=8, keysizemin=64, 
>>> keysizema
>>> x=64
>>> 000 algorithm ESP encrypt: id=3, name=ESP_3DES, ivlen=8, keysizemin=192, 
>>> keysize
>>> max=192
>>> 000 algorithm ESP encrypt: id=11, name=ESP_NULL, ivlen=0, keysizemin=0, 
>>> keysizem
>>> ax=0
>>> 000 algorithm ESP encrypt: id=12, name=ESP_AES, ivlen=8, keysizemin=128, 
>>> keysize
>>> max=256
>>> 000 algorithm ESP encrypt: id=14, name=ESP_AES_CCM_A, ivlen=8, 
>>> keysizemin=128, k
>>> eysizemax=256
>>> 000 algorithm ESP encrypt: id=15, name=ESP_AES_CCM_B, ivlen=8, 
>>> keysizemin=128, k
>>> eysizemax=256
>>> 000 algorithm ESP encrypt: id=16, name=ESP_AES_CCM_C, ivlen=8, 
>>> keysizemin=128, k
>>> eysizemax=256
>>> 000 algorithm ESP encrypt: id=18, name=ESP_AES_GCM_A, ivlen=8, 
>>> keysizemin=128, k
>>> eysizemax=256
>>> 000 algorithm ESP encrypt: id=19, name=ESP_AES_GCM_B, ivlen=8, 
>>> keysizemin=128, k
>>> eysizemax=256
>>> 000 algorithm ESP encrypt: id=20, name=ESP_AES_GCM_C, ivlen=8, 
>>> keysizemin=128, k
>>> eysizemax=256
>>> 000 algorithm ESP auth attr: id=1, name=AUTH_ALGORITHM_HMAC_MD5, 
>>> keysizemin=128,
>>> keysizemax=128
>>> 000 algorithm ESP auth attr: id=2, name=AUTH_ALGORITHM_HMAC_SHA1, 
>>> keysizemin=160
>>> , keysizemax=160
>>> 000 algorithm ESP auth attr: id=251, name=AUTH_ALGORITHM_NULL_KAME, 
>>> keysizemin=0
>>> , keysizemax=0
>>> 000
>>> 000 algorithm IKE encrypt: id=0, name=(null), blocksize=16, 
>>> keydeflen=131
>>> 000 algorithm IKE encrypt: id=5, name=OAKLEY_3DES_CBC, blocksize=8, 
>>> keydeflen=19
>>> 2
>>> 000 algorithm IKE encrypt: id=7, name=OAKLEY_AES_CBC, blocksize=16, 
>>> keydeflen=12
>>> 8
>>> 000 algorithm IKE hash: id=1, name=OAKLEY_MD5, hashsize=16
>>> 000 algorithm IKE hash: id=2, name=OAKLEY_SHA1, hashsize=20
>>> 000 algorithm IKE hash: id=4, name=OAKLEY_SHA2_256, hashsize=32
>>> 000 algorithm IKE hash: id=6, name=OAKLEY_SHA2_512, hashsize=64
>>> 000 algorithm IKE dh group: id=2, name=OAKLEY_GROUP_MODP1024, bits=1024
>>> 000 algorithm IKE dh group: id=5, name=OAKLEY_GROUP_MODP1536, bits=1536
>>> 000 algorithm IKE dh group: id=14, name=OAKLEY_GROUP_MODP2048, bits=2048
>>> 000 algorithm IKE dh group: id=15, name=OAKLEY_GROUP_MODP3072, bits=3072
>>> 000 algorithm IKE dh group: id=16, name=OAKLEY_GROUP_MODP4096, bits=4096
>>> 000 algorithm IKE dh group: id=17, name=OAKLEY_GROUP_MODP6144, bits=6144
>>> 000 algorithm IKE dh group: id=18, name=OAKLEY_GROUP_MODP8192, bits=8192
>>> 000 algorithm IKE dh group: id=22, name=OAKLEY_GROUP_DH22, bits=1024
>>> 000 algorithm IKE dh group: id=23, name=OAKLEY_GROUP_DH23, bits=2048
>>> 000 algorithm IKE dh group: id=24, name=OAKLEY_GROUP_DH24, bits=2048
>>> 000
>>> 000 stats db_ops: {curr_cnt, total_cnt, maxsz} :context={0,5,36} 
>>> trans={0,5,360}
>>> attrs={0,5,480}
>>> 000
>>> 000 "t1": 
>>> 192.168.1.0/24===172.17.21.88<172.17.21.88>...172.17.21.87<172.17.21.8
>>> 7>===192.168.6.0/24; erouted; eroute owner: #4
>>> 000 "t1":     myip=unset; hisip=unset;
>>> 000 "t1":   ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; 
>>> rekey_fuzz:
>>> 100%; keyingtries: 0
>>> 000 "t1":   policy: 
>>> PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW+SAREFTRACK+lKOD+rKOD; p
>>> rio: 24,24; interface: eth0.1;
>>> 000 "t1":   newest ISAKMP SA: #3; newest IPsec SA: #4;
>>> 000 "t1":   IKE algorithms wanted: 
>>> 3DES_CBC(5)_000-MD5(1)_000-MODP1024(2); flags
>>> =-strict
>>> 000 "t1":   IKE algorithms found: 
>>> 3DES_CBC(5)_192-MD5(1)_128-MODP1024(2)
>>> 000 "t1":   IKE algorithm newest: 3DES_CBC_192-MD5-MODP1024
>>> 000 "t1":   ESP algorithms wanted: AES(12)_256-SHA1(2)_000; 
>>> flags=-strict
>>> 000 "t1":   ESP algorithms loaded: AES(12)_256-SHA1(2)_160
>>> 000 "t1":   ESP algorithm newest: 3DES_000-HMAC_MD5; pfsgroup=<Phase1>
>>> 000
>>> 000 #7: "t1":500 STATE_QUICK_I1 (sent QI1, expecting QR1); 
>>> EVENT_RETRANSMIT in 3
>>> 1s; lastdpd=-1s(seq in:0 out:0); idle; import:admin initiate
>>> 000 #4: "t1":500 STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE 
>>> in 3122
>>> s; newest IPSEC; eroute owner; isakmp#3; idle; import:not set
>>> 000 #4: "t1" esp.7756b716 at 172.17.21.87 esp.454085f8 at 172.17.21.88 ref=0 
>>> refhim=42
>>> 94901761
>>> 000 #3: "t1":500 STATE_MAIN_R3 (sent MR3, ISAKMP SA established); 
>>> EVENT_SA_REPLA
>>> CE in 3121s; newest ISAKMP; lastdpd=8s(seq in:0 out:0); idle; 
>>> import:admin initiate
>>>
>>> _______________________________________________
>>> 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
>> Regards
>>
>> Dan.
>>
>> _______________________________________________
>> 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
> 



More information about the Users mailing list