Page MenuHomeVyOS Platform

IPsec tunnel will break when ESP timeout
Closed, ResolvedPublicBUG

Description

I noticed that the two peer tunnel will broken when esp timeout (I used 30 sec to check it faster).
Even if I set DPD and close-action as restart, it would not reconnect ever.

IPsec will show the connection is ESTABLISHED but it will not go to INSTALLED step.

This is very easy to reproduce, just connecting two vyos by ipsec then set the esp timeout very low, and it will be.

Is it a bug or my config is wrong ? please help me.

The ike and esp config like these:

esp-group default {
     lifetime 30
     mode transport
     pfs dh-group2
     proposal 1 {
         encryption aes128
         hash sha1
     }
 }
 ike-group default {
     close-action restart
     dead-peer-detection {
         action restart
     }
     key-exchange ikev1
     lifetime 86400
     proposal 1 {
         dh-group 14
         encryption aes128
         hash sha1
     }
 }
site-to-site {
     peer <right> {
         authentication {
             mode pre-shared-secret
             pre-shared-secret myipseckey
         }
         default-esp-group default
         ike-group default
         local-address <left>
         tunnel 0 {
             esp-group default
         }
     }
 }

Details

Difficulty level
Unknown (require assessment)
Version
VyOS 1.4-rolling-202203070319
Why the issue appeared?
Implementation mistake
Is it a breaking change?
Unspecified (possibly destroys the router)
Issue type
Bug (incorrect behavior)

Event Timeline

I found the swanctl.conf.
The config does not match the vyso config.

I set the close_action as restart, but config does not show this line.

children {
    peer_xxx_tunnel_0 {
        esp_proposals = aes128-sha1-modp1024
        life_time = 30s
        local_ts = xxx
        remote_ts = xxx
        ipcomp = no
        mode = transport
        start_action = start
        dpd_action = start
    }
}
chesskuo triaged this task as High priority.Mar 8 2022, 3:30 AM
chesskuo changed Why the issue appeared? from Will be filled on close to Implementation mistake.

Could you try to use "ikev2"? Will the same problem be if you use "ikev2"?

Hello sir, thank you !!!

I tried ikev2 and it reconnect automatically.

When I set the different close_action and dpd_action value, it show its behavior now!

Please let me ask a question.
Why ikev1 will break this behavior?

I found the swanctl.conf.
The config does not match the vyso config.

I set the close_action as restart, but config does not show this line.

https://wiki.strongswan.org/projects/strongswan/wiki/Fromipsecconf

ipsec.conf dpdaction=restart => swactl.conf connections.<conn>.children.<child>.dpd_action=start

emmm, I know it.

I just mean I set the behavior as restart.
You can see it on my swanctl.conf

IKEv2 has a different working behavior compared to the IKEv1. IKEv2 provides proper inline rekeying of IKE SAs by use of CREATE_CHILD_SA exchanges. This means that new keys may be established without any interruption of the existing IKE and IPsec SAs.

The dpdaction triggers only if a peer does not respond. The closeaction does not guarantee that a tunnel keeps up, but just that it gets recreated if it is actively deleted by the peer.
The default of none does not take any action. trap installs a trap policy for the CHILD_SA and start tries to re-create the CHILD_SA. close_action does not provide any guarantee that the CHILD_SA is kept alive. It acts on explicit close messages only but not on negotiation failures. Use trap policies to reliably re-create failed CHILD_SAs

If VyOS compared to strongswan settings, these are the conversions of the action:

Action:

none | clear    ---> connections.<conn>.children.<child>.close_action=none (default)
hold               ---> connections.<conn>.children.<child>.close_action=trap
restart            ---> connections.<conn>.children.<child>.close_action=start

close_action parameter is missing from the swanctl.conf, I will submit PR soon to add this option

Viacheslav changed the task status from Open to Needs testing.Apr 1 2022, 11:11 AM
m.korobeinikov changed the task status from Needs testing to In progress.EditedApr 10 2022, 2:26 AM

I tested it with VyOS 1.4-rolling-202204090217 and it works well for a while.

1.4-rolling-202202210317 has the problem.

