Project

General

Profile

Issue #1334

Updated by Tobias Brunner over 6 years ago

Hi,

I used two strongswan5.3.5 as initiator and responder.
pc1----DUT1-----------------DUT2----pc2
(to reproduce quickly ,we set the ikelifetime and lifetime as short as possible)

DUT1:initiator
remote peer:172.32.1.20
ikelifetime=300s
lifetime=150s

DUT2:responder
remote peer:0.0.0.0
ikelifetime=300s
lifetime=150s

At the start, the IKE_SA and the CHILD_SA can established normally like this:
<pre>
Connections:
@Connections:
test_ini: 172.32.1.100...172.32.1.20 IKEv1, dpddelay=10s
test_ini: local: [172.32.1.100] uses pre-shared key authentication
test_ini: remote: [172.32.1.20] uses pre-shared key authentication
test_ini: child: 192.168.1.0/24 === 192.168.0.0/24 TUNNEL, dpdaction=restart
Security Associations (1 up, 0 connecting):
test_ini[1]: ESTABLISHED 3 seconds ago, 172.32.1.100[172.32.1.100]...172.32.1.20[172.32.1.20]
test_ini[1]: IKEv1 SPIs: 2af0f37f10a91f53_i* adba57e03b4bfe84_r, pre-shared key reauthentication in 4 minutes
test_ini[1]: IKE proposal: 3DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024
test_ini{1}: INSTALLED, TUNNEL, reqid 1, ESP SPIs: cb7971b3_i cc475099_o
test_ini{1}: 3DES_CBC/HMAC_MD5_96, 0 bytes_i, 0 bytes_o, rekeying in 117 seconds
test_ini{1}: 192.168.1.0/24 === 192.168.0.0/24
</pre>
192.168.0.0/24@

after several minutes, there is another duplicated tunnel.Sometimes, the duplicated tunnel will disappear but sometimes it won't.
<pre>
Connections:
@Connections:
test_ini: 172.32.1.100...172.32.1.20 IKEv1, dpddelay=10s
test_ini: local: [172.32.1.100] uses pre-shared key authentication
test_ini: remote: [172.32.1.20] uses pre-shared key authentication
test_ini: child: 192.168.1.0/24 === 192.168.0.0/24 TUNNEL, dpdaction=restart
Security Associations (2 up, 0 connecting):
test_ini[5]: ESTABLISHED 3 minutes ago, 172.32.1.100[172.32.1.100]...172.32.1.20[172.32.1.20]
test_ini[5]: IKEv1 SPIs: 5db344aa30722c0d_i 36fb0f4dbfe100ef_r*, pre-shared key reauthentication in 39 seconds
test_ini[5]: IKE proposal: 3DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024
test_ini{9}: INSTALLED, TUNNEL, reqid 1, ESP SPIs: cd9f7cd4_i c3d7699a_o
test_ini{9}: 3DES_CBC/HMAC_MD5_96, 0 bytes_i, 0 bytes_o, rekeying in 68 seconds
test_ini{9}: 192.168.1.0/24 === 192.168.0.0/24
test_ini[4]: ESTABLISHED 3 minutes ago, 172.32.1.100[172.32.1.100]...172.32.1.20[172.32.1.20]
test_ini[4]: IKEv1 SPIs: 4d13d9b46230805a_i* 5dfe42fb1840dd97_r, pre-shared key reauthentication in 39 seconds
test_ini[4]: IKE proposal: 3DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024
test_ini{8}: INSTALLED, TUNNEL, reqid 1, ESP SPIs: c2eb6d69_i c103ec96_o
test_ini{8}: 3DES_CBC/HMAC_MD5_96, 0 bytes_i, 0 bytes_o, rekeying in 68 seconds
test_ini{8}: 192.168.1.0/24 === 192.168.0.0/24
</pre>
192.168.0.0/24@

