Actions
Bug #12155
closedTunnels with conflicting REQID values can lead to multiple identical Child SA entries
Start date:
07/21/2021
Due date:
% Done:
100%
Estimated time:
Plus Target Version:
22.01
Release Notes:
Default
Affected Version:
2.5.x
Affected Architecture:
All
Description
Testing in 21.05 and 21.09 it's possible to create IPSec tunnels with the same reqid if both VTI and Tunnel mode connections are used.
This usually doesn't seem to be an issue unless one of the tunnels fails to connect.
In the case where the VTI tunnel is down it continually tries to re-establish and each time it does so it triggers the create_child task on the other tunnel with the same reqid.
This results in numerous identical ChildSAs.
swanctl.conf:
# This file is automatically generated. Do not edit connections { bypass { remote_addrs = 127.0.0.1 children { bypasslan { local_ts = 192.168.241.0/24 remote_ts = 192.168.241.0/24 mode = pass start_action = trap } } } con200000 { fragmentation = yes unique = replace version = 2 proposals = aes128-sha256-modp2048 dpd_delay = 10s dpd_timeout = 60s rekey_time = 25920s reauth_time = 0s over_time = 2880s rand_time = 2880s encap = no mobike = no local_addrs = 172.21.16.246 remote_addrs = 172.21.16.1 local { id = 172.21.16.246 auth = psk } remote { id = 172.21.16.1 auth = psk } children { con200000 { dpd_action = trap mode = tunnel policies = yes life_time = 3600s rekey_time = 3240s rand_time = 360s start_action = trap remote_ts = 192.168.126.0/24 local_ts = 192.168.241.0/24 esp_proposals = aes128-sha1-modp2048 } } } con1 { fragmentation = yes unique = replace version = 2 proposals = aes128-sha256-modp2048 dpd_delay = 10s dpd_timeout = 60s rekey_time = 25920s reauth_time = 0s over_time = 2880s rand_time = 2880s encap = no mobike = no local_addrs = 10.65.28.1 remote_addrs = 10.65.28.2 local { id = 10.65.28.1 auth = psk } remote { id = 10.65.28.2 auth = psk } children { con1 { dpd_action = restart policies = no life_time = 3600s rekey_time = 3240s rand_time = 360s start_action = start remote_ts = 10.66.10.2,0.0.0.0/0 local_ts = 10.66.10.1,0.0.0.0/0 reqid = 1 esp_proposals = aes128gcm128-modp2048,aes128-sha256-modp2048 } } } con300000 { fragmentation = yes unique = replace version = 2 proposals = aes128-sha256-modp2048 dpd_delay = 10s dpd_timeout = 60s rekey_time = 25920s reauth_time = 0s over_time = 2880s rand_time = 2880s encap = no mobike = no local_addrs = 172.21.16.246 remote_addrs = 172.21.16.22 local { id = 172.21.16.246 auth = psk } remote { id = 172.21.16.22 auth = psk } children { con300000 { dpd_action = trap mode = tunnel policies = yes life_time = 3600s rekey_time = 3240s rand_time = 360s start_action = trap remote_ts = 192.168.22.0/24 local_ts = 192.168.241.0/24 esp_proposals = aes128gcm128-modp2048,aes128-sha256-modp2048 } } } }
The VTI connection there uses reqid 1 but the first tunnel mode does too:
Routed Connections: con300000{2}: ROUTED, TUNNEL, reqid 2 con300000{2}: 192.168.241.0/24|/0 === 192.168.22.0/24|/0 con200000{1}: ROUTED, TUNNEL, reqid 1 con200000{1}: 192.168.241.0/24|/0 === 192.168.126.0/24|/0
Despite the fact the config has it defined as reqid 2:
Routed Connections: con300000{2}: ROUTED, TUNNEL, reqid 2 con300000{2}: 192.168.241.0/24|/0 === 192.168.22.0/24|/0 con200000{1}: ROUTED, TUNNEL, reqid 1 con200000{1}: 192.168.241.0/24|/0 === 192.168.126.0/24|/0
Files
Actions