[Openswan Users] phase2alg confusedly
Nick Howitt
n1ck.h0w1tt at gmail.com
Fri Jul 20 09:27:15 EDT 2012
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