Is this problem relevant for versions 1.3.X 1.2.X?

VyOS 1.3 and 1.2 use the legacy Perl based IPSec implementation. A test would still be good just to be sure!

m.korobeinikov changed the task status from In progress to Needs testing.Apr 10 2022, 10:30 PM

image.png (319×992 px, 33 KB)

I've tested the scenario using VyOS 1.4-rolling-202204090217 and (esp lifetime '30'). Attached is the config.
After turning on the right and left routers, IPsec creates two tunnels that are updated every 10 seconds. (Tunnels are updated using strange intervals, the first 1-10 seconds, the second 10-20 seconds).

vyos@vyos:~$ show vpn ipsec sa
Connection                 State    Uptime    Bytes In/Out    Packets In/Out    Remote address    Remote ID    Proposal
-------------------------  -------  --------  --------------  ----------------  ----------------  -----------  ----------------------------------
peer_192-168-0-6_tunnel_0  up       10s       0B/0B           0B/0B             192.168.0.6       192.168.0.6  AES_CBC_128/HMAC_SHA1_96/MODP_1024
peer_192-168-0-6_tunnel_0  up       20s       0B/0B           0B/0B             192.168.0.6       192.168.0.6  AES_CBC_128/HMAC_SHA1_96/MODP_1024
vyos@vyos:~$ show vpn ipsec sa
Connection                 State    Uptime    Bytes In/Out    Packets In/Out    Remote address    Remote ID    Proposal
-------------------------  -------  --------  --------------  ----------------  ----------------  -----------  ----------------------------------
peer_192-168-0-6_tunnel_0  up       1s        0B/0B           0B/0B             192.168.0.6       192.168.0.6  AES_CBC_128/HMAC_SHA1_96/MODP_1024
peer_192-168-0-6_tunnel_0  up       11s       0B/0B           0B/0B             192.168.0.6       192.168.0.6  AES_CBC_128/HMAC_SHA1_96/MODP_1024

Every 10 seconds, there is an exchange between peers.