The responder's log:
<pre> @
Jan 1 00:27:56 46[IKE] <4> received XAuth vendor ID
Jan 1 00:27:56 46[IKE] <4> received DPD vendor ID
Jan 1 00:27:56 46[IKE] <4> received NAT-T (RFC 3947) vendor ID
Jan 1 00:27:56 46[IKE] <4> received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
Jan 1 00:27:56 46[IKE] <4> 172.32.1.100 is initiating a Main Mode IKE_SA
Jan 1 00:27:56 38[IKE] <test_res|3> initiator did not reauthenticate as requested
Jan 1 00:27:56 38[IKE] <test_res|3> reauthenticating IKE_SA test_res[3] actively
Jan 1 00:27:56 38[IKE] <test_res|3> initiating Main Mode IKE_SA test_res[5] to 172.32.1.100
Jan 1 00:27:56 47[IKE] <test_res|5> received XAuth vendor ID
Jan 1 00:27:56 47[IKE] <test_res|5> received DPD vendor ID
Jan 1 00:27:56 47[IKE] <test_res|5> received NAT-T (RFC 3947) vendor ID
Jan 1 00:27:56 03[CFG] <4> looking for pre-shared key peer configs matching 172.32.1.20...172.32.1.100[172.32.1.100]
Jan 1 00:27:56 03[CFG] <4> selected peer config "test_res"
Jan 1 00:27:56 03[IKE] <test_res|4> IKE_SA test_res[4] established between 172.32.1.20[172.32.1.20]...172.32.1.100[172.32.1.100]
Jan 1 00:27:56 03[IKE] <test_res|4> scheduling reauthentication in 270s
Jan 1 00:27:56 03[IKE] <test_res|4> maximum IKE_SA lifetime 300s
Jan 1 00:27:56 02[IKE] <test_res|5> IKE_SA test_res[5] established between 172.32.1.20[172.32.1.20]...172.32.1.100[172.32.1.100]
Jan 1 00:27:56 02[IKE] <test_res|5> scheduling reauthentication in 270s
Jan 1 00:27:56 02[IKE] <test_res|5> maximum IKE_SA lifetime 300s
</pre> @

The initiator's log:
<pre>
Jan
@Jan 1 00:39:04 46[IKE] <test_ini|1> sending DPD request
Jan 1 00:39:14 54[IKE] <test_ini|1> sending DPD request
Jan 1 00:39:14 19[IKE] <test_ini|1> reauthenticating IKE_SA test_ini[1]
Jan 1 00:39:14 19[IKE] <test_ini|1> initiating Main Mode IKE_SA test_ini[2] to 172.32.1.20
Jan 1 00:39:14 09[IKE] <3> received XAuth vendor ID
Jan 1 00:39:14 09[IKE] <3> received DPD vendor ID
Jan 1 00:39:14 09[IKE] <3> received NAT-T (RFC 3947) vendor ID
Jan 1 00:39:14 09[IKE] <3> received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
Jan 1 00:39:14 09[IKE] <3> 172.32.1.20 is initiating a Main Mode IKE_SA
Jan 1 00:39:14 36[IKE] <test_ini|2> received XAuth vendor ID
Jan 1 00:39:14 36[IKE] <test_ini|2> received DPD vendor ID
Jan 1 00:39:14 36[IKE] <test_ini|2> received NAT-T (RFC 3947) vendor ID
Jan 1 00:39:14 11[CFG] <3> looking for pre-shared key peer configs matching 172.32.1.100...172.32.1.20[172.32.1.20]
Jan 1 00:39:14 11[CFG] <3> selected peer config "test_ini"
Jan 1 00:39:14 11[IKE] <test_ini|3> IKE_SA test_ini[3] established between 172.32.1.100[172.32.1.100]...172.32.1.20[172.32.1.20]
Jan 1 00:39:14 11[IKE] <test_ini|3> scheduling reauthentication in 270s
Jan 1 00:39:14 11[IKE] <test_ini|3> maximum IKE_SA lifetime 300s
Jan 1 00:39:14 15[IKE] <test_ini|2> IKE_SA test_ini[2] established between 172.32.1.100[172.32.1.100]...172.32.1.20[172.32.1.20]
Jan 1 00:39:14 15[IKE] <test_ini|2> scheduling reauthentication in 270s
Jan 1 00:39:14 15[IKE] <test_ini|2> maximum IKE_SA lifetime 300s
</pre> @

From the log,it seems that the initiator and the responder reauthenticating the IKE_SA at the same time, so there is another duplicated tunnel,
Normally the initiator can detect the duplicated tunnel and delete it. *But sometimes the initiator can't detect the duplicated tunnel*,so there are two same tunnels.
By the way, the communication is still OK.

Is this problem a known issue? Or anything wrong with my ipsec.conf(in the attachment)?

Back