IPsec tunnel to Azure spawning many, many child SAs

[Isabella Borgward]

OPNsense 25.1.12-amd64
Using IPsec Connections, not IPsec Tunnel Settings.
Route-based VPN tunnel to Azure.
Tunnel mode.
Having the SA enabled seems to result in a new SA being created every 30-60 seconds or so.

[the one MODP_2048 entry below is a working tunnel, not related to this]

Code Select Expand

# ipsec statusall | grep bytes
no files found matching '/usr/local/etc/strongswan.opnsense.d/*.conf'
0a06bd58-d311-4be4-b850-e21ee2405c88{45}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{36}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 248 bytes_o, rekeying in 6 hours
dafa61b0-baa3-4120-85bf-b6bf37d00487{24}:  AES_CBC_256/HMAC_SHA2_256_128/MODP_2048, 14657534 bytes_i (142048 pkts, 0s ago), 28693760 bytes_o (127444 pkts, 0s ago), rekeying in 7 minutes
0a06bd58-d311-4be4-b850-e21ee2405c88{62}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{51}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{64}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{63}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{49}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 124 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{42}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{39}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 124 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{44}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{37}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 124 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{68}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 2604 bytes_o, rekeying in 7 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{57}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 248 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{50}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 124 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{33}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{28}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 124 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{58}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 372 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{53}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{38}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{54}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{43}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{35}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 372 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{34}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{55}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{32}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{30}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{48}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 124 bytes_o, rekeying in 7 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{41}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{29}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{59}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 124 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{56}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{52}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{46}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{31}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{47}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 496 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{65}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
0a06bd58-d311-4be4-b850-e21ee2405c88{61}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 124 bytes_o, rekeying in 6 hours
Some of the alleged SAs have TX bytes on, none have any RX.
If I disable the policy, it stops creating SAs but none actually get deleted.
Behaviour is a bit puzzling, what is going on here? Clearly, my end thinks the SA is up if there are TX bytes, but why does it then bring up another?

[Isabella Borgward]

When enabled, every 20s, this is logged:

Code Select Expand

<30>1 2025-11-14T14:27:54+00:00 router charon 35057 - [meta sequenceId="13664"] 10[CHD2] <771e685b-783a-4fc6-9c54-6c49e07621c8|4456> CHILD_SA 0a06bd58-d311-4be4-b850-e21ee2405c88{65} state change: CREATED => INSTALLING
<30>1 2025-11-14T14:27:54+00:00 router charon 35057 - [meta sequenceId="13679"] 10[IKE0] <771e685b-783a-4fc6-9c54-6c49e07621c8|4456> CHILD_SA 0a06bd58-d311-4be4-b850-e21ee2405c88{65} established with SPIs c87529cf_i 0237a11e_o and TS 0.0.0.0/0 === 0.0.0.0/0
<30>1 2025-11-14T14:27:54+00:00 router charon 35057 - [meta sequenceId="13680"] 10[CHD2] <771e685b-783a-4fc6-9c54-6c49e07621c8|4456> CHILD_SA 0a06bd58-d311-4be4-b850-e21ee2405c88{65} state change: INSTALLING => INSTALLED
<165>1 2025-11-14T14:27:54+00:00 router charon 57611 - [meta sequenceId="13682"] [UPDOWN] <0a06bd58-d311-4be4-b850-e21ee2405c88> received up-client event for reqid 20

[viragomann]

Did you specify a uniqe requid in each child?

Also I'd recommend to state "Trap+start" for the start action.

[Isabella Borgward]

Yes, the reqids are unique.
Each connection only has a single child SA.
I have changed to Trap+Start and will report back.

[Isabella Borgward]

Hasn't made any difference. Restarting the IPsec service got rid of all the older child SAs but it's still creating new ones.
I am going to delete and recreate.

[Isabella Borgward]

Same.

Code Select Expand

# ipsec statusall | grep ESTABL
no files found matching '/usr/local/etc/strongswan.opnsense.d/*.conf'
b4e048fe-e7a7-4fb7-a326-317bdd1a5529[131]: ESTABLISHED 112 seconds ago, 192.0.2.99[192.0.2.99]...198.51.100.7[198.51.100.7]
b4e048fe-e7a7-4fb7-a326-317bdd1a5529[134]: ESTABLISHED 76 seconds ago, 192.0.2.99[192.0.2.99]...198.51.100.7[198.51.100.7]
b4e048fe-e7a7-4fb7-a326-317bdd1a5529[139]: ESTABLISHED 18 seconds ago, 192.0.2.99[192.0.2.99]...198.51.100.7[198.51.100.7]
b4e048fe-e7a7-4fb7-a326-317bdd1a5529[133]: ESTABLISHED 95 seconds ago, 192.0.2.99[192.0.2.99]...198.51.100.7[198.51.100.7]
b4e048fe-e7a7-4fb7-a326-317bdd1a5529[138]: ESTABLISHED 38 seconds ago, 192.0.2.99[192.0.2.99]...198.51.100.7[198.51.100.7]
b4e048fe-e7a7-4fb7-a326-317bdd1a5529[136]: ESTABLISHED 57 seconds ago, 192.0.2.99[192.0.2.99]...198.51.100.7[198.51.100.7]
4d094f8b-e147-4d3d-9380-d60d6184c77d[10]: ESTABLISHED 24 minutes ago, 192.0.2.99[192.0.2.99]...203.0.113.6[203.0.113.6]
b4e048fe-e7a7-4fb7-a326-317bdd1a5529[130]: ESTABLISHED 2 minutes ago, 192.0.2.99[192.0.2.99]...198.51.100.7[198.51.100.7]