Bug #8117

IPSec statuspage shows both connected and connecting tunnel

Added by Ges Ture about 2 months ago. Updated 5 days ago.

Not a Bug
Target version:
Start date:
Due date:
% Done:


Affected Version:
Affected Architecture:


The bug started after upgrading from 2.3.4 to v2.4.1. Once in a while a number of IPSec tunnels show up as both connected and connecting. It makes it hard to determine whether the tunnel is up or down. This was already confirmed in v2.4.1 ('#8003, '#6335) and was supposed to be solved in 2.4.2 (so I upgraded to a 2.4.3 develop build), but as far as I can tell it's not completely solved. Half the time it shows the correct status, otherwise it shows duplicates (see picture). What is weird is the fact that the 'connecting' part is actually the initiator, but the tunnel is set as responder only, as the 'connected' part shows (it's as if the responder setting is ignored and the tunnel is initiated by itself)

IPSec Statuspage duplicates.png (29.5 KB) Ges Ture, 11/22/2017 09:23 AM


#1 Updated by Stephen Jones about 2 months ago

One thing to try would be in the command shell or in Diagnostics > Command Prompt type the command `swanctl --list-sas` and see what it outputs. The Status IPsec page should show what is listed there.

`swanctl --list-sas` Will show all currently active IKE_SAs.

If its in the connecting state it will look similar to this in the shell
con7: #46, CONNECTING, IKEv2, fdb690b0e5add6bb_i* 0000000000000000_r

#2 Updated by Ges Ture about 2 months ago

Hello Stephen,

The same connection as in the picture shows up (twice!) as follows in the cli:

con59000: #1796, CONNECTING, IKEv1, 6bb51b0a9244e500_i* 0000000000000000_r
local '%any' @ x.x.x.x [500]
remote '%any' @ x.x.x.x [500]
queued: QUICK_MODE
con59000: #1797, ESTABLISHED, IKEv1, 3b5f72fc4164f640_i 5736bcd0b8a6f6af_r*
local 'x.x.x.x' @ x.x.x.x [500]
remote 'x.x.x.x' @ x.x.x.x [500]
established 16s ago, reauth in 28129s
con59000: '#3105, reqid 503, INSTALLED, TUNNEL, ESP:AES_CBC-256/HMAC_SHA1_96
installed 16s ago, rekeying in 2528s, expires in 3584s
in cf1c521f, 729 bytes, 8 packets, 16s ago
out d691774f, 0 bytes, 0 packets
local x.x.x.x/16|/0
remote x.x.x.x/24|/0

So it seems to be the Strongswan that is at error here, not the status page...

#3 Updated by Ges Ture about 2 months ago

Any follow up? Will this be reported to Strongswan developers?

#4 Updated by Jim Pingle 5 days ago

  • Status changed from New to Not a Bug
  • Target version deleted (2.4.3)

Given the output I'm not sure it's a bug at all. The main connection could accept another remote, given its configuration. It is showing you both the generic configuration and the specific connected instance. Given the nature of the remote being 'any', the main connection can't progress past that "connecting" state since it has no idea where the peer is. You could try to set the Phase 1 as "responder only" to work around that fact.

Also available in: Atom PDF