version - 1.3
I have configured ipsec vpn from DC to oracle cloud.
Problem noticed :VTI interface going to admin down and once i reboot the router connection is stable for some time and again VTI is going down.
show vpn ispec status - 2 tunnel is showing up
I am establishing BGP over VTI interface.
Hi @Jayas , any corresponding logs that can help to identify the issue? What is the exact version and environment of your setup? Your current configuration also may help to check what can be wrong there.
I’m also getting the same issue. I let IPSec tunnel run for a week without touching it, after 3 days it was still up, but now I just came back to vti interface being down.
vyos@cxr# run show interfaces
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface IP Address S/L Description
--------- ---------- --- -----------
br0 - u/D bridge itf
br3 10.110.10.38/29 u/u bridge itf
br6 10.152.10.1/24 u/u bridge itf
10.172.172.1/24
br7 10.151.10.1/24 u/u bridge itf
eth0 192.168.0.56/16 u/u Ethernet Interface eth0
eth1 203.127.99.235/27 u/u Ethernet Interface eth1
eth2 - u/u
eth3 - A/D
eth4 - A/D peer0
eth5 - u/u
eth6 - A/D
lo 127.0.0.1/8 u/u
::1/128
peth50 172.21.1.23/24 u/u svc1
vti1 169.254.231.46/30 A/D VTI vti1
IPSec configurations:
vyos@cxr# show vpn ipsec
esp-group esp-vti1 {
proposal 1 {
encryption aes128
hash sha1
}
}
ike-group ike-vti1 {
dead-peer-detection {
action restart
interval 30
timeout 120
}
key-exchange ikev1
proposal 1 {
dh-group 2
encryption aes128
hash sha1
}
}
site-to-site {
peer 3.106.68.200 {
authentication {
mode pre-shared-secret
pre-shared-secret *********
}
connection-type initiate
default-esp-group esp-vti1
ike-group ike-vti1
local-address 203.127.99.235
vti {
bind vti1
}
}
}
vyos@cxr# show interfaces vti
vti vti1 {
address 169.254.231.46/30
description "VTI vti1"
firewall {
in {
}
out {
}
}
mtu 1419
vrf vrf-vti1
}
IPSec status get:
vyos@cxr# run show vpn ipsec sa
IPSec process not running
vyos@cxr# run show vpn ipsec status
IPSec process not running
Charon log (last non-repetitive lines of the log for this relevant peer, charon stopped printing log for this peer after this):
Jul 6 03:43:56 cxr charon: 15[ENC] <peer_3-106-68-200|472> generating INFORMATIONAL_V1 request 601002276 [ HASH N(DPD_ACK) ]
Jul 6 03:43:56 cxr charon: 15[NET] <peer_3-106-68-200|472> sending packet: from 203.127.99.235[4500] to 3.106.68.200[4500] (92 bytes)
Jul 6 03:44:06 cxr charon: 06[NET] <peer_3-106-68-200|472> received packet: from 3.106.68.200[4500] to 203.127.99.235[4500] (92 bytes)
Jul 6 03:44:06 cxr charon: 06[ENC] <peer_3-106-68-200|472> parsed INFORMATIONAL_V1 request 1437337983 [ HASH N(DPD) ]
Jul 6 03:44:06 cxr charon: 06[ENC] <peer_3-106-68-200|472> generating INFORMATIONAL_V1 request 3525446735 [ HASH N(DPD_ACK) ]
Jul 6 03:44:06 cxr charon: 06[NET] <peer_3-106-68-200|472> sending packet: from 203.127.99.235[4500] to 3.106.68.200[4500] (92 bytes)
Jul 6 03:44:16 cxr charon: 12[NET] <peer_3-106-68-200|472> received packet: from 3.106.68.200[4500] to 203.127.99.235[4500] (92 bytes)
Jul 6 03:44:16 cxr charon: 12[ENC] <peer_3-106-68-200|472> parsed INFORMATIONAL_V1 request 4285826335 [ HASH N(DPD) ]
Jul 6 03:44:16 cxr charon: 12[ENC] <peer_3-106-68-200|472> generating INFORMATIONAL_V1 request 1030086262 [ HASH N(DPD_ACK) ]
Jul 6 03:44:16 cxr charon: 12[NET] <peer_3-106-68-200|472> sending packet: from 203.127.99.235[4500] to 3.106.68.200[4500] (92 bytes)
Jul 6 03:44:26 cxr charon: 15[NET] <peer_3-106-68-200|472> received packet: from 3.106.68.200[4500] to 203.127.99.235[4500] (92 bytes)
Jul 6 03:44:26 cxr charon: 15[ENC] <peer_3-106-68-200|472> parsed INFORMATIONAL_V1 request 103827567 [ HASH N(DPD) ]
Jul 6 03:44:26 cxr charon: 15[ENC] <peer_3-106-68-200|472> generating INFORMATIONAL_V1 request 2667113644 [ HASH N(DPD_ACK) ]
Jul 6 03:44:26 cxr charon: 15[NET] <peer_3-106-68-200|472> sending packet: from 203.127.99.235[4500] to 3.106.68.200[4500] (92 bytes)
Jul 6 03:44:27 cxr charon: 14[KNL] fe80::347d:33ff:feba:2be7 appeared on br1
Jul 6 03:44:27 cxr charon: 09[KNL] interface br1 activated
Jul 6 03:44:35 cxr charon: 05[KNL] fe80::347d:33ff:feba:2be7 disappeared from br1
Jul 6 03:44:35 cxr charon: 13[KNL] interface br1 deactivated
Jul 6 03:44:35 cxr charon: 07[KNL] interface br1 deleted
Jul 6 03:44:36 cxr charon: 06[NET] <peer_3-106-68-200|472> received packet: from 3.106.68.200[4500] to 203.127.99.235[4500] (92 bytes)
Jul 6 03:44:36 cxr charon: 06[ENC] <peer_3-106-68-200|472> parsed INFORMATIONAL_V1 request 1860480628 [ HASH N(DPD) ]
Jul 6 03:44:36 cxr charon: 06[ENC] <peer_3-106-68-200|472> generating INFORMATIONAL_V1 request 205969854 [ HASH N(DPD_ACK) ]
Jul 6 03:44:36 cxr charon: 06[NET] <peer_3-106-68-200|472> sending packet: from 203.127.99.235[4500] to 3.106.68.200[4500] (92 bytes)
Jul 6 03:44:36 cxr charon: 08[KNL] fe80::605a:e0ff:feb1:c496 appeared on br2
Jul 6 03:44:36 cxr charon: 12[KNL] interface br2 activated
Jul 6 03:44:42 cxr charon: 11[KNL] fe80::605a:e0ff:feb1:c496 disappeared from br2
Jul 6 03:44:42 cxr charon: 16[KNL] interface br2 deactivated
Jul 6 03:44:42 cxr charon: 08[KNL] interface br2 deleted
Jul 6 03:44:46 cxr charon: 13[KNL] fe80::ac75:8bff:fe4f:5ae8 appeared on br1
Jul 6 03:44:46 cxr charon: 07[KNL] interface br1 activated
Jul 6 03:44:46 cxr charon: 16[NET] <peer_3-106-68-200|472> received packet: from 3.106.68.200[4500] to 203.127.99.235[4500] (92 bytes)
Jul 6 03:44:46 cxr charon: 16[ENC] <peer_3-106-68-200|472> parsed INFORMATIONAL_V1 request 2540737580 [ HASH N(DPD) ]
Jul 6 03:44:46 cxr charon: 16[ENC] <peer_3-106-68-200|472> generating INFORMATIONAL_V1 request 792697772 [ HASH N(DPD_ACK) ]
Jul 6 03:44:46 cxr charon: 16[NET] <peer_3-106-68-200|472> sending packet: from 203.127.99.235[4500] to 3.106.68.200[4500] (92 bytes)
Jul 6 03:44:52 cxr charon: 00[DMN] SIGINT received, shutting down
Jul 6 03:44:52 cxr charon: 00[IKE] <peer_3-106-68-200|472> closing CHILD_SA peer_3-106-68-200_vti{21} with SPIs c225f5c9_i (0 bytes) c48f9426_o (0 bytes) and TS 0.0.0.0/0 === 0.0.0.0/0
Jul 6 03:44:52 cxr vti-up-down[188026]: Interface vti1 down-client peer_3-106-68-200_vti
Jul 6 03:44:52 cxr charon: 02[KNL] interface vti1 deactivated
Jul 6 03:44:52 cxr charon: 00[IKE] <peer_3-106-68-200|472> sending DELETE for ESP CHILD_SA with SPI c225f5c9
Jul 6 03:44:52 cxr charon: 00[ENC] <peer_3-106-68-200|472> generating INFORMATIONAL_V1 request 4005955240 [ HASH D ]
Jul 6 03:44:52 cxr charon: 00[NET] <peer_3-106-68-200|472> sending packet: from 203.127.99.235[4500] to 3.106.68.200[4500] (76 bytes)
Jul 6 03:44:52 cxr charon: 00[IKE] <peer_3-106-68-200|472> deleting IKE_SA peer_3-106-68-200[472] between 203.127.99.235[203.127.99.235]...3.106.68.200[3.106.68.200]
Jul 6 03:44:52 cxr charon: 00[IKE] <peer_3-106-68-200|472> sending DELETE for IKE_SA peer_3-106-68-200[472]
Jul 6 03:44:52 cxr charon: 00[ENC] <peer_3-106-68-200|472> generating INFORMATIONAL_V1 request 495199667 [ HASH D ]
Jul 6 03:44:52 cxr charon: 00[NET] <peer_3-106-68-200|472> sending packet: from 203.127.99.235[4500] to 3.106.68.200[4500] (92 bytes)
LMK if you need more info to debug this issue.
Hi @sandwichdoge ,
The vti interface’s status is down as the ipsec service was not running and below log shows that charon has crashed.
Jul 6 03:44:52 cxr charon: 00[DMN] SIGINT received, shutting down
May I know the VyOS version ?
To restore the service, try to restart the vpn service.
$ restart vpn
And can you try ikev2 instead of ikev1.
vyos@cxr:~$ show version
Version: VyOS 1.4-rolling-202202230317
Release train: sagitta
Built by: autobuild@vyos.net
Built on: Wed 23 Feb 2022 03:17 UTC
Build UUID: 008815ba-b343-4d5b-a86d-950ef7a843c2
Build commit ID: 7c82c5c7104675
Architecture: x86_64
Boot via: installed image
System type: KVM guest
Hardware vendor: QEMU
Hardware model: Standard PC (i440FX + PIIX, 1996)
Hardware S/N:
Hardware UUID: 75151ed2-890b-4a78-b485-a9b57477caf7
Copyright: VyOS maintainers and contributors
I created another tunnel connects to Azure Cloud VPN (same as last time), it’s been running for a week now since my previous post. I’m still using ikev1 but I’ll keep an eye out in case it crashes again. And yes, I checked pstree and the ipsec starter daemon was no longer running by the time it crashed.
Try to upgrade to the latest release
There have been many fixes in five months
And as said @a.srividya IKEv2 highly recommended
@sandwichdoge
Apart from what was already recommended by others, if the update will not fix the problem, please get the full log (show log, for example). We should see what is going on in the router before charon is stopped. It just cannot do this by itself, something sends the signal to the daemon and we need to know what and why.
It seems that updating to VyOS 1.4-rolling-202207170217 fixed the problem.
I have 2 tunnels, both are up for almost a month now.