[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