I’ve encountered an issue with a site-to-site IPsec VPN in VyOS. When the Dead Peer Detection (DPD) check fails, the VTI interface bound to the VPN transitions to an admin down state. The interface does not automatically recover and requires manual intervention to restore functionality. The following steps are necessary to bring the interface back up:

Unbinding the VTI interface from the VPN and rebinding it.
Forcing the interface down and then removing it.
Is this the expected behaviour, or is this a potential bug?

Below is what we see in the logs:

bytes)
Jan 13 06:41:32 charon[6155]: 15[ENC] <Phones|43> generating INFORMATIONAL_V1 request 1404289472 [ HASH N(DPD) ]
Jan 13 06:41:32 charon-systemd[6155]: generating INFORMATIONAL_V1 request 1404289472 [ HASH N(DPD) ]
Jan 13 06:41:32 charon[6155]: 15[NET] <Phones|43> sending packet: from 82.219.xxx.xxx[500] to 5.101.xxx.xxx[500] (92 bytes)
Jan 13 06:41:32 charon-systemd[6155]: sending packet: from 82.219.xxxx.xxx[500] to 5.101.xx.xxx[500] (92 bytes)
Jan 13 06:42:02 charon[6155]: 16[IKE] <Phones|43> sending DPD request
Jan 13 06:42:02 charon-systemd[6155]: sending DPD request
Jan 13 06:42:02 charon[6155]: 16[ENC] <Phones|43> generating INFORMATIONAL_V1 request 1505008814 [ HASH N(DPD) ]
Jan 13 06:42:02 charon-systemd[6155]: generating INFORMATIONAL_V1 request 1505008814 [ HASH N(DPD) ]
Jan 13 06:42:02 charon[6155]: 16[NET] <Phones|43> sending packet: from 82.219.xxx.xxx[500] to 5.101.xxx.xxx[500] (92 bytes)
Jan 13 06:42:02 charon-systemd[6155]: sending packet: from 82.219.xxx.xxx[500] to 5.101.xxx.xxx[500] (92 bytes)
Jan 13 06:42:32 charon[6155]: 03[JOB] <Phones|43> DPD check timed out, enforcing DPD action
Jan 13 06:42:32 charon-systemd[6155]: DPD check timed out, enforcing DPD action
Jan 13 06:42:33 vti-up-down[651483]: Interface vti0 down-client Phones-tunnel-2
Jan 13 06:42:33 vti-up-down[651485]: Interface vti0 down-client Phones-tunnel-1
Jan 13 06:42:33 charon[6155]: 12[KNL] interface vti0 deactivated
Jan 13 06:42:33 charon-systemd[6155]: interface vti0 deactivated
Jan 13 06:42:33 charon[6155]: 10[KNL] fe80::fc56:caff:fe7a:a9ac disappeared from vti0
Jan 13 06:42:33 charon-systemd[6155]: fe80::fc56:caff:fe7a:a9ac disappeared from vti0
Jan 13 06:42:33 vti-up-down[651485]: Interface vti0 is admin down ...
Jan 13 06:42:33 charon[6155]: 03[CFG] <Phones|43> updating already routed CHILD_SA 'Phones-tunnel-2'
Jan 13 06:42:33 charon[6155]: 03[CFG] <Phones|43> updating already routed CHILD_SA 'Phones-tunnel-1'
Jan 13 06:42:33 charon-systemd[6155]: updating already routed CHILD_SA 'Phones-tunnel-2'
Jan 13 06:42:33 charon-systemd[6155]: updating already routed CHILD_SA 'Phones-tunnel-1'
Jan 13 06:42:33 charon[6155]: 07[NET] using forecast interface eth0
Jan 13 06:42:33 charon-systemd[6155]: using forecast interface eth0
Jan 13 06:42:33 charon[6155]: 07[CFG] joining forecast multicast groups: 224.0.0.1,224.0.0.22,224.0.0.251,224.0.0.252,239.255.255.250
Jan 13 06:42:33 charon-systemd[6155]: joining forecast multicast groups: 224.0.0.1,224.0.0.22,224.0.0.251,224.0.0.252,239.255.255.250

Further to this we have the below configuration

VPN Config:

vpn {

ipsec {
    authentication {
        psk Phones {
            id 82.219.xx.xxxx
            secret xxxxxxxxxxxxxxxxxx
        }
    }
    esp-group phones {
        lifetime 28800
        pfs disable
        proposal 1 {
            encryption 3des
            hash sha1
        }
    }
    ike-group phones {
        close-action start
        dead-peer-detection {
            action restart
        }
        key-exchange ikev1
        lifetime 86400
        mode main
        proposal phones {
            dh-group 2
            encryption 3des
            hash sha1
        }
    }
    options {
        disable-route-autoinstall
    }
    site-to-site {
        peer Phones {
            authentication {
                mode pre-shared-secret
            }
            connection-type initiate
            ike-group phones
            local-address 82.219.xxx.xxx
            remote-address 5.101.xxx.xxx
            tunnel 1 {
                esp-group phones
                local {
                    prefix 10.128.232.0/22
                }
                remote {
                    prefix 10.0.1.23/32
                }
            }
            tunnel 2 {
                esp-group phones
                local {
                    prefix 172.23.84.0/22
                }
                remote {
                    prefix 10.0.1.12/32
                }
            }
            tunnel 3 {
                esp-group phones
                local {
                    prefix 10.126.40.0/22
                }
                remote {
                    prefix 10.0.1.23/32
                }
            }
            vti {
                bind vti0
            }
        }
    }
}

}