chore(swap): remove canary md-*.md files and docs/superpowers

- Remove 115 canary md-*.md files (incremental swap helpers no longer needed)
- Remove 8 files under docs/superpowers (project planning/design docs that
  shouldn't ship in the documentation tree)

🤖 Generated by [robots](https://vyos.io)

3 files changed, 0 insertions, 494 deletions

diff --git a/docs/configuration/vpn/ipsec/md-index.md b/docs/configuration/vpn/ipsec/md-index.md
deleted file mode 100644
index cc40b6f8..00000000
--- a/docs/configuration/vpn/ipsec/md-index.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# IPsec
-
-```{toctree}
-:includehidden: true
-:maxdepth: 1
-
-ipsec_general
-site2site_ipsec
-remoteaccess_ipsec
-troubleshooting_ipsec
-```
diff --git a/docs/configuration/vpn/ipsec/md-remoteaccess_ipsec.md b/docs/configuration/vpn/ipsec/md-remoteaccess_ipsec.md
deleted file mode 100644
index de553aec..00000000
--- a/docs/configuration/vpn/ipsec/md-remoteaccess_ipsec.md
+++ /dev/null
@@ -1,181 +0,0 @@
-(remoteaccess-ipsec)=
-
-# IPSec IKEv2 Remote Access VPN
-
-```{todo}
-Convert raw command blocks in this file to cfgcmd/opcmd
-directives for command coverage tracking.
-```
-
-Internet Key Exchange version 2 (IKEv2) is a tunneling protocol, based on IPsec,
-that establishes a secure VPN communication between VPN devices, and defines
-negotiation and authentication processes for IPsec security associations (SAs).
-It is often known as IKEv2/IPSec or IPSec IKEv2 remote-access — or road-warriors
-as others call it.
-
-Key exchange and payload encryption is done using IKE and ESP proposals as known
-from IKEv1 but the connections are faster to establish, more reliable, and also
-support roaming from IP to IP (called MOBIKE which makes sure your connection
-does not drop when changing networks from e.g. WIFI to LTE and back).
-Authentication can be achieved with X.509 certificates.
-
-## Setting up certificates:
-First of all, we need to create a CA root certificate and server certificate
-on the server side.
-
-```none
-vyos@vpn.vyos.net# run generate pki ca install ca_root
-Enter private key type: [rsa, dsa, ec] (Default: rsa)
-Enter private key bits: (Default: 2048)
-Enter country code: (Default: GB)
-Enter state: (Default: Some-State)
-Enter locality: (Default: Some-City)
-Enter organization name: (Default: VyOS)
-Enter common name: (Default: vyos.io)
-Enter how many days certificate will be valid: (Default: 1825)
-Note: If you plan to use the generated key on this router, do not encrypt the private key.
-Do you want to encrypt the private key with a passphrase? [y/N] N
-2 value(s) installed. Use "compare" to see the pending changes, and "commit" to apply.
-[edit]
-
-
-vyos@vpn.vyos.net# comp
-[pki ca]
-+ ca_root {
-+     certificate "MIIDnTCCAoWgAwI…."
-+     private {
-+         key "MIIEvAIBADANBgkqhkiG9….”
-
-vyos@vpn.vyos.net# run generate pki certificate sign ca_root install server_cert
-Do you already have a certificate request? [y/N] N
-Enter private key type: [rsa, dsa, ec] (Default: rsa)
-Enter private key bits: (Default: 2048)
-Enter country code: (Default: GB)
-Enter state: (Default: Some-State)
-Enter locality: (Default: Some-City)
-Enter organization name: (Default: VyOS)
-Enter common name: (Default: vyos.io) vpn.vyos.net
-Do you want to configure Subject Alternative Names? [y/N] N
-Enter how many days certificate will be valid: (Default: 365)
-Enter certificate type: (client, server) (Default: server)
-Note: If you plan to use the generated key on this router, do not encrypt the private key.
-Do you want to encrypt the private key with a passphrase? [y/N] N
-2 value(s) installed. Use "compare" to see the pending changes, and "commit" to apply.
-
-vyos@vpn.vyos.net# comp
-[pki certificate]
-+ server_cert {
-+     certificate "MIIDuzCCAqOgAwIBAgIUaSrCPWx………"
-+     private {
-+         key "MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBK….."
-+     }
-+ }
-```
-
-Once the command is completed, it will add the certificate to the configuration
-session, to the pki subtree. You can then review the proposed changes and
-commit them.
-
-## Setting up IPSec:
-After the PKI certs are all set up we can start configuring our IPSec/IKE
-proposals used for key-exchange end data encryption. The used encryption ciphers
-and integrity algorithms vary from operating system to operating system. The
-ones used in this example are validated to work on Windows 10.
-
-```none
-set vpn ipsec esp-group ESP-RW lifetime '3600'
-set vpn ipsec esp-group ESP-RW pfs 'disable'
-set vpn ipsec esp-group ESP-RW proposal 10 encryption 'aes128gcm128'
-set vpn ipsec esp-group ESP-RW proposal 10 hash 'sha256'
-
-set vpn ipsec ike-group IKE-RW key-exchange 'ikev2'
-set vpn ipsec ike-group IKE-RW lifetime '7200'
-set vpn ipsec ike-group IKE-RW proposal 10 dh-group '14'
-set vpn ipsec ike-group IKE-RW proposal 10 encryption 'aes128gcm128'
-set vpn ipsec ike-group IKE-RW proposal 10 hash 'sha256'
-```
-
-Every connection/remote-access pool we configure also needs a pool where we
-can draw our client IP addresses from. We provide one IPv4 and IPv6 pool.
-Authorized clients will receive an IPv4 address from the configured IPv4 prefix
-and an IPv6 address from the IPv6 prefix. We can also send some DNS nameservers
-down to our clients used on their connection.
-
-```none
-set vpn ipsec remote-access pool ra-rw-ipv4 name-server '192.0.2.1'
-set vpn ipsec remote-access pool ra-rw-ipv4 prefix '192.0.2.128/25'
-
-set vpn ipsec remote-access pool ra-rw-ipv6 name-server '2001:db8:1000::1'
-set vpn ipsec remote-access pool ra-rw-ipv6 prefix '2001:db8:2000::/64'
-```
-
-## Setting up tunnel:
-
-```none
-set vpn ipsec remote-access connection rw authentication local-id '192.0.2.1'
-set vpn ipsec remote-access connection rw authentication server-mode 'x509'
-set vpn ipsec remote-access connection rw authentication x509 ca-certificate 'ca_root'
-set vpn ipsec remote-access connection rw authentication x509 certificate 'server_cert'
-set vpn ipsec remote-access connection rw esp-group 'ESP-RW'
-set vpn ipsec remote-access connection rw ike-group 'IKE-RW'
-set vpn ipsec remote-access connection rw local-address '192.0.2.1'
-set vpn ipsec remote-access connection rw pool 'ra-rw-ipv4'
-set vpn ipsec remote-access connection rw pool 'ra-rw-ipv6'
-```
-
-VyOS also supports two different modes of authentication, local and RADIUS.
-To create a new local user named "vyos" with a password of "vyos" use the
-following commands.
-
-```none
-set vpn ipsec remote-access connection rw authentication client-mode 'eap-mschapv2'
-set vpn ipsec remote-access connection rw authentication local-users username vyos password 'vyos'
-```
-
-Some client operating systems like to see the servers certificate. The following
-option causes the server to voluntarily send its certificate, even if it wasn't
-requested.
-
-```none
-set vpn ipsec remote-access connection rw authentication always-send-cert
-```
-
-## Client Configuration
-Most operating systems include native client support for IPsec IKEv2 VPN
-connections, and others typically have an app or add-on package which adds the
-capability.
-This section covers IPsec IKEv2 client configuration for Windows 10.
-
-VyOS provides a command to generate a connection profile used by Windows clients
-that will connect to the "rw" connection on our VyOS server.
-
-:::{note}
-Windows expects the server name to be also used in the server's
-certificate common name, so it's best to use this DNS name for your VPN
-connection.
-:::
-
-```none
-vyos@vpn.vyos.net:~$ generate ipsec profile windows-remote-access rw remote vpn.vyos.net
-
-
-==== <snip> ====
-Add-VpnConnection -Name "VyOS IKEv2 VPN" -ServerAddress "vpn.vyos.net" -TunnelType "Ikev2"
-
-Set-VpnConnectionIPsecConfiguration -ConnectionName "VyOS IKEv2 VPN" -AuthenticationTransformConstants GCMAES128 -CipherTransformConstants
-GCMAES128 -EncryptionMethod GCMAES128 -IntegrityCheckMethod SHA256128 -PfsGroup None -DHGroup "Group14" -PassThru -Force
-==== </snip> ====
-```
-
-Add the commands from Snippet in the Windows side via PowerShell.
-Also import the root CA cert to the Windows “Trusted Root Certification
-Authorities” and establish the connection.
-
-## Verification:
-
-```none
-vyos@vpn.vyos.net:~$ show vpn ipsec remote-access summary
-  Connection ID  Username    Protocol    State    Uptime    Tunnel IP    Remote Host    Remote ID    IKE Proposal                                IPSec Proposal
----------------  ----------  ----------  -------  --------  -----------  -------------  -----------  ------------------------------------------  ------------------
-              5  vyos        IKEv2       UP       37s       192.0.2.129  10.0.0.2       10.0.0.2     AES_GCM_16-128/PRF_HMAC_SHA2_256/MODP_2048  ESP:AES_GCM_16-128
-```
diff --git a/docs/configuration/vpn/ipsec/md-troubleshooting_ipsec.md b/docs/configuration/vpn/ipsec/md-troubleshooting_ipsec.md
deleted file mode 100644
index 2dfd3fec..00000000
--- a/docs/configuration/vpn/ipsec/md-troubleshooting_ipsec.md
+++ /dev/null
@@ -1,302 +0,0 @@
-(troubleshooting-ipsec)=
-
-# Troubleshooting Site-to-Site VPN IPsec
-
-```{todo}
-Convert raw command blocks in this file to cfgcmd/opcmd
-directives for command coverage tracking.
-```
-
-## Introduction
-This document describes the methodology to monitor and troubleshoot
-Site-to-Site VPN IPsec.
-
-Steps for troubleshooting problems with Site-to-Site VPN IPsec:
-: 1. Ping the remote site through the tunnel using the source and
-     destination IPs included in the policy.
-  2. Check connectivity between the routers using the ping command
-     (if ICMP traffic is allowed).
-  3. Check the IKE SAs' statuses.
-  4. Check the IPsec SAs' statuses.
-  5. Check logs to view debug messages.
-
-## Checking IKE SA Status
-The next command shows IKE SAs' statuses.
-
-```none
-vyos@vyos:~$ show vpn ike sa
-
-Peer ID / IP                            Local ID / IP
-------------                            -------------
-192.168.1.2 192.168.1.2                 192.168.0.1 192.168.0.1
-
-    State  IKEVer  Encrypt      Hash          D-H Group      NAT-T  A-Time  L-Time
-    -----  ------  -------      ----          ---------      -----  ------  ------
-    up     IKEv2   AES_CBC_128  HMAC_SHA1_96  MODP_2048      no     162     27023
-```
-
-This command shows the next information:
-: - IKE SA status.
-  - Selected IKE version.
-  - Selected Encryption, Hash and Diffie-Hellman Group.
-  - NAT-T.
-  - ID and IP of both peers.
-  - A-Time: established time, L-Time: time for next rekeying.
-
-## IPsec SA (CHILD SA) Status
-The next commands show IPsec SAs' statuses.
-
-```none
-vyos@vyos:~$ show vpn ipsec sa
-Connection     State    Uptime    Bytes In/Out    Packets In/Out    Remote address    Remote ID    Proposal
--------------  -------  --------  --------------  ----------------  ----------------  -----------  ----------------------------------
-PEER-tunnel-1  up       16m30s    168B/168B       2/2               192.168.1.2       192.168.1.2  AES_CBC_128/HMAC_SHA1_96/MODP_2048
-```
-
-```none
-vyos@vyos:~$ show vpn ipsec sa detail
-PEER: #1, ESTABLISHED, IKEv2, 101275ac719d5a1b_i* 68ea4ec3bed3bf0c_r
-  local  '192.168.0.1' @ 192.168.0.1[4500]
-  remote '192.168.1.2' @ 192.168.1.2[4500]
-  AES_CBC-128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
-  established 4054s ago, rekeying in 23131s
-  PEER-tunnel-1: #2, reqid 1, INSTALLED, TUNNEL, ESP:AES_CBC-128/HMAC_SHA1_96/MODP_2048
-    installed 1065s ago, rekeying in 1998s, expires in 2535s
-    in  c5821882,    168 bytes,     2 packets,    81s ago
-    out c433406a,    168 bytes,     2 packets,    81s ago
-    local  10.0.0.0/24
-    remote 10.0.1.0/24
-```
-
-These commands show the next information:
-: - IPsec SA status.
-  - Uptime and time for the next rekeing.
-  - Amount of transferred data.
-  - Remote and local ID and IP.
-  - Selected Encryption, Hash and Diffie-Hellman Group.
-  - Mode (tunnel or transport).
-  - Remote and local prefixes which are use for policy.
-
-There is a possibility to view the summarized information of SAs' status
-
-```none
-vyos@vyos:~$ show vpn ipsec connections
-Connection     State    Type    Remote address    Local TS     Remote TS    Local id     Remote id    Proposal
--------------  -------  ------  ----------------  -----------  -----------  -----------  -----------  ----------------------------------
-PEER           up       IKEv2   192.168.1.2       -            -            192.168.0.1  192.168.1.2  AES_CBC/128/HMAC_SHA1_96/MODP_2048
-PEER-tunnel-1  up       IPsec   192.168.1.2       10.0.0.0/24  10.0.1.0/24  192.168.0.1  192.168.1.2  AES_CBC/128/HMAC_SHA1_96/MODP_2048
-```
-
-## Viewing Logs for Debugging
-If IKE SAs or IPsec SAs are down, need to debug IPsec connectivity
-using logs `show log ipsec`
-
-The next example of the successful IPsec connection initialization.
-
-```none
-vyos@vyos:~$ show log ipsec
-Jun 20 14:29:47 charon[2428]: 02[NET] <PEER|1> received packet: from 192.168.1.2[500] to 192.168.0.1[500] (472 bytes)
-Jun 20 14:29:47 charon[2428]: 02[ENC] <PEER|1> parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(CHDLESS_SUP) N(MULT_AUTH) ]
-Jun 20 14:29:47 charon-systemd[2428]: received packet: from 192.168.1.2[500] to 192.168.0.1[500] (472 bytes)
-Jun 20 14:29:47 charon[2428]: 02[CFG] <PEER|1> selected proposal: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
-Jun 20 14:29:47 charon-systemd[2428]: parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(CHDLESS_SUP) N(MULT_AUTH) ]
-Jun 20 14:29:47 charon-systemd[2428]: selected proposal: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
-Jun 20 14:29:47 charon[2428]: 02[IKE] <PEER|1> authentication of '192.168.0.1' (myself) with pre-shared key
-Jun 20 14:29:47 charon-systemd[2428]: authentication of '192.168.0.1' (myself) with pre-shared key
-Jun 20 14:29:47 charon[2428]: 02[IKE] <PEER|1> establishing CHILD_SA PEER-tunnel-1{1}
-Jun 20 14:29:47 charon-systemd[2428]: establishing CHILD_SA PEER-tunnel-1{1}
-Jun 20 14:29:47 charon[2428]: 02[ENC] <PEER|1> generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
-Jun 20 14:29:47 charon-systemd[2428]: generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
-Jun 20 14:29:47 charon[2428]: 02[NET] <PEER|1> sending packet: from 192.168.0.1[4500] to 192.168.1.2[4500] (268 bytes)
-Jun 20 14:29:47 charon-systemd[2428]: sending packet: from 192.168.0.1[4500] to 192.168.1.2[4500] (268 bytes)
-Jun 20 14:29:47 charon[2428]: 13[NET] <PEER|1> received packet: from 192.168.1.2[4500] to 192.168.0.1[4500] (220 bytes)
-Jun 20 14:29:47 charon[2428]: 13[ENC] <PEER|1> parsed IKE_AUTH response 1 [ IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) ]
-Jun 20 14:29:47 charon-systemd[2428]: received packet: from 192.168.1.2[4500] to 192.168.0.1[4500] (220 bytes)
-Jun 20 14:29:47 charon[2428]: 13[IKE] <PEER|1> authentication of '192.168.1.2' with pre-shared key successful
-Jun 20 14:29:47 charon-systemd[2428]: parsed IKE_AUTH response 1 [ IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) ]
-Jun 20 14:29:47 charon[2428]: 13[IKE] <PEER|1> peer supports MOBIKE
-Jun 20 14:29:47 charon-systemd[2428]: authentication of '192.168.1.2' with pre-shared key successful
-Jun 20 14:29:47 charon[2428]: 13[IKE] <PEER|1> IKE_SA PEER[1] established between 192.168.0.1[192.168.0.1]...192.168.1.2[192.168.1.2]
-Jun 20 14:29:47 charon-systemd[2428]: peer supports MOBIKE
-Jun 20 14:29:47 charon[2428]: 13[IKE] <PEER|1> scheduling rekeying in 27703s
-Jun 20 14:29:47 charon-systemd[2428]: IKE_SA PEER[1] established between 192.168.0.1[192.168.0.1]...192.168.1.2[192.168.1.2]
-Jun 20 14:29:47 charon[2428]: 13[IKE] <PEER|1> maximum IKE_SA lifetime 30583s
-Jun 20 14:29:47 charon-systemd[2428]: scheduling rekeying in 27703s
-Jun 20 14:29:47 charon[2428]: 13[CFG] <PEER|1> selected proposal: ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ
-Jun 20 14:29:47 charon-systemd[2428]: maximum IKE_SA lifetime 30583s
-Jun 20 14:29:47 charon-systemd[2428]: selected proposal: ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ
-Jun 20 14:29:47 charon[2428]: 13[IKE] <PEER|1> CHILD_SA PEER-tunnel-1{1} established with SPIs cb94fb3f_i ca99c8a9_o and TS 10.0.0.0/24 === 10.0.1.0/24
-Jun 20 14:29:47 charon-systemd[2428]: CHILD_SA PEER-tunnel-1{1} established with SPIs cb94fb3f_i ca99c8a9_o and TS 10.0.0.0/24 === 10.0.1.0/24
-```
-
-## Troubleshooting Examples
-
-### IKE PROPOSAL are Different
-In this situation, IKE SAs can be down or not active.
-
-```none
-vyos@vyos:~$ show vpn ike sa
-```
-
-The problem is in IKE phase (Phase 1). The next step is checking debug logs.
-
-Responder Side:
-
-```none
-Jun 23 07:36:33 charon[2440]: 01[CFG] <1> received proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
-Jun 23 07:36:33 charon-systemd[2440]: received proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
-Jun 23 07:36:33 charon[2440]: 01[CFG] <1> configured proposals: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
-Jun 23 07:36:33 charon-systemd[2440]: configured proposals: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
-Jun 23 07:36:33 charon[2440]: 01[IKE] <1> received proposals unacceptable
-Jun 23 07:36:33 charon-systemd[2440]: received proposals unacceptable
-Jun 23 07:36:33 charon[2440]: 01[ENC] <1> generating IKE_SA_INIT response 0 [ N(NO_PROP) ]
-```
-
-Initiator side:
-
-```none
-Jun 23 07:36:32 charon-systemd[2444]: parsed IKE_SA_INIT response 0 [ N(NO_PROP) ]
-Jun 23 07:36:32 charon[2444]: 14[IKE] <PEER|1> received NO_PROPOSAL_CHOSEN notify error
-Jun 23 07:36:32 charon-systemd[2444]: received NO_PROPOSAL_CHOSEN notify error
-```
-
-The notification **NO_PROPOSAL_CHOSEN** means that the proposal mismatch.
-On the Responder side there is concrete information where is mismatch.
-Encryption **AES_CBC_128** is configured in IKE policy on the responder
-but **AES_CBC_256** is configured on the initiator side.
-
-### PSK Secret Mismatch
-In this situation, IKE SAs can be down or not active.
-
-```none
-vyos@vyos:~$ show vpn ike sa
-```
-
-The problem is in IKE phase (Phase 1). The next step is checking debug logs.
-
-Responder:
-
-```none
-Jun 23 08:07:26 charon-systemd[2440]: tried 1 shared key for '192.168.1.2' - '192.168.0.1', but MAC mismatched
-Jun 23 08:07:26 charon[2440]: 13[ENC] <PEER|3> generating IKE_AUTH response 1 [ N(AUTH_FAILED) ]
-```
-
-Initiator side:
-
-```none
-Jun 23 08:07:24 charon[2436]: 12[ENC] <PEER|1> parsed IKE_AUTH response 1 [ N(AUTH_FAILED) ]
-Jun 23 08:07:24 charon-systemd[2436]: parsed IKE_AUTH response 1 [ N(AUTH_FAILED) ]
-Jun 23 08:07:24 charon[2436]: 12[IKE] <PEER|1> received AUTHENTICATION_FAILED notify error
-Jun 23 08:07:24 charon-systemd[2436]: received AUTHENTICATION_FAILED notify error
-```
-
-The notification **AUTHENTICATION_FAILED** means that the authentication
-is failed. There is a reason to check PSK on both side.
-
-### ESP Proposal Mismatch
-The output of **show** commands shows us that IKE SA is established but
-IPSec SA is not.
-
-```none
-vyos@vyos:~$ show vpn ike sa
-Peer ID / IP                            Local ID / IP
-------------                            -------------
-192.168.1.2 192.168.1.2                 192.168.0.1 192.168.0.1
-
-    State  IKEVer  Encrypt      Hash          D-H Group      NAT-T  A-Time  L-Time
-    -----  ------  -------      ----          ---------      -----  ------  ------
-    up     IKEv2   AES_CBC_128  HMAC_SHA1_96  MODP_2048      no     158     26817
-```
-
-```none
-vyos@vyos:~$ show vpn ipsec sa
-Connection    State    Uptime    Bytes In/Out    Packets In/Out    Remote address    Remote ID    Proposal
-------------  -------  --------  --------------  ----------------  ----------------  -----------  ----------
-```
-
-The next step is checking debug logs.
-
-Initiator side:
-
-```none
-Jun 23 08:16:10 charon[3789]: 13[NET] <PEER|1> received packet: from 192.168.1.2[500] to 192.168.0.1[500] (472 bytes)
-Jun 23 08:16:10 charon[3789]: 13[ENC] <PEER|1> parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(CHDLESS_SUP) N(MULT_AUTH) ]
-Jun 23 08:16:10 charon-systemd[3789]: received packet: from 192.168.1.2[500] to 192.168.0.1[500] (472 bytes)
-Jun 23 08:16:10 charon[3789]: 13[CFG] <PEER|1> selected proposal: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
-Jun 23 08:16:10 charon-systemd[3789]: parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(CHDLESS_SUP) N(MULT_AUTH) ]
-Jun 23 08:16:10 charon-systemd[3789]: selected proposal: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
-Jun 23 08:16:10 charon[3789]: 13[IKE] <PEER|1> authentication of '192.168.0.1' (myself) with pre-shared key
-Jun 23 08:16:10 charon-systemd[3789]: authentication of '192.168.0.1' (myself) with pre-shared key
-Jun 23 08:16:10 charon[3789]: 13[IKE] <PEER|1> establishing CHILD_SA PEER-tunnel-1{1}
-Jun 23 08:16:10 charon-systemd[3789]: establishing CHILD_SA PEER-tunnel-1{1}
-Jun 23 08:16:10 charon[3789]: 13[ENC] <PEER|1> generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
-Jun 23 08:16:10 charon-systemd[3789]: generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
-Jun 23 08:16:10 charon[3789]: 13[NET] <PEER|1> sending packet: from 192.168.0.1[4500] to 192.168.1.2[4500] (268 bytes)
-Jun 23 08:16:10 charon-systemd[3789]: sending packet: from 192.168.0.1[4500] to 192.168.1.2[4500] (268 bytes)
-Jun 23 08:16:10 charon[3789]: 09[NET] <PEER|1> received packet: from 192.168.1.2[4500] to 192.168.0.1[4500] (140 bytes)
-Jun 23 08:16:10 charon-systemd[3789]: received packet: from 192.168.1.2[4500] to 192.168.0.1[4500] (140 bytes)
-Jun 23 08:16:10 charon[3789]: 09[ENC] <PEER|1> parsed IKE_AUTH response 1 [ IDr AUTH N(MOBIKE_SUP) N(NO_ADD_ADDR) N(NO_PROP) ]
-Jun 23 08:16:10 charon-systemd[3789]: parsed IKE_AUTH response 1 [ IDr AUTH N(MOBIKE_SUP) N(NO_ADD_ADDR) N(NO_PROP) ]
-Jun 23 08:16:10 charon[3789]: 09[IKE] <PEER|1> authentication of '192.168.1.2' with pre-shared key successful
-Jun 23 08:16:10 charon-systemd[3789]: authentication of '192.168.1.2' with pre-shared key successful
-Jun 23 08:16:10 charon[3789]: 09[IKE] <PEER|1> peer supports MOBIKE
-Jun 23 08:16:10 charon-systemd[3789]: peer supports MOBIKE
-Jun 23 08:16:10 charon[3789]: 09[IKE] <PEER|1> IKE_SA PEER[1] established between 192.168.0.1[192.168.0.1]...192.168.1.2[192.168.1.2]
-Jun 23 08:16:10 charon-systemd[3789]: IKE_SA PEER[1] established between 192.168.0.1[192.168.0.1]...192.168.1.2[192.168.1.2]
-Jun 23 08:16:10 charon[3789]: 09[IKE] <PEER|1> scheduling rekeying in 26975s
-Jun 23 08:16:10 charon-systemd[3789]: scheduling rekeying in 26975s
-Jun 23 08:16:10 charon[3789]: 09[IKE] <PEER|1> maximum IKE_SA lifetime 29855s
-Jun 23 08:16:10 charon-systemd[3789]: maximum IKE_SA lifetime 29855s
-Jun 23 08:16:10 charon[3789]: 09[IKE] <PEER|1> received NO_PROPOSAL_CHOSEN notify, no CHILD_SA built
-Jun 23 08:16:10 charon-systemd[3789]: received NO_PROPOSAL_CHOSEN notify, no CHILD_SA built
-Jun 23 08:16:10 charon[3789]: 09[IKE] <PEER|1> failed to establish CHILD_SA, keeping IKE_SA
-Jun 23 08:16:10 charon-systemd[3789]: failed to establish CHILD_SA, keeping IKE_SA
-```
-
-There are messages: **NO_PROPOSAL_CHOSEN** and
-**failed to establish CHILD_SA** which refers that the problem is in
-the IPsec(ESP) proposal mismatch.
-
-The reason of this problem is showed on the responder side.
-
-```none
-Jun 23 08:16:12 charon[2440]: 01[CFG] <PEER|5> received proposals: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ
-Jun 23 08:16:12 charon-systemd[2440]: received proposals: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ
-Jun 23 08:16:12 charon[2440]: 01[CFG] <PEER|5> configured proposals: ESP:AES_CBC_128/HMAC_SHA1_96/MODP_2048/NO_EXT_SEQ
-Jun 23 08:16:12 charon-systemd[2440]: configured proposals: ESP:AES_CBC_128/HMAC_SHA1_96/MODP_2048/NO_EXT_SEQ
-Jun 23 08:16:12 charon[2440]: 01[IKE] <PEER|5> no acceptable proposal found
-Jun 23 08:16:12 charon-systemd[2440]: no acceptable proposal found
-Jun 23 08:16:12 charon[2440]: 01[IKE] <PEER|5> failed to establish CHILD_SA, keeping IKE_SA
-```
-
-Encryption **AES_CBC_128** is configured in IKE policy on the responder but **AES_CBC_256**
-is configured on the initiator side.
-
-### Prefixes in Policies Mismatch
-As in previous situation, IKE SA is in up state but IPsec SA is not up.
-According to logs we can see **TS_UNACCEPTABLE** notification. It means
-that prefixes (traffic selectors) mismatch on both sides
-
-Initiator:
-
-```none
-Jun 23 14:13:17 charon[4996]: 11[IKE] <PEER|1> received TS_UNACCEPTABLE notify, no CHILD_SA built
-Jun 23 14:13:17 charon-systemd[4996]: maximum IKE_SA lifetime 29437s
-Jun 23 14:13:17 charon[4996]: 11[IKE] <PEER|1> failed to establish CHILD_SA, keeping IKE_SA
-Jun 23 14:13:17 charon-systemd[4996]: received TS_UNACCEPTABLE notify, no CHILD_SA built
-Jun 23 14:13:17 charon-systemd[4996]: failed to establish CHILD_SA, keeping IKE_SA
-```
-
-The reason of this problem is showed on the responder side.
-
-```none
-Jun 23 14:13:19 charon[2440]: 01[IKE] <PEER|7> traffic selectors 10.0.2.0/24 === 10.0.0.0/24 unacceptable
-Jun 23 14:13:19 charon-systemd[2440]: traffic selectors 10.0.2.0/24 === 10.0.0.0/24 unacceptable
-Jun 23 14:13:19 charon[2440]: 01[IKE] <PEER|7> failed to establish CHILD_SA, keeping IKE_SA
-Jun 23 14:13:19 charon-systemd[2440]: failed to establish CHILD_SA, keeping IKE_SA
-Jun 23 14:13:19 charon[2440]: 01[ENC] <PEER|7> generating IKE_AUTH response 1 [ IDr AUTH N(MOBIKE_SUP) N(NO_ADD_ADDR) N(TS_UNACCEPT) ]
-Jun 23 14:13:19 charon-systemd[2440]: generating IKE_AUTH response 1 [ IDr AUTH N(MOBIKE_SUP) N(NO_ADD_ADDR) N(TS_UNACCEPT) ]
-```
-
-Traffic selectors **10.0.2.0/24 === 10.0.0.0/24** are unacceptable on the
-responder side.