Apr 10 21:23:11 charon[1896]: 06[NET] <peer_192-168-0-6|35> received packet: from 192.168.0.6[500] to 192.168.0.5[500] (76 bytes)
Apr 10 21:23:11 charon[1896]: 06[ENC] <peer_192-168-0-6|35> parsed INFORMATIONAL_V1 request 3409847400 [ HASH D ]
Apr 10 21:23:11 charon[1896]: 06[IKE] <peer_192-168-0-6|35> received DELETE for ESP CHILD_SA with SPI c6a685c9
Apr 10 21:23:11 charon[1896]: 06[IKE] <peer_192-168-0-6|35> CHILD_SA not found, ignored
Apr 10 21:23:12 charon[1896]: 15[NET] <peer_192-168-0-6|34> received packet: from 192.168.0.6[500] to 192.168.0.5[500] (92 bytes)
Apr 10 21:23:12 charon[1896]: 15[ENC] <peer_192-168-0-6|34> parsed INFORMATIONAL_V1 request 2520092712 [ HASH D ]
Apr 10 21:23:12 charon[1896]: 15[IKE] <peer_192-168-0-6|34> received DELETE for IKE_SA peer_192-168-0-6[34]
Apr 10 21:23:12 charon[1896]: 15[IKE] <peer_192-168-0-6|34> deleting IKE_SA peer_192-168-0-6[34] between 192.168.0.5[192.168.0.5]...192.168.0.6[192.168.0.6]
Apr 10 21:23:12 charon[1896]: 15[IKE] <peer_192-168-0-6|34> restarting CHILD_SA peer_192-168-0-6_tunnel_0
Apr 10 21:23:12 charon[1896]: 15[IKE] <peer_192-168-0-6|34> initiating Main Mode IKE_SA peer_192-168-0-6[36] to 192.168.0.6
Apr 10 21:23:12 charon[1896]: 15[ENC] <peer_192-168-0-6|34> generating ID_PROT request 0 [ SA V V V V V ]
Apr 10 21:23:12 charon[1896]: 15[NET] <peer_192-168-0-6|34> sending packet: from 192.168.0.5[500] to 192.168.0.6[500] (180 bytes)
Apr 10 21:23:12 charon[1896]: 07[NET] <peer_192-168-0-6|36> received packet: from 192.168.0.6[500] to 192.168.0.5[500] (160 bytes)
Apr 10 21:23:12 charon[1896]: 07[ENC] <peer_192-168-0-6|36> parsed ID_PROT response 0 [ SA V V V V ]
Apr 10 21:23:12 charon[1896]: 07[IKE] <peer_192-168-0-6|36> received XAuth vendor ID
Apr 10 21:23:12 charon[1896]: 07[IKE] <peer_192-168-0-6|36> received DPD vendor ID
Apr 10 21:23:12 charon[1896]: 07[IKE] <peer_192-168-0-6|36> received FRAGMENTATION vendor ID
Apr 10 21:23:12 charon[1896]: 07[IKE] <peer_192-168-0-6|36> received NAT-T (RFC 3947) vendor ID
Apr 10 21:23:12 charon[1896]: 07[CFG] <peer_192-168-0-6|36> selected proposal: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
Apr 10 21:23:12 charon[1896]: 07[ENC] <peer_192-168-0-6|36> generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
Apr 10 21:23:12 charon[1896]: 07[NET] <peer_192-168-0-6|36> sending packet: from 192.168.0.5[500] to 192.168.0.6[500] (372 bytes)
Apr 10 21:23:12 charon[1896]: 09[NET] <peer_192-168-0-6|36> received packet: from 192.168.0.6[500] to 192.168.0.5[500] (372 bytes)
Apr 10 21:23:12 charon[1896]: 09[ENC] <peer_192-168-0-6|36> parsed ID_PROT response 0 [ KE No NAT-D NAT-D ]
Apr 10 21:23:12 charon[1896]: 09[ENC] <peer_192-168-0-6|36> generating ID_PROT request 0 [ ID HASH ]
Apr 10 21:23:12 charon[1896]: 09[NET] <peer_192-168-0-6|36> sending packet: from 192.168.0.5[500] to 192.168.0.6[500] (76 bytes)
Apr 10 21:23:12 charon[1896]: 08[NET] <peer_192-168-0-6|36> received packet: from 192.168.0.6[500] to 192.168.0.5[500] (76 bytes)
Apr 10 21:23:12 charon[1896]: 08[ENC] <peer_192-168-0-6|36> parsed ID_PROT response 0 [ ID HASH ]
Apr 10 21:23:12 charon[1896]: 08[IKE] <peer_192-168-0-6|36> IKE_SA peer_192-168-0-6[36] established between 192.168.0.5[192.168.0.5]...192.168.0.6[192.168.0.6]
Apr 10 21:23:12 charon[1896]: 08[IKE] <peer_192-168-0-6|36> scheduling rekeying in 2954s
Apr 10 21:23:12 charon[1896]: 08[IKE] <peer_192-168-0-6|36> maximum IKE_SA lifetime 3254s
Apr 10 21:23:12 charon[1896]: 08[ENC] <peer_192-168-0-6|36> generating QUICK_MODE request 2814802701 [ HASH SA No KE ID ID ]
Apr 10 21:23:12 charon[1896]: 08[NET] <peer_192-168-0-6|36> sending packet: from 192.168.0.5[500] to 192.168.0.6[500] (316 bytes)
Apr 10 21:23:12 charon[1896]: 12[NET] <peer_192-168-0-6|36> received packet: from 192.168.0.6[500] to 192.168.0.5[500] (316 bytes)
Apr 10 21:23:12 charon[1896]: 12[ENC] <peer_192-168-0-6|36> parsed QUICK_MODE response 2814802701 [ HASH SA No KE ID ID ]
Apr 10 21:23:12 charon[1896]: 12[CFG] <peer_192-168-0-6|36> selected proposal: ESP:AES_CBC_128/HMAC_SHA1_96/MODP_1024/NO_EXT_SEQ
Apr 10 21:23:12 charon[1896]: 12[IKE] <peer_192-168-0-6|36> CHILD_SA peer_192-168-0-6_tunnel_0{36} established with SPIs c3843a16_i ca742ab9_o and TS 10.0.0.0/24 === 
172.16.0.0/24
Apr 10 21:23:12 charon[1896]: 12[ENC] <peer_192-168-0-6|36> generating QUICK_MODE request 2814802701 [ HASH ]
Apr 10 21:23:12 charon[1896]: 12[NET] <peer_192-168-0-6|36> sending packet: from 192.168.0.5[500] to 192.168.0.6[500] (60 bytes)

