Site-to-Site VPN deleting IKE_SA

General questions
,
1

Hello, we have site-to-site VPN IPSec tunnel with vyos (behind nat, version 1.3, public ip 61.65.209.66, eth0 ip - 10.67.48.55) and cisco (public ip 81.200.100.241). VPN connection works fine, but almost every two hours I see in logs that tunnel has restarted:

received DELETE for IKE_SA peer-81.200.100.241-tunnel-0[5]

and that starts restarting CHILD_SA and initiating IKE_SA. What could be the reason for that and how bad it is if tunnel acts like that.

Full log below.

Oct 19 07:20:49 vyos charon: 12[NET] <peer-81.200.100.241-tunnel-0|5> sending packet: from 10.67.48.55[4500] to 81.200.100.241[4500] (80 bytes)
Oct 19 07:21:03 vyos charon: 13[NET] <peer-81.200.100.241-tunnel-0|5> received packet: from 81.200.100.241[4500] to 10.67.48.55[4500] (80 bytes)
Oct 19 07:21:03 vyos charon: 13[ENC] <peer-81.200.100.241-tunnel-0|5> parsed INFORMATIONAL request 442 [ ]
Oct 19 07:21:03 vyos charon: 13[ENC] <peer-81.200.100.241-tunnel-0|5> generating INFORMATIONAL response 442 [ ]
Oct 19 07:21:03 vyos charon: 13[NET] <peer-81.200.100.241-tunnel-0|5> sending packet: from 10.67.48.55[4500] to 81.200.100.241[4500] (80 bytes)
Oct 19 07:21:19 vyos charon: 09[NET] <peer-81.200.100.241-tunnel-0|5> received packet: from 81.200.100.241[4500] to 10.67.48.55[4500] (80 bytes)
Oct 19 07:21:19 vyos charon: 09[ENC] <peer-81.200.100.241-tunnel-0|5> parsed INFORMATIONAL request 443 [ D ]
Oct 19 07:21:19 vyos charon: 09[IKE] <peer-81.200.100.241-tunnel-0|5> received DELETE for IKE_SA peer-81.200.100.241-tunnel-0[5]
Oct 19 07:21:19 vyos charon: 09[IKE] <peer-81.200.100.241-tunnel-0|5> deleting IKE_SA peer-81.200.100.241-tunnel-0[5] between 10.67.48.55[61.65.209.66]...81.200.100.241[81.200.100.241]
Oct 19 07:21:19 vyos charon: 09[IKE] <peer-81.200.100.241-tunnel-0|5> restarting CHILD_SA peer-81.200.100.241-tunnel-0
Oct 19 07:21:19 vyos charon: 09[IKE] <peer-81.200.100.241-tunnel-0|5> initiating IKE_SA peer-81.200.100.241-tunnel-0[6] to 81.200.100.241
Oct 19 07:21:19 vyos charon: 09[ENC] <peer-81.200.100.241-tunnel-0|5> generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
Oct 19 07:21:19 vyos charon: 09[NET] <peer-81.200.100.241-tunnel-0|5> sending packet: from 10.67.48.55[500] to 81.200.100.241[500] (340 bytes)
Oct 19 07:21:19 vyos charon: 09[IKE] <peer-81.200.100.241-tunnel-0|5> IKE_SA deleted
Oct 19 07:21:19 vyos charon: 09[ENC] <peer-81.200.100.241-tunnel-0|5> generating INFORMATIONAL response 443 [ ]
Oct 19 07:21:19 vyos charon: 09[NET] <peer-81.200.100.241-tunnel-0|5> sending packet: from 10.67.48.55[4500] to 81.200.100.241[4500] (80 bytes)
Oct 19 07:21:19 vyos charon: 10[NET] <peer-81.200.100.241-tunnel-0|6> received packet: from 81.200.100.241[500] to 10.67.48.55[500] (555 bytes)
Oct 19 07:21:19 vyos charon: 10[ENC] <peer-81.200.100.241-tunnel-0|6> parsed IKE_SA_INIT response 0 [ SA KE No V V N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) V ]
Oct 19 07:21:19 vyos charon: 10[IKE] <peer-81.200.100.241-tunnel-0|6> received Cisco Delete Reason vendor ID
Oct 19 07:21:19 vyos charon: 10[IKE] <peer-81.200.100.241-tunnel-0|6> received Cisco Copyright (c) 2009 vendor ID
Oct 19 07:21:19 vyos charon: 10[IKE] <peer-81.200.100.241-tunnel-0|6> received FRAGMENTATION vendor ID
Oct 19 07:21:19 vyos charon: 10[CFG] <peer-81.200.100.241-tunnel-0|6> selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_521
Oct 19 07:21:19 vyos charon: 10[IKE] <peer-81.200.100.241-tunnel-0|6> local host is behind NAT, sending keep alives
Oct 19 07:21:19 vyos charon: 10[IKE] <peer-81.200.100.241-tunnel-0|6> received 5 cert requests for an unknown ca
Oct 19 07:21:19 vyos charon: 10[IKE] <peer-81.200.100.241-tunnel-0|6> authentication of '61.65.209.66' (myself) with pre-shared key
Oct 19 07:21:19 vyos charon: 10[IKE] <peer-81.200.100.241-tunnel-0|6> establishing CHILD_SA peer-81.200.100.241-tunnel-0{6} reqid 5
Oct 19 07:21:19 vyos charon: 10[ENC] <peer-81.200.100.241-tunnel-0|6> generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH SA TSi TSr N(MOBIKE_SUP)N(NO_ADD_ADDR) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
Oct 19 07:21:19 vyos charon: 10[NET] <peer-81.200.100.241-tunnel-0|6> sending packet: from 10.67.48.55[4500] to 81.200.100.241[4500] (272 bytes)
Oct 19 07:21:19 vyos charon: 07[NET] <peer-81.200.100.241-tunnel-0|6> received packet: from 81.200.100.241[4500] to 10.67.48.55[4500] (256 bytes)
Oct 19 07:21:19 vyos charon: 07[ENC] <peer-81.200.100.241-tunnel-0|6> parsed IKE_AUTH response 1 [ V IDr AUTH SA TSi TSr N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG)N(MOBIKE_SUP) ]
Oct 19 07:21:19 vyos charon: 07[IKE] <peer-81.200.100.241-tunnel-0|6> authentication of '81.200.100.241' with pre-shared key successful
Oct 19 07:21:19 vyos charon: 07[IKE] <peer-81.200.100.241-tunnel-0|6> IKE_SA peer-81.200.100.241-tunnel-0[6] established between 10.67.48.55[61.65.209.66]...81.200.100.241[81.200.100.241]
Oct 19 07:21:19 vyos charon: 07[IKE] <peer-81.200.100.241-tunnel-0|6> scheduling rekeying in 85593s
Oct 19 07:21:19 vyos charon: 07[IKE] <peer-81.200.100.241-tunnel-0|6> maximum IKE_SA lifetime 86133s
Oct 19 07:21:19 vyos charon: 07[IKE] <peer-81.200.100.241-tunnel-0|6> received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
Oct 19 07:21:19 vyos charon: 07[CFG] <peer-81.200.100.241-tunnel-0|6> selected proposal: ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ
Oct 19 07:21:19 vyos charon: 07[IKE] <peer-81.200.100.241-tunnel-0|6> CHILD_SA peer-81.200.100.241-tunnel-0{6} established with SPIs ce7bedcc_i 1025fb82_o and TS 172.31.0.0/30 === 81.200.100.0/25
Oct 19 07:21:19 vyos charon: 07[IKE] <peer-81.200.100.241-tunnel-0|6> peer supports MOBIKE
Oct 19 07:21:35 vyos charon: 06[NET] <peer-81.200.100.241-tunnel-0|6> received packet: from 81.200.100.241[4500] to 10.67.48.55[4500] (80 bytes)
Oct 19 07:21:35 vyos charon: 06[ENC] <peer-81.200.100.241-tunnel-0|6> parsed INFORMATIONAL request 0 [ ]
Oct 19 07:21:35 vyos charon: 06[ENC] <peer-81.200.100.241-tunnel-0|6> generating INFORMATIONAL response 0 [ ]
Oct 19 07:21:35 vyos charon: 06[NET] <peer-81.200.100.241-tunnel-0|6> sending packet: from 10.67.48.55[4500] to 81.200.100.241[4500] (80 bytes)
Oct 19 07:21:51 vyos charon: 16[NET] <peer-81.200.100.241-tunnel-0|6> received packet: from 81.200.100.241[4500] to 10.67.48.55[4500] (80 bytes)
Oct 19 07:21:51 vyos charon: 16[ENC] <peer-81.200.100.241-tunnel-0|6> parsed INFORMATIONAL request 1 [ ]
Oct 19 07:21:51 vyos charon: 16[ENC] <peer-81.200.100.241-tunnel-0|6> generating INFORMATIONAL response 1 [ ]
Oct 19 07:21:51 vyos charon: 16[NET] <peer-81.200.100.241-tunnel-0|6> sending packet: from 10.67.48.55[4500] to 81.200.100.241[4500] (80 bytes)
Oct 19 07:22:21 vyos charon: 06[NET] <peer-81.200.100.241-tunnel-0|6> received packet: from 81.200.100.241[4500] to 10.67.48.55[4500] (80 bytes)

Thanks for your help!

2

@janiisi
Please check pfs in Phase 2 on cisco and VyOS side.
Cisco uses group 1 by default.
In log we can see that cisco generates the delete message. So if you can, try to debug on cisco side too.

3

I cannot check VPN IPSec on Cisco side (provider end). The provider asked to set dh-group21. We have also set this group on our end.

vpn {
    ipsec {
        esp-group VPN-esp {
            compression disable
            lifetime 28800
            mode tunnel
            pfs dh-group21
            proposal 1 {
                encryption aes256
                hash sha256
            }
        }

Should I ask VPN IPSec provider to check if Phase 2 is set to dh-group21 (pfs dh-group21) on Cisco?

4

VPN IPSec provider points out that they see on their cisco, that we send information from our side “connection timeout: 120 minutes”, which must be true, because tunnel restarts every 2 hours. What params should I check on our vyos-gw?

5

@janiisi
Try to configure DPD.

6

Thanks, we have already configured DPD with action restart and interval 15s. But it does not solve the issue. We will try to investigate further tomorrow.

7

[Solved.] There was a connection timeout limit set to 120 minutes on Cisco device (default setting). Thanks.

8

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.