Bug #8117
closed
IPSec statuspage shows both connected and connecting tunnel
0%
Description
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)
Files
Updated by Anonymous about 7 years 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 shellcon7: #46, CONNECTING, IKEv2, fdb690b0e5add6bb_i* 0000000000000000_r
...
...
Updated by Ges Ture about 7 years 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
active: ISAKMP_VENDOR ISAKMP_CERT_PRE MAIN_MODE ISAKMP_CERT_POST ISAKMP_NATD
...
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]
AES_CBC-256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
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...
Updated by Ges Ture almost 7 years ago
Any follow up? Will this be reported to Strongswan developers?
Updated by Jim Pingle almost 7 years 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.
Updated by Ges Ture almost 7 years ago
It is set to respond only! (but I think previously it was set to initiate!)
This did not happen in the previous versions. I still have no idea whether the tunnel is connected or not, as it still shows both a connected and a connecting version of the SAME IPSec tunnel endpoint connection. What's most annoying is the fact that it thinks it is both the initiator and the responder. It should be one or the other, not both, in the latter situation the tunnel is very unstable, as the other side gets both initiating and responding messages as well and therefore keeps resetting the tunnel!
The main connection could accept another remote, given its configuration. It is definitely not configured this way, it's the 'bug' that is thinking it's configured this way. As already said, you cannot set the connection to both initiate and respond to the same tunnel endpoint. Still, it's Strongswan (or the ipsec feature) that is in error here.
Note: once I stop and start the VPN service, the duplicates disappear, at least for some time. After a while I could still see the duplicates again.