You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
System (please complete the following information):
OS: Ubuntu 16.04.4
Kernel version (if applicable): 4.4.0
strongSwan version(s): U5.9.8
Tested/confirmed with the latest version: no
Describe the bug
I have one config file on each device. Such as SUN and MOON. And they are running in gw-gw mode.
With the repdoduce steps. you can see two SAs on SUN and MOON with "swanctl --list-sas"
It can be reproduced consistently .
To Reproduce
Steps to reproduce the behavior:
Execute the below commands on both MOON and SUN.
ipsec down gw-gw
ipsec stop
Then execute the below commands on both MOON and SUN.
ipsec start
sleep 1
swanctl --load-all
ipsec up gw-gw
swanctl --list-sas
Expected behavior
Will observe two sas with swanctl --list-sas
It's not correct, one conf will and only setup one SA.
Logs/Backtraces
swanctl --list-sas
gw-gw: #2, ESTABLISHED, IKEv2, e9b350b334d4471c_i da041b06af808f25_r*
local '192.168.91.101' @ 192.168.91.101[500]
remote '192.168.91.100' @ 192.168.91.100[500]
AES_CBC-128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256_BP
established 1342s ago, reauth in 1549s
net-net: #1, reqid 1, INSTALLED, TUNNEL, ESP:AES_GCM_16-128
installed 1342s ago, rekeying in 1931s, expires in 2618s
in c2afa150, 0 bytes, 0 packets
out cfaa84e8, 0 bytes, 0 packets
local 192.168.41.0/24
remote 192.168.51.0/24
gw-gw: #1, ESTABLISHED, IKEv2, fded340ca66d743b_i* 748d52d67f2a643a_r
local '192.168.91.101' @ 192.168.91.101[500]
remote '192.168.91.100' @ 192.168.91.100[500]
AES_CBC-128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256_BP
established 1339s ago, reauth in 1473s
net-net: #2, reqid 1, INSTALLED, TUNNEL, ESP:AES_GCM_16-128
installed 1339s ago, rekeying in 1999s, expires in 2621s
in c0552846, 0 bytes, 0 packets
out cf229fb8, 0 bytes, 0 packets
local 192.168.41.0/24
remote 192.168.51.0/24
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered:
This can obviously happen if two peers establish the same SA concurrently. It shouldn't be a problem.
Not that it has anything to do with this, but please not that you are mixing new and old management commands (ipsec is the legacy script, while swanctl the more modern tool).
System (please complete the following information):
Describe the bug
I have one config file on each device. Such as SUN and MOON. And they are running in gw-gw mode.
With the repdoduce steps. you can see two SAs on SUN and MOON with "swanctl --list-sas"
It can be reproduced consistently .
To Reproduce
Steps to reproduce the behavior:
Execute the below commands on both MOON and SUN.
ipsec down gw-gw
ipsec stop
Then execute the below commands on both MOON and SUN.
ipsec start
sleep 1
swanctl --load-all
ipsec up gw-gw
swanctl --list-sas
Expected behavior
Will observe two sas with swanctl --list-sas
It's not correct, one conf will and only setup one SA.
Logs/Backtraces
swanctl --list-sas
gw-gw: #2, ESTABLISHED, IKEv2, e9b350b334d4471c_i da041b06af808f25_r*
local '192.168.91.101' @ 192.168.91.101[500]
remote '192.168.91.100' @ 192.168.91.100[500]
AES_CBC-128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256_BP
established 1342s ago, reauth in 1549s
net-net: #1, reqid 1, INSTALLED, TUNNEL, ESP:AES_GCM_16-128
installed 1342s ago, rekeying in 1931s, expires in 2618s
in c2afa150, 0 bytes, 0 packets
out cfaa84e8, 0 bytes, 0 packets
local 192.168.41.0/24
remote 192.168.51.0/24
gw-gw: #1, ESTABLISHED, IKEv2, fded340ca66d743b_i* 748d52d67f2a643a_r
local '192.168.91.101' @ 192.168.91.101[500]
remote '192.168.91.100' @ 192.168.91.100[500]
AES_CBC-128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256_BP
established 1339s ago, reauth in 1473s
net-net: #2, reqid 1, INSTALLED, TUNNEL, ESP:AES_GCM_16-128
installed 1339s ago, rekeying in 1999s, expires in 2621s
in c0552846, 0 bytes, 0 packets
out cf229fb8, 0 bytes, 0 packets
local 192.168.41.0/24
remote 192.168.51.0/24
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: