IPsec: T4552: Fix reset vpn ipsec peer

[sever-sever]

Change Summary

When we use IPv6 peer we need to make a replacement : => -
for correct resetting as it doesn't match get_peer_connections()
regex
Use new format vyos.opmode

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Code style update (formatting, renaming)
• Refactoring (no functional changes)
• Migration from an old Vyatta component to vyos-1x, please link to related PR inside obsoleted component
• Other (please describe):

Related Task(s)

• https://phabricator.vyos.net/T4552

Component(s) name

vpn, ipsec

Proposed changes

How to test

Before fix

vyos@r14:~$ reset vpn ipsec-peer 2001:db8::2 
Tunnel(s) not found, aborting
vyos@r14:~$

After fix:

vyos@r14:~$ reset vpn ipsec-peer 2001:db8::2 
CHILD_SA {20548} closed successfully
CHILD_SA {20551} closed successfully
CHILD_SA {20555} closed successfully
CHILD_SA {20554} closed successfully
CHILD_SA {20558} closed successfully
CHILD_SA {20561} closed successfully
closing CHILD_SA peer_2001-db8--2_tunnel_0{20563} with SPIs cc9180c9_i (0 bytes) cbbcdd4a_o (0 bytes) and TS 2001:db8:1111::/64 === 2001:db8:2222::/64
sending DELETE for ESP CHILD_SA with SPI cc9180c9
generating INFORMATIONAL request 13663 [ D ]
sending packet: from 2001:db8::1[500] to 2001:db8::2[500] (69 bytes)
received packet: from 2001:db8::2[500] to 2001:db8::1[500] (69 bytes)
parsed INFORMATIONAL response 13663 [ D ]
received DELETE for ESP CHILD_SA with SPI cbbcdd4a
CHILD_SA closed
CHILD_SA {20563} closed successfully
establishing CHILD_SA peer_2001-db8--2_tunnel_0{20564}
generating CREATE_CHILD_SA request 13664 [ SA No KE TSi TSr ]
sending packet: from 2001:db8::1[500] to 2001:db8::2[500] (497 bytes)
received packet: from 2001:db8::2[500] to 2001:db8::1[500] (497 bytes)
parsed CREATE_CHILD_SA response 13664 [ SA No KE TSi TSr ]
selected proposal: ESP:AES_GCM_16_256/MODP_2048/NO_EXT_SEQ
CHILD_SA peer_2001-db8--2_tunnel_0{20564} established with SPIs c4490e21_i ce62da22_o and TS 2001:db8:1111::/64 === 2001:db8:2222::/64
connection 'peer_2001-db8--2_tunnel_0' established successfully
Peer reset result: success
vyos@r14:~$ 

Reset with the script:

vyos@r14:~$ /usr/libexec/vyos/op_mode/ipsec.py reset_peer --peer 2001:db8::2 --tunnel 0
CHILD_SA {2022} closed successfully
CHILD_SA {2025} closed successfully
CHILD_SA {2024} closed successfully
CHILD_SA {2028} closed successfully
CHILD_SA {2027} closed successfully
CHILD_SA {2031} closed successfully
CHILD_SA {2030} closed successfully
CHILD_SA {2035} closed successfully
CHILD_SA {2034} closed successfully
CHILD_SA {2038} closed successfully
closing CHILD_SA peer_2001-db8--2_tunnel_0{2037} with SPIs c08cb946_i (0 bytes) cc888f04_o (0 bytes) and TS 2001:db8:1111::/64 === 2001:db8:2222::/64
sending DELETE for ESP CHILD_SA with SPI c08cb946
generating INFORMATIONAL request 624 [ D ]
sending packet: from 2001:db8::1[500] to 2001:db8::2[500] (69 bytes)
received packet: from 2001:db8::2[500] to 2001:db8::1[500] (69 bytes)
parsed INFORMATIONAL response 624 [ D ]
received DELETE for ESP CHILD_SA with SPI cc888f04
CHILD_SA closed
CHILD_SA {2037} closed successfully
establishing CHILD_SA peer_2001-db8--2_tunnel_0{2041}
generating CREATE_CHILD_SA request 625 [ SA No KE TSi TSr ]
sending packet: from 2001:db8::1[500] to 2001:db8::2[500] (497 bytes)
received packet: from 2001:db8::2[500] to 2001:db8::1[500] (497 bytes)
parsed CREATE_CHILD_SA response 625 [ SA No KE TSi TSr ]
selected proposal: ESP:AES_GCM_16_256/MODP_2048/NO_EXT_SEQ
CHILD_SA peer_2001-db8--2_tunnel_0{2041} established with SPIs c05bfc18_i cf49ddc8_o and TS 2001:db8:1111::/64 === 2001:db8:2222::/64
connection 'peer_2001-db8--2_tunnel_0' established successfully
Peer reset result: success
vyos@r14:~$ 

There is a lot of CHILD_SA due to another bug (CHILD_REKEY collision) https://phabricator.vyos.net/T4551
So it is OK when we see multiple CHILD_SA in resetting output

Checklist:

• I have read the CONTRIBUTING document
• I have linked this PR to one or more Phabricator Task(s)
• I have run the components SMOKETESTS if applicable
• My commit headlines contain a valid Task id
• My change requires a change to the documentation
• I have updated the documentation accordingly

[c-po]

I wonder if it's feasible to print everything to stdout? Should we probably silently send all the logs to journald?

[sever-sever]

I wonder if it's feasible to print everything to stdout? Should we probably silently send all the logs to journald?

In the current version (before fix), we get this output. I think it is useful as we see that delete was successful and established successfully
But it depends.