[strongSwan] Duplicate CHILD_SAs and DPD

[Heiko Wundram]

Hey all,

I'm currently seeing duplicate CHILD_SAs on long-running IPsec tunnels 
with strongSwan 5.3.3. The setup starts normally, but after some time 
both ends of the connection (the responder, which is on a fixed IP, and 
the initiator, which is on a dialup line) acquire additional CHILD_SAs 
for some of the connections between the two sides.

The general setup of the connection on the initiator:

conn %default
         # Default setup.
         keyexchange=ikev2
         authby=secret
         mobike=no
         keyingtries=%forever
         reauth=no
         compress=yes
         dpddelay=30
         dpdtimeout=120
         dpdaction=restart
         auto=start

The general setup of the connection on the responder:

conn %default
         # Default setup.
         keyexchange=ikev2
         authby=secret
         mobike=no
         keyingtries=%forever
         rekey=no
         reauth=no
         compress=yes
         dpddelay=30
         dpdtimeout=120
         dpdaction=clear
         auto=add

After two rekeyings, this is the result on the initiator:

uplink-v4[3]: ESTABLISHED 7 minutes ago, <host1>...<host2>
uplink-v4[3]: IKEv2 SPIs: de05552af21b451c_i* c6786a850fe62561_r, 
rekeying in 2 hours
uplink-v4[3]: IKE proposal: 
AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
mgmt-v6{19}:  INSTALLED, TUNNEL, reqid 4, ESP in UDP SPIs: c86174ee_i 
c675ddfc_o, IPCOMP CPIs: 842e_i ec4c_o
mgmt-v6{19}:  AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying 
in 40 minutes
mgmt-v6{19}:   fd92:2dff:d232:3f::/64 === fd92:2dff:d232::/64
uplink-v4{20}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c8cd26cf_i 
c8a3c75a_o, IPCOMP CPIs: e2aa_i 47f7_o
uplink-v4{20}:  AES_CBC_128/HMAC_SHA1_96, 661806322 bytes_i (531912 
pkts, 0s ago), 44307596 bytes_o (385286 pkts, 0s ago), rekeying in 35 
minutes
uplink-v4{20}:   10.252.16.0/20 === 0.0.0.0/0
uplink-v6{21}:  INSTALLED, TUNNEL, reqid 2, ESP in UDP SPIs: cdaabd88_i 
cf4ae731_o, IPCOMP CPIs: 961a_i b130_o
uplink-v6{21}:  AES_CBC_128/HMAC_SHA1_96, 27812648 bytes_i (30354 pkts, 
0s ago), 3312336 bytes_o (25269 pkts, 0s ago), rekeying in 36 minutes
uplink-v6{21}:   fd92:2dff:d232:10::/64 === ::/0
mgmt-v4{22}:  INSTALLED, TUNNEL, reqid 3, ESP in UDP SPIs: c339992c_i 
c29cd6c3_o, IPCOMP CPIs: 5594_i 6aba_o
mgmt-v4{22}:  AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying 
in 40 minutes
mgmt-v4{22}:   10.252.63.0/24 === 10.252.0.0/20
mgmt-v6{23}:  INSTALLED, TUNNEL, reqid 4, ESP in UDP SPIs: c2b5a806_i 
ce132e2a_o, IPCOMP CPIs: e703_i 873e_o
mgmt-v6{23}:  AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying 
in 34 minutes
mgmt-v6{23}:   fd92:2dff:d232:3f::/64 === fd92:2dff:d232::/64

This time, mgmt-v6 is (just) duplicated, and the responder also has the 
corresponding two CHILD_SAs:

uplink-v4[21]: ESTABLISHED 9 minutes ago, <host2>...<host1>
uplink-v4[21]: IKEv2 SPIs: de05552af21b451c_i c6786a850fe62561_r*, 
rekeying disabled
uplink-v4[21]: IKE proposal: 
AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
mgmt-v6{274}:  INSTALLED, TUNNEL, reqid 25, ESP in UDP SPIs: c675ddfc_i 
c86174ee_o, IPCOMP CPIs: ec4c_i 842e_o
mgmt-v6{274}:  AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying 
disabled
mgmt-v6{274}:   fd92:2dff:d232::/64 === fd92:2dff:d232:3f::/64
uplink-v4{275}:  INSTALLED, TUNNEL, reqid 26, ESP in UDP SPIs: 
c8a3c75a_i c8cd26cf_o, IPCOMP CPIs: 47f7_i e2aa_o
uplink-v4{275}:  AES_CBC_128/HMAC_SHA1_96, 31967628 bytes_i (245546 
pkts, 0s ago), 795783341 bytes_o (643732 pkts, 0s ago), rekeying 
disabled
uplink-v4{275}:   0.0.0.0/0 === 10.252.16.0/20
uplink-v6{276}:  INSTALLED, TUNNEL, reqid 27, ESP in UDP SPIs: 
cf4ae731_i cdaabd88_o, IPCOMP CPIs: b130_i 961a_o
uplink-v6{276}:  AES_CBC_128/HMAC_SHA1_96, 2503131 bytes_i (16819 pkts, 
0s ago), 35956342 bytes_o (39386 pkts, 0s ago), rekeying disabled
uplink-v6{276}:   ::/0 === fd92:2dff:d232:10::/64
mgmt-v4{277}:  INSTALLED, TUNNEL, reqid 28, ESP in UDP SPIs: c29cd6c3_i 
c339992c_o, IPCOMP CPIs: 6aba_i 5594_o
mgmt-v4{277}:  AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying 
disabled
mgmt-v4{277}:   10.252.0.0/20 === 10.252.63.0/24
mgmt-v6{278}:  INSTALLED, TUNNEL, reqid 25, ESP in UDP SPIs: ce132e2a_i 
c2b5a806_o, IPCOMP CPIs: 873e_i e703_o
mgmt-v6{278}:  AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying 
disabled
mgmt-v6{278}:   fd92:2dff:d232::/64 === fd92:2dff:d232:3f::/64

The difference in runtime IDs comes from the fact that I restart 
strongswan on the initiator to reset the tunnels. From that I've seen 
this is "known" broken behaviour (I'm not the first to notice this) and 
has generally been harmless so far, but as custom updown-scripts are 
attached to the CHILD_SAs, I'm somewhat afraid that this will in the 
long run lead to broken states concerning the actions that are 
dispatched by the updown-scripts (which includes setting up routes in 
specific routing tables).

Is there any way to fix this properly, i.e. make sure that the SAs 
aren't duplicated? Thanks for any feedback!

-- 
--- Heiko.