In this state, IPSEC operates stably without loss.

But as soon as I disable the interface on one of the sides, incorrect behavior occurs:

  1. IPSEC operation is not restored after the interface is enabled.
  2. After rebooting the left IPSEC router, two cycles of 30 seconds each work (total of 60 sec.).
  3. After the VPN restart, the situation is similar.
Apr 10 21:48:03 charon[4587]: 11[KNL] creating delete job for CHILD_SA ESP/0xc01589fb/192.168.0.5
Apr 10 21:48:03 charon[4587]: 11[IKE] <peer_192-168-0-6|1> closing expired CHILD_SA peer_192-168-0-6_tunnel_0{1} with SPIs c01589fb_i c8c9a100_o and TS 10.0.0.0/24 === 172.16.0.0/24
Apr 10 21:48:03 charon[4587]: 11[IKE] <peer_192-168-0-6|1> sending DELETE for ESP CHILD_SA with SPI c01589fb
Apr 10 21:48:03 charon[4587]: 11[ENC] <peer_192-168-0-6|1> generating INFORMATIONAL_V1 request 403107873 [ HASH D ]
Apr 10 21:48:03 charon[4587]: 11[NET] <peer_192-168-0-6|1> sending packet: from 192.168.0.5[500] to 192.168.0.6[500] (76 bytes)
Apr 10 21:48:03 charon[4587]: 13[NET] <peer_192-168-0-6|1> received packet: from 192.168.0.6[500] to 192.168.0.5[500] (316 bytes)
Apr 10 21:48:03 charon[4587]: 13[ENC] <peer_192-168-0-6|1> parsed QUICK_MODE request 2893438187 [ HASH SA No KE ID ID ]
Apr 10 21:48:03 charon[4587]: 13[CFG] <peer_192-168-0-6|1> selected proposal: ESP:AES_CBC_128/HMAC_SHA1_96/MODP_1024/NO_EXT_SEQ
Apr 10 21:48:03 charon[4587]: 13[ENC] <peer_192-168-0-6|1> generating QUICK_MODE response 2893438187 [ HASH SA No KE ID ID ]
Apr 10 21:48:03 charon[4587]: 13[NET] <peer_192-168-0-6|1> sending packet: from 192.168.0.5[500] to 192.168.0.6[500] (316 bytes)
Apr 10 21:48:03 charon[4587]: 14[NET] <peer_192-168-0-6|1> received packet: from 192.168.0.6[500] to 192.168.0.5[500] (60 bytes)
Apr 10 21:48:03 charon[4587]: 14[ENC] <peer_192-168-0-6|1> parsed QUICK_MODE request 2893438187 [ HASH ]
Apr 10 21:48:03 charon[4587]: 14[IKE] <peer_192-168-0-6|1> CHILD_SA peer_192-168-0-6_tunnel_0{2} established with SPIs cd36900d_i cd7597c8_o and TS 10.0.0.0/24 === 172.16.0.0/24
vyos@vyos:~$ sudo swanctl -l
peer_192-168-0-6: #2, ESTABLISHED, IKEv1, 5415d10b6101229d_i* 63f0538d18d56f6e_r
local  '192.168.0.5' @ 192.168.0.5[500]
remote '192.168.0.6' @ 192.168.0.6[500]
AES_CBC-128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
established 26s ago, rekeying in 2865s
peer_192-168-0-6_tunnel_0: #1, reqid 1, INSTALLED, TUNNEL, ESP:AES_CBC-128/HMAC_SHA1_96/MODP_1024
  installed 26s ago, rekeying in 3574s, expires in 4s
  in  c32d23bc,   2016 bytes,    24 packets,     1s ago
  out ccd854b8,   2016 bytes,    24 packets,     1s ago
  local  10.0.0.0/24
  remote 172.16.0.0/24
