S2S IPSEC creates connections with duplicate reqids
-
We have a S2S VPN with one subnet on our side and multiple subnets on the other side. Everything works OK but sometimes when a connection (Phase2) is reestablished for subnet A it gets a reqid that is already in use for a subnet B. For the reestablished connection new SAD and SPD entries are created. But because the new SAD entry has the same ID as another SAD entry created earlier for subnet B the SPD for subnet B starts pointing to the new SAD. The result is that packets sent to subnet B have SPI of subnet A and are dropped by the other side.
When this happens swanctl --list-sas provides this output
con2: #118, ESTABLISHED, IKEv1, e39d2415353ed8a1_i* 4cfca4bfde292a82_r
local '194.37.12.73' @ 194.37.12.73[500]
remote '103.32.58.148' @ 103.32.58.148[500]
AES_CBC-256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
established 15298s ago, reauth in 54025s
con2_23: #2531, reqid 1, INSTALLED, TUNNEL, ESP:AES_CBC-256/HMAC_SHA1_96/MODP_1536
installed 23624s ago, rekeying in 598s, expires in 5176s
in c00720e5, 6812691 bytes, 157869 packets, 105s ago
out f80b7431, 1264181712 bytes, 890636 packets, 121s ago
local 172.28.194.0/24|/0
remote 192.168.255.200/32|/0
con2_6: #2532, reqid 9, INSTALLED, TUNNEL, ESP:AES_CBC-256/HMAC_SHA1_96/MODP_1536
installed 15161s ago, rekeying in 8829s, expires in 13639s
in cf66b7e1, 173786 bytes, 372 packets, 1121s ago
out 2ef1316e, 59728 bytes, 334 packets, 1087s ago
local 172.28.194.0/24|/0
remote 10.148.134.0/23|/0
con2_28: #2533, reqid 2, INSTALLED, TUNNEL, ESP:AES_CBC-256/HMAC_SHA1_96/MODP_1536
installed 13541s ago, rekeying in 11534s, expires in 15259s
in cbf320d1, 22596 bytes, 287 packets, 133s ago
out 6c69b7f0, 41608 bytes, 287 packets, 134s ago
local 172.28.194.0/24|/0
remote 172.19.0.0/16|/0
con2_29: #2534, reqid 3, INSTALLED, TUNNEL, ESP:AES_CBC-256/HMAC_SHA1_96/MODP_1536
installed 13125s ago, rekeying in 10747s, expires in 15675s
in c0726f32, 128365 bytes, 1315 packets, 104s ago
out 32f5b5de, 2420928 bytes, 2592 packets, 105s ago
local 172.28.194.0/24|/0
remote 172.20.0.0/16|/0
con2_5: #2535, reqid 8, INSTALLED, TUNNEL, ESP:AES_CBC-256/HMAC_SHA1_96/MODP_1536
installed 11585s ago, rekeying in 12052s, expires in 17215s
in ca148ea0, 0 bytes, 0 packets, 44354s ago
out 2e6fba54, 0 bytes, 0 packets
local 172.28.194.0/24|/0
remote 172.24.0.0/16|/0
con2_30: #2537, reqid 4, INSTALLED, TUNNEL, ESP:AES_CBC-256/HMAC_SHA1_96/MODP_1536
installed 7372s ago, rekeying in 16235s, expires in 21428s
in c9640198, 132805 bytes, 2578 packets, 3258s ago
out e72c8612, 14720200 bytes, 9593 packets, 3259s ago
local 172.28.194.0/24|/0
remote 172.23.0.0/16|/0
con2_31: #2538, reqid 1, INSTALLED, TUNNEL, ESP:AES_CBC-256/HMAC_SHA1_96/MODP_1536
installed 144s ago, rekeying in 24677s, expires in 28656s
in cce5aed6, 1702802 bytes, 39720 packets, 0s ago
out a82aadbe, 667066648 bytes, 447853 packets, 0s ago
local 172.28.194.0/24|/0
remote 10.192.0.0/16|/0The conflicting connections are con2_23 and the newly reestablished con2_31. From the log we know that it was reestablished by a request sent by the other side but not sure if it matters. It happens rarely. In the log we have other reconnections initiated by the other side but they have not created reqid duplicates.
Is it a good enough description of the problem? Is it a known issue? At the moment we can fix that by restarting the VPN but we would like to prevent that from occurring.
-
con2_23contains a remote network of192.168.255.200/32|/0, andcon2_31contains a remote network of10.192.0.0/16|/0.Whatever's happening there is your clue.
-
@tinfoilmatt Both the connections use the same reqid. And that is the problem because the reqid is used for creating SAD/SPD entries. The result is that there are two SPD entries pointing to the same SAD entry which makes the formerly established connection not working because there are wrong encryption values used.
