Page MenuHomeVyOS Platform

Reset vpn ipsec command breaks tunnel and does not reset SAs that are down
Closed, ResolvedPublicBUG

Description

I found two bugs related to the reset command on 1.4.0 epa2.

"reset vpn ipsec" command breaks tunnel, but command output report the reset as successful.
"reset vpn ipsec " command and does not reset SAs that are down. The problem not finding occurs both for IKE SAs and Child SAs.

Let me know what more information you need.

Bug 1: reset vpn ipsec command Breaks working SA( reset fails ) and report is as successful.

I have tested on 4 different vpns across 3 devices. On one VPNs the reset seems to work, but that might just be the remote side having a unexpected close action = reset. I have only tested on policy based VPNs(with traffic selectors defined on the tunnels)

vyos@CUSTOMER-fw-p:~$ reset vpn ipsec site-to-site peer peer_X-X-252-1 tunnel 1
Peer peer_X-X-252-1 reset result: success

The result is that the SA goes down

vyos@CUSTOMER-fw-p:~$ show vpn ipsec connections | strip-private
Connection                   State    Type    Remote address    Local TS          Remote TS          Local id    Remote id      Proposal
---------------------------  -------  ------  ----------------  ----------------  -----------------  ----------  -------------  ---------------------------------------
peer_X-X-252-1             up       IKEv2   xxx.xxx.252.1       -                 -                              xxx.xxx.252.1    AES_CBC/256/HMAC_SHA2_256_128/MODP_2048
peer_X-X-252-1-tunnel-1    down     IPsec   xxx.xxx.252.1       xxx.xxx.92.96/29  xxx.xxx.16.231/32               xxx.xxx.252.1    -

Bug 2: Does not find SA when it is down

vyos@CUSTOMER-fw-p:~$ reset vpn ipsec site-to-site peer peer_X-X-252-1 tunnel 1
Peer peer_X-X-252-1 tunnel 1 SA(s) not found, aborting
vyos@CUSTOMER-fw-p:~$ show vpn ipsec connections | strip-private
Connection                   State    Type    Remote address    Local TS          Remote TS          Local id    Remote id      Proposal
---------------------------  -------  ------  ----------------  ----------------  -----------------  ----------  -------------  ---------------------------------------
peer_X-X-252-1             up       IKEv2   xxx.xxx.252.1       -                 -                              xxx.xxx.252.1    AES_CBC/256/HMAC_SHA2_256_128/MODP_2048
peer_X-X-252-1-tunnel-1    up       IPsec   xxx.xxx.252.1       xxx.xxx.92.96/29  xxx.xxx.16.231/32               xxx.xxx.252.1    AES_CBC/256/HMAC_SHA2_256_128/MODP_2048

Other output:

Swanctl (correctly) does not list the SAs that are not up. Description says active IKE_SAs, but it also display Child SAs that are up.
" swanctl --list-sas (-l) list currently active IKE_SAs"

vyos@CUSTOMER-fw-p:~$ sudo swanctl --list-sas | strip-private
peer_X-X-252-1: #44, ESTABLISHED, IKEv2, b31707d09d2ea486_i 205f29da562ea554_r*
  local  'xxx.xxx.92.10' @ xxx.xxx.92.10[500]
  remote 'xxx.xxx.252.1' @ xxx.xxx.252.1[500]
  AES_CBC-256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
  established 17279s ago, rekeying in 67832s

Swanctl connection list ( configured)

vyos@CUSTOMER-fw-p:~$ sudo swanctl --list-conns | strip-private
peer_X-X-252-1: IKEv2, no reauthentication, rekeying every 86400s, dpd delay 30s
  local:  xxx.xxx.92.10
  remote: xxx.xxx.252.1
  local pre-shared key xxxxxx
  remote pre-shared key xxxxxx
    id: xxx.xxx.252.1
  peer_X-X-252-1-tunnel-1: TUNNEL, rekeying every 3272s, dpd action is none
    local:  xxx.xxx.92.96/29
    remote: xxx.xxx.16.231/32

Details

Version
VyOS1.4.0, VyOS 1.5
Is it a breaking change?
Unspecified (possibly destroys the router)
Issue type
Bug (incorrect behavior)

Event Timeline

"reset vpn ipsec " command and does not reset SAs that are dow

You cannot reset SAs that do not exist, due to Strongswan vici cannot reset something that doesn't exist because cannot find them.

Not sure if it is meaningful to create a new operational vyos command "initiate" or re-write the reset to be consistent with older VyOS.

Debugging VPNs require you to trigger actions and looking into logs and TCPdupms. Initiate, terminate, reset(break before make) etc.

In 1.4 and 1.5 command reset vpn ipsec has a termination meaning.

The command reset vpn ipsec site-to-site peer peer_X-X-252-1 tunnel 1 should terminate specific active IPSEC SA (CHILD SA) by name

The command reset vpn ipsec site-to-site peer peer_X-X-252-1 should terminate active IKE SA (CONNECTION) with all IPSEC SAs(CHILD SAs)

If your IPSEC tunnel is configured properly, Strongswan should reinitialize this tunnel itself.

In 1.4 and 1.5 command reset vpn ipsec has a termination meaning.

No, it says reset, both the command, and auto complete output. It does not say terminate or clear. If you run a reset you do expect it to restart or re-populate in one way or another, not just stop working completley.

If your IPSEC tunnel is configured properly, Strongswan should reinitialize this tunnel itself.

You can't generalize and say "configured properly". It depends on the desired config.

Here is an example of a perferctly valid vyos vpn config that will never recover a child SA when resetting it.

No trap action that brings them back up when you have traffic. No vyos command to fix the problem at all.

vyos@wwn-fw-p# show vpn ipsec site-to-site peer | strip-private
authentication {

local-id xxx.xxx.92.8
mode pre-shared-secret
remote-id xxx.xxx.69.117

}
connection-type initiate
default-esp-group wwn
ike-group wwn
ikev2-reauth inherit
local-address xxx.xxx.92.8
remote-address xxx.xxx.69.117
tunnel 1 {

local {
    prefix xxx.xxx.86.0/24
}
remote {
    prefix xxx.xxx.67.0/24
}

}
tunnel 2 {

local {
    prefix xxx.xxx.86.0/24
}
remote {
    prefix xxx.xxx.68.0/24
}

}

show vpn ipsec ike-group wwn
close-action trap
disable-mobike
key-exchange ikev2
lifetime 28800
proposal 1 {

dh-group 14
encryption aes256
hash sha256

vyos@wwn-fw-p# show vpn ipsec esp-group wwn
lifetime 3600
mode tunnel
pfs dh-group14
proposal 1 {

encryption aes256
hash sha256

}

After considering, we decided that reset is the same as terminate.
If you want to add a feature start manual initialization, please create a feature request.

a.apostoliuk claimed this task.
a.apostoliuk moved this task from Open to Finished on the VyOS 1.4 Sagitta board.
a.apostoliuk changed the task status from Open to In progress.Jun 19 2024, 12:16 PM
a.apostoliuk changed Version from epa2 to VyOS1.4.0, VyOS 1.5.
a.apostoliuk moved this task from In Progress to Open on the VyOS 1.4 Sagitta board.
a.apostoliuk edited projects, added VyOS 1.4 Sagitta (1.4.1); removed VyOS 1.4 Sagitta.

After deep testing, we saw that if we reset the peer on the initiator side, strongswan does not reinitiate the connection by itself.
Need to add a connection initiation in the reset function on the initiator side.

Viacheslav changed the task status from In progress to Needs testing.Jul 28 2024, 12:54 PM