vyos@vyos:~$
vyos@vyos:~$ sudo swanctl -l
peer_192-168-0-6: #2, ESTABLISHED, IKEv1, 5415d10b6101229d_i* 63f0538d18d56f6e_r
local  '192.168.0.5' @ 192.168.0.5[500]
remote '192.168.0.6' @ 192.168.0.6[500]
AES_CBC-128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
established 28s ago, rekeying in 2863s
peer_192-168-0-6_tunnel_0: #1, reqid 1, INSTALLED, TUNNEL, ESP:AES_CBC-128/HMAC_SHA1_96/MODP_1024
  installed 28s ago, rekeying in 3572s, expires in 2s
  in  c32d23bc,   2184 bytes,    26 packets,     1s ago
  out ccd854b8,   2184 bytes,    26 packets,     1s ago
  local  10.0.0.0/24
  remote 172.16.0.0/24
vyos@vyos:~$
vyos@vyos:~$ sudo swanctl -L
peer_192-168-0-6: IKEv1, reauthentication every 3000s, dpd delay 30s
local:  192.168.0.5
remote: 192.168.0.6
local pre-shared key authentication:
remote pre-shared key authentication:
  id: 192.168.0.6
peer_192-168-0-6_tunnel_0: TUNNEL, rekeying every 3600s, dpd action is restart
  local:  10.0.0.0/24
  remote: 172.16.0.0/24
vyos@vyos:~$
vyos@vyos:~$ sudo swanctl -q
loaded ike secret 'ike_192-168-0-6'
no authorities found, 0 unloaded
no pools found, 0 unloaded
loaded connection 'peer_192-168-0-6'
successfully loaded 1 connections, 0 unloaded

After 60 seconds of stable operation, there are constant DPD exchanges. IPSEC stops working.

Apr 10 22:04:57 charon[7003]: 14[IKE] <peer_192-168-0-6|2> sending DPD request
Apr 10 22:04:57 charon[7003]: 14[ENC] <peer_192-168-0-6|2> generating INFORMATIONAL_V1 request 1859315113 [ HASH N(DPD) ]
Apr 10 22:04:57 charon[7003]: 14[NET] <peer_192-168-0-6|2> sending packet: from 192.168.0.5[500] to 192.168.0.6[500] (92 bytes)
Apr 10 22:04:57 charon[7003]: 05[NET] <peer_192-168-0-6|2> received packet: from 192.168.0.6[500] to 192.168.0.5[500] (92 bytes)
Apr 10 22:04:57 charon[7003]: 05[ENC] <peer_192-168-0-6|2> parsed INFORMATIONAL_V1 request 1981536034 [ HASH N(DPD_ACK) ]

If you reboot two routers, IPSec will work until one of the interfaces is disabled.
Further, the incorrect scenario of work begins to be repeated.

LEFT
set interfaces ethernet eth0 address 192.168.0.5/24
set interfaces ethernet eth7 address 10.0.0.2/24
set vpn ipsec interface eth0

set vpn ipsec esp-group ESP-GROUP mode transport
set vpn ipsec esp-group ESP-GROUP lifetime 30
set vpn ipsec esp-group ESP-GROUP pfs dh-group2
set vpn ipsec esp-group ESP-GROUP proposal 1 encryption aes128
set vpn ipsec esp-group ESP-GROUP proposal 1 hash sha1

set vpn ipsec ike-group IKE-GROUP close-action restart
set vpn ipsec ike-group IKE-GROUP dead-peer-detection action restart
set vpn ipsec ike-group IKE-GROUP key-exchange ikev1
set vpn ipsec ike-group IKE-GROUP lifetime 86400
set vpn ipsec ike-group IKE-GROUP proposal 1 dh-group 14
set vpn ipsec ike-group IKE-GROUP proposal 1 encryption aes128
set vpn ipsec ike-group IKE-GROUP proposal 1 hash sha1


