Interface vti0 deactivated when IKE_SA delete failed

I have configured a tunnel between vyos and Paloalto and Paloalto is behind NAT. Once tunnel is established I am running command “test vpn ike-sa” on Paloalto. Paloalto start creating new child_sa and does not send delete child_sa request for old child_sa. vyos gets new child_sa request and start deleting old child_sa. vyos send delete child_sa request to Paloalto for old child_sa but since Paloalto has already deleted old sa it does not respond to delete request. vyos sends delete request for 5 tumes and deactivate vti0.

I am getting following logs in charon.log:
Jun 14 06:11:41 14[IKE] <peer-10.15.18.12-tunnel-vti|2> giving up after 5 retransmits
Jun 14 06:11:41 14[IKE] <peer-10.15.18.12-tunnel-vti|2> proper IKE_SA delete failed, peer not responding
Jun 14 06:11:41 13[KNL] interface vti0 deactivated

IPSEC.CONF

generated by /opt/vyatta/sbin/vpn-config.pl

config setup
interfaces="%none"
nat_traversal=yes

conn %default
keyexchange=ikev1

conn peer-10.15.18.12-tunnel-vti
left=10.15.20.119
leftid=“100.64.0.1”
right=10.15.18.12
rightid=“100.64.0.2”
leftsubnet=0.0.0.0/0
rightsubnet=0.0.0.0/0
ike=aes128-sha1-modp2048,aes128-md5-ecp256,aes128-sha256-modp1024,aes128-sha384-modp1024!
keyexchange=ikev2
reauth=no
ikelifetime=86400s
dpddelay=30s
dpdtimeout=120s
closeaction=none
dpdaction=restart
esp=aes128-sha1-modp1024,aes256-md5-modp1024,aes256-sha256-modp1024,aes128-md5-modp1024,aes128-sha256-modp1024!
keylife=43200s
rekeymargin=540s
type=tunnel
compress=no
authby=secret
mark=9437185
leftupdown="/usr/lib/ipsec/vti-up-down vti0"
auto=add
keyingtries=1
#conn peer-10.15.18.12-tunnel-vti

vyos is in responder mode. how can I make sure that when delete request from vyos does not get responded vti0 should not go down.

Maybe check that lifetime and DPD settings match on both sides?

Or I’m missing something?

DPD is matching on both side. The issue is paloalto not replying to delete request and thats why vyos is deactivating vti0. I dont want vyos to deactivate vti0 when paloalto does not reply.

leftsubnet=0.0.0.0/0
rightsubnet=0.0.0.0/0

left and right subnet is any IP address? I’m not 100% sure, but aren’t you ‘disabling’ your default route instantly if the tunnel is established? I still have to test it, but I doubt that such a setup would work in general.
Do you see that /usr/lib/ipsec/vti-up-down vti0 gets triggered in a loop?

default subnet is not getting disabled. Tunnel is working fine and vti-up-down script does not get called in loop.

I tested your scenario, the vyos router assumed that the peer is dead and takes down the vti until the tunnel is reestablished.

Can we avoid vti going down ?

Not as far as i know, it will come up if the tunnel is back online, automatically. I disconnected also the interface physically to see the vti behavior, DPD detects the not responding tunnel, takes everything down and tries to reinit. After the SA is re-established, vti is back online.

Has there been a solution to this problem?

I am facing the exact same behaviour. It configured dead peer detection to prevent the tunnel from going down:

  • set security vpn ipsec ike-group IKE-XY dead-peer-detection action ‘restart’
    
  • set security vpn ipsec ike-group IKE-XY dead-peer-detection interval ‘30’
    
  • set security vpn ipsec ike-group IKE-XY dead-peer-detection timeout ‘120’
    

But still the vtis are deactivated after IKE lifetime expires.
Any more hints?

In my case vti is not comming UP even after rekeying.