[Openswan Users] [IPv6]Interoperability issue between openswan and Racoon2

Yatong Cui yacui at redhat.com
Mon Oct 18 01:03:20 EDT 2010


Hi,

Thanks a lot for your kind suggestion,i've got more debug messages.
Here is more info about this failed connection.

1 On RHEL6.0
=============
[root at TAR-EN1 ~]# ipsec auto --status
no default routes detected
000 using kernel interface: netkey
000 interface lo/lo ::1
000 interface eth0/eth0 2001:db8:1:1:20c:29ff:fe0c:3ed1
000 interface lo/lo 127.0.0.1
000 interface eth0/eth0 192.168.1.10
000 %myid = (none)
000 debug raw+crypt+parsing+emitting+control+lifecycle+klips+dns+oppo+controlmore+pfkey+nattraversal+x509
000  
000 virtual_private (%priv):
000 - allowed 0 subnets: 
000 - disallowed 0 subnets: 
000 WARNING: Either virtual_private= was not specified, or there was a syntax 
000          error in that line. 'left/rightsubnet=%priv' will not work!
000  
000 algorithm ESP encrypt: id=2, name=ESP_DES, ivlen=8, keysizemin=64, keysizemax=64
000 algorithm ESP encrypt: id=3, name=ESP_3DES, ivlen=8, keysizemin=192, keysizemax=192
000 algorithm ESP encrypt: id=6, name=ESP_CAST, ivlen=8, keysizemin=40, keysizemax=128
000 algorithm ESP encrypt: id=7, name=ESP_BLOWFISH, ivlen=8, keysizemin=40, keysizemax=448
000 algorithm ESP encrypt: id=11, name=ESP_NULL, ivlen=0, keysizemin=0, keysizemax=0
000 algorithm ESP encrypt: id=12, name=ESP_AES, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=13, name=ESP_AES_CTR, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=14, name=ESP_AES_CCM_A, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=15, name=ESP_AES_CCM_B, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=16, name=ESP_AES_CCM_C, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=18, name=ESP_AES_GCM_A, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=19, name=ESP_AES_GCM_B, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=20, name=ESP_AES_GCM_C, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=22, name=ESP_CAMELLIA, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=252, name=ESP_SERPENT, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=253, name=ESP_TWOFISH, ivlen=8, keysizemin=128, keysizemax=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=5, name=AUTH_ALGORITHM_HMAC_SHA2_256, keysizemin=256, keysizemax=256
000 algorithm ESP auth attr: id=8, name=AUTH_ALGORITHM_HMAC_RIPEMD, keysizemin=160, keysizemax=160
000 algorithm ESP auth attr: id=9, name=AUTH_ALGORITHM_AES_CBC, keysizemin=128, keysizemax=128
000 algorithm ESP auth attr: id=251, name=(null), keysizemin=0, keysizemax=0
000  
000 algorithm IKE encrypt: id=0, name=(null), blocksize=16, keydeflen=131
000 algorithm IKE encrypt: id=3, name=OAKLEY_BLOWFISH_CBC, blocksize=8, keydeflen=128
000 algorithm IKE encrypt: id=5, name=OAKLEY_3DES_CBC, blocksize=8, keydeflen=192
000 algorithm IKE encrypt: id=7, name=OAKLEY_AES_CBC, blocksize=16, keydeflen=128
000 algorithm IKE encrypt: id=65004, name=OAKLEY_SERPENT_CBC, blocksize=16, keydeflen=128
000 algorithm IKE encrypt: id=65005, name=OAKLEY_TWOFISH_CBC, blocksize=16, keydeflen=128
000 algorithm IKE encrypt: id=65289, name=OAKLEY_TWOFISH_CBC_SSH, blocksize=16, keydeflen=128
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,2,64} trans={0,2,2304} attrs={0,2,1536} 
000  
000 "TAHI": 2001:db8:1:1:20c:29ff:fe0c:3ed1<2001:db8:1:1:20c:29ff:fe0c:3ed1>[+S=C]...2001:db8:1:2:20c:29ff:fe4d:489<2001:db8:1:2:20c:29ff:fe4d:489>[+S=C]; unrouted; eroute owner: #0
000 "TAHI":     myip=unset; hisip=unset;
000 "TAHI":   ike_life: 3600s; ipsec_life: 1200s; rekey_margin: 180s; rekey_fuzz: 100%; keyingtries: 1
000 "TAHI":   policy: PSK+ENCRYPT+PFS+UP+IKEv2ALLOW+IKEv2Init+lKOD+rKOD; prio: 128,128; interface: eth0; 
000 "TAHI":   newest ISAKMP SA: #0; newest IPsec SA: #0; 
000 "TAHI":   IKE algorithms wanted: 3DES_CBC(5)_000-SHA1(2)-MODP1024(2); flags=-strict
000 "TAHI":   IKE algorithms found:  3DES_CBC(5)_192-SHA1(2)_160-2, 
000 "TAHI":   ESP algorithms wanted: 3DES(3)_000-SHA1(2); flags=-strict
000 "TAHI":   ESP algorithms loaded: 3DES(3)_192-SHA1(2)_160
000  
000 #2: "TAHI":500 STATE_PARENT_I2 (sent v2I2, expected v2R2); EVENT_v2_RETRANSMIT in 32s; nodpd; idle; import:admin initiate
000 #1: "TAHI":500 STATE_PARENT_I2 (sent v2I2, expected v2R2); EVENT_SA_REPLACE in 3562s; nodpd; idle; import:admin initiate
000  



2.On Freebsd8.1
================
[PROTO_WARN]: ikev2.c:1003:ikev2_check_new_request(): 0:2001:db8:1:2:20c:29ff:fe4d:489[500] - 2001:db8:1:1:20c:29ff:fe0c:3ed1[500]:0x284022f0:message to a nonexistent ike_sa

Except this message on the remote SSH login session,i also found another message on the console:
iked:[PROTO_ERR]:ikev2_auth.c:615:ikev2_verify():1:2001:db8:1:2:20c:29ff:fe4d:489[500] - 
2001:db8:1:1:20c:29ff:fe0c:3ed1[500]:0x28402348:authentication failure.

3.Analysis
================
So does it mean it's because the unmatching ID cause the connection crashes. My current ID configuration is 
1>on RHEL
        left=2001:db8:1:1:20c:29ff:fe0c:3ed1
        right=2001:db8:1:2:20c:29ff:fe4d:489
        leftid=2001:db8:1:1:20c:29ff:fe0c:3ed1
        rightid=2001:db8:1:2:20c:29ff:fe4d:489
2>on Freebsd 8.1
        my_id ipaddr 2001:db8:1:2:20c:29ff:fe4d:489;
        peers_id ipaddr 2001:db8:1:1:20c:29ff:fe0c:3ed1;

Is there anywhere else that i need to specify the ID they use.(Because the test specification states i have to use the ipaddr as the ID,so i cannot use the FQDN as the ID).

Many thanks for your reply in advance.




















More information about the Users mailing list