set vpn ipsec site-to-site peer 192.168.0.6 authentication mode pre-shared-secret
set vpn ipsec site-to-site peer 192.168.0.6 authentication pre-shared-secret 'megatest'
set vpn ipsec site-to-site peer 192.168.0.6 local-address 192.168.0.5
set vpn ipsec site-to-site peer 192.168.0.6 ike-group IKE-GROUP
set vpn ipsec site-to-site peer 192.168.0.6 default-esp-group ESP-GROUP

set vpn ipsec site-to-site peer 192.168.0.6 tunnel 0 esp-group 'ESP-GROUP'

set vpn ipsec site-to-site peer 192.168.0.6 tunnel 0 local prefix 10.0.0.0/24
set vpn ipsec site-to-site peer 192.168.0.6 tunnel 0 remote prefix 172.16.0.0/24 

RIGHT

set interfaces ethernet eth0 address 192.168.0.6/24
set interfaces ethernet eth7 address 172.16.0.1/24
set vpn ipsec interface eth0

set vpn ipsec esp-group ESP-GROUP mode transport
set vpn ipsec esp-group ESP-GROUP lifetime 30
set vpn ipsec esp-group ESP-GROUP pfs dh-group2
set vpn ipsec esp-group ESP-GROUP proposal 1 encryption aes128
set vpn ipsec esp-group ESP-GROUP proposal 1 hash sha1

set vpn ipsec ike-group IKE-GROUP close-action restart
set vpn ipsec ike-group IKE-GROUP dead-peer-detection action restart
set vpn ipsec ike-group IKE-GROUP key-exchange ikev1
set vpn ipsec ike-group IKE-GROUP lifetime 86400
set vpn ipsec ike-group IKE-GROUP proposal 1 dh-group 14
set vpn ipsec ike-group IKE-GROUP proposal 1 encryption aes128
set vpn ipsec ike-group IKE-GROUP proposal 1 hash sha1


set vpn ipsec site-to-site peer 192.168.0.5 authentication mode pre-shared-secret
set vpn ipsec site-to-site peer 192.168.0.5 authentication pre-shared-secret 'megatest'
set vpn ipsec site-to-site peer 192.168.0.5 local-address 192.168.0.6
set vpn ipsec site-to-site peer 192.168.0.5 ike-group IKE-GROUP
set vpn ipsec site-to-site peer 192.168.0.5 default-esp-group ESP-GROUP

set vpn ipsec site-to-site peer 192.168.0.5 tunnel 0 esp-group 'ESP-GROUP'


set vpn ipsec site-to-site peer 192.168.0.5 tunnel 0 local prefix 172.16.0.0/24
set vpn ipsec site-to-site peer 192.168.0.5 tunnel 0 remote prefix 10.0.0.0/24

@m.korobeinikov I believe that I already posted this some time ago, but just in case...
Not all combinations of DPD and close-action are safe. Actually, most of them sooner or later will lead to issues with IPSec. So, I created the next scheme. It is from 2020, so I will not say that nothing was changed from that time, however, it shows well how careful you should be while configuring IPSec. On the scheme, you can see the only safe configuration of the close-action option, depending on how the peer is configured, but the same logic can be applied to DPD.

IPSec site-to-site IKE configuration.png (780×1 px, 27 KB)

syncer lowered the priority of this task from High to Low.Jul 11 2023, 12:30 PM

Tested in the latest rolling release with both ipsec configured as tunnel and transport mode . As suggested in the above comment, with the correct close-action setting configured in both the initiator and responder side, then no duplicate child_sa are noticed.

Tried different scenarios and sharing one if it, where esp mode is transport and least lifetime i.e 30s configured with gre protocol

If no close-action is configured on the responder side, and the ipsec interface is disable and enable, then multiple childs are opened in few seconds and double entries seen for ike sa output. Only reboot helps to close the child_sa.

Peer1"

