Interface vti0 deactivated when IKE_SA delete failed


#1

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.


#3

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

Or I’m missing something?


#4

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.


#5

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?


#6

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


#7

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


#8

Can we avoid vti going down ?


#9

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.


#10

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?


#11

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