The CLI command reset vpn ipsec-peer XXX tunnel XXX internally turns into the:
ipsec down XXX ipsec up XXX
This makes it wrong. According to CLI description, it should "Reset a specific tunnel for given peer", but it actually trying to reset IKE session that may even drop other tunnels between peers.
Most likely, the proper syntax should be:
ipsec down XXX{*}
ipsec up XXXThe first command closes all the CHILD_SA instances of the connection name, and the second reestablish a tunnel.
I believe this is the behavior in 1.2.6 aswell?
And I think its not even possible to reset one peer?
So, reset vpn ipsec-peer XXX is broken
as well as reset vpn ipsec-peer XXX tunnel YYY
I can confirm it is broken for
reset vpn ipsec-peer XXX
too when you run policy-based VPNs.
Peer reset log:
Feb 19 11:21:29 adm-fw3-p sudo[3729]: vyos : TTY=pts/0 ; PWD=/home/vyos ; USER=root ; COMMAND=/usr/sbin/ipsec down peer-x.x.92.1-tunnel-1 Feb 19 11:21:29 adm-fw3-p sudo[3735]: vyos : TTY=pts/0 ; PWD=/home/vyos ; USER=root ; COMMAND=/usr/sbin/ipsec up peer-x.x.92.1-tunnel-1 Feb 19 11:21:29 adm-fw3-p sudo[3740]: vyos : TTY=pts/0 ; PWD=/home/vyos ; USER=root ; COMMAND=/usr/sbin/ipsec down peer-x.x.92.1-tunnel-2 Feb 19 11:21:29 adm-fw3-p sudo[3745]: vyos : TTY=pts/0 ; PWD=/home/vyos ; USER=root ; COMMAND=/usr/sbin/ipsec up peer-x.x.92.1-tunnel-2
The peer reset should probably first reset the IKE connection name, something like
ipsec down XXXi
and then iterate through all the defined tunnels:
ipsec down XXXn{*}XXXi = connection name for IKE SA
XXXn = connection name for CHILD SAs
Note:
If you delete tunnel 1 in a policy-based VPN, the connection name for the IKE tunnel will no longer be tunnel-1, but tunnel-2.
Happy to see a fix in 1.2.x.
Which proper format do we need?
For example 2 tunnels:
peer-100.64.0.2-tunnel-0
peer-100.64.0.2-tunnel-1
Like this?
ipsec down peer-100.64.0.2-tunnel-1{*}
ipsec up peer-100.64.0.2-tunnel-1PR https://github.com/vyos/vyatta-op-vpn/pull/28
vyos@r4-epa2:~$ reset vpn ipsec-peer 192.0.2.2 tunnel 0 Resetting tunnel 0 with peer 192.0.2.2... vyos@r4-epa2:~$
And swanctl shows that tunnel was reset corrected, not affected to other tunnels:
peer-192.0.2.2-tunnel-0: #1, ESTABLISHED, IKEv1, e49e5b247597c265_i* 02a81d10d8ca795f_r
local '192.0.2.1' @ 192.0.2.1[500]
remote '192.0.2.2' @ 192.0.2.2[500]
AES_CBC-256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
established 665s ago, reauth in 2205s
peer-192.0.2.2-tunnel-1: #3, reqid 3, INSTALLED, TUNNEL, ESP:AES_CBC-256/HMAC_SHA1_96/MODP_1024
installed 665s ago, rekeying in 424s, expires in 1135s
in c1164c47, 0 bytes, 0 packets
out cc564a00, 0 bytes, 0 packets
local 10.1.2.0/24
remote 10.2.2.0/24
peer-192.0.2.2-tunnel-2: #4, reqid 4, INSTALLED, TUNNEL, ESP:AES_CBC-256/HMAC_SHA1_96/MODP_1024
installed 665s ago, rekeying in 321s, expires in 1135s
in c39761d6, 0 bytes, 0 packets
out c1d62b31, 0 bytes, 0 packets
local 10.1.3.0/24
remote 10.2.3.0/24
peer-192.0.2.2-tunnel-0: #6, reqid 6, INSTALLED, TUNNEL, ESP:AES_CBC-256/HMAC_SHA1_96/MODP_1024
installed 27s ago, rekeying in 831s, expires in 1773s
in c3d4fd3f, 0 bytes, 0 packets
out cef6a3c7, 0 bytes, 0 packets
local 10.1.1.0/24
remote 10.2.1.0/24
vyos@r4-epa2:~$