set interfaces tunnel tun0 address '10.10.10.1/30'
set interfaces tunnel tun0 encapsulation 'gre'
set interfaces tunnel tun0 remote '10.0.0.1'
set interfaces tunnel tun0 source-address '10.0.0.2'
set interfaces vti vti0 address '172.16.10.1/30'
set vpn ipsec authentication psk test id '10.0.0.2'
set vpn ipsec authentication psk test secret 'vyos'
set vpn ipsec esp-group ESP-GROUP lifetime '30'
set vpn ipsec esp-group ESP-GROUP mode 'transport'
set vpn ipsec esp-group ESP-GROUP pfs 'dh-group2'
set vpn ipsec esp-group ESP-GROUP proposal 1 encryption 'aes128'
set vpn ipsec esp-group ESP-GROUP proposal 1 hash 'sha1'
set vpn ipsec ike-group IKE-GROUP close-action 'restart'
set vpn ipsec ike-group IKE-GROUP dead-peer-detection action 'restart'
set vpn ipsec ike-group IKE-GROUP key-exchange 'ikev1'
set vpn ipsec ike-group IKE-GROUP lifetime '86400'
set vpn ipsec ike-group IKE-GROUP proposal 1 dh-group '14'
set vpn ipsec ike-group IKE-GROUP proposal 1 encryption 'aes128'
set vpn ipsec ike-group IKE-GROUP proposal 1 hash 'sha1'
set vpn ipsec interface 'eth1'
set vpn ipsec site-to-site peer test authentication local-id '10.0.0.2'
set vpn ipsec site-to-site peer test authentication mode 'pre-shared-secret'
set vpn ipsec site-to-site peer test authentication remote-id '10.0.0.1'
set vpn ipsec site-to-site peer test connection-type 'initiate'
set vpn ipsec site-to-site peer test default-esp-group 'ESP-GROUP'
set vpn ipsec site-to-site peer test ike-group 'IKE-GROUP'
set vpn ipsec site-to-site peer test local-address '10.0.0.2'
set vpn ipsec site-to-site peer test remote-address '10.0.0.1'
set vpn ipsec site-to-site peer test tunnel 1 protocol 'gre'

peer2:

set interfaces tunnel tun0 address '10.10.10.2/30'
set interfaces tunnel tun0 encapsulation 'gre'
set interfaces tunnel tun0 remote '10.0.0.2'
set interfaces tunnel tun0 source-address '10.0.0.1'
set vpn ipsec authentication psk test1 id '10.0.0.1'
set vpn ipsec authentication psk test1 secret 'vyos'
set vpn ipsec esp-group ESP-GROUP lifetime '30'
set vpn ipsec esp-group ESP-GROUP mode 'transport'
set vpn ipsec esp-group ESP-GROUP pfs 'dh-group2'
set vpn ipsec esp-group ESP-GROUP proposal 1 encryption 'aes128'
set vpn ipsec esp-group ESP-GROUP proposal 1 hash 'sha1'
set vpn ipsec ike-group IKE-GROUP close-action 'hold'
set vpn ipsec ike-group IKE-GROUP dead-peer-detection action 'clear'
set vpn ipsec ike-group IKE-GROUP key-exchange 'ikev1'
set vpn ipsec ike-group IKE-GROUP lifetime '86400'
set vpn ipsec ike-group IKE-GROUP proposal 1 dh-group '14'
set vpn ipsec ike-group IKE-GROUP proposal 1 encryption 'aes128'
set vpn ipsec ike-group IKE-GROUP proposal 1 hash 'sha1'
set vpn ipsec interface 'eth1'
set vpn ipsec site-to-site peer test authentication local-id '10.0.0.1'
set vpn ipsec site-to-site peer test authentication mode 'pre-shared-secret'
set vpn ipsec site-to-site peer test authentication remote-id '10.0.0.2'
set vpn ipsec site-to-site peer test connection-type 'respond'
set vpn ipsec site-to-site peer test default-esp-group 'ESP-GROUP'
set vpn ipsec site-to-site peer test ike-group 'IKE-GROUP'
set vpn ipsec site-to-site peer test local-address '10.0.0.1'
set vpn ipsec site-to-site peer test remote-address '10.0.0.2'
set vpn ipsec site-to-site peer test tunnel 1 protocol 'gre'