topic VPN tunnel for some subnets doesn't work in Network Security

VPN tunnel for some subnets doesn't work

vishnureddy1979 — Tue, 12 Mar 2019 07:23:32 GMT

I have the 10.64.0.0 subnet and 172.21.0.0 subnet that talk to each other via the tunnel. Everyday in the morning i have to bounce the tunnel to get this working. I have case opened with the TAC engineer but seems like there is no resolution to this.

IMMCUSTFW01# sh asp table classify crypto | be out

out id=0xad1abc10, priority=70, domain=encrypt, deny=false

hits=3270, user_data=0x3b27dc, cs_id=0xacc6dbd8, reverse, flags=0x0, protocol=0

src ip=10.64.0.0, mask=255.255.0.0, port=0

dst ip=172.21.0.0, mask=255.255.0.0, port=0, dscp=0x0

out id=0xacccd398, priority=70, domain=encrypt, deny=false

hits=1676, user_data=0x0, cs_id=0xacc6dbd8, reverse, flags=0x0, protocol=0

src ip=10.64.0.0, mask=255.255.0.0, port=0

dst ip=172.21.0.0, mask=255.255.0.0, port=0, dscp=0x0

Last clearing of hits counters: Never

IMMCUSTFW01# show crypto ipsec sa peer 148.61.xx.xx

Crypto map tag: Outside_map, seq num: 12, local addr: 63.111.xx.xx

access-list outside_14_cryptomap extended permit ip 10.64.0.0 255.255.0.0 172.21.0.0 255.255.0.0
local ident (addr/mask/prot/port): (10.64.0.0/255.255.0.0/0/0)
remote ident (addr/mask/prot/port): (172.21.0.0/255.255.0.0/0/0)
current_peer: 148.61.xx.xx

#pkts encaps: 4784, #pkts encrypt: 4784, #pkts digest: 4784
#pkts decaps: 4782, #pkts decrypt: 4782, #pkts verify: 4782
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 4784, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#send errors: 0, #recv errors: 0

local crypto endpt.: 63.111.xx.xx, remote crypto endpt.: 148.61.xx.xx

path mtu 1500, ipsec overhead 58, media mtu 1500
current outbound spi: 71792FB1
current inbound spi : 42E74BAC

The TAC engineer says that the SPI values are different from the existing once to the once that are found in the output shown above for the SAs(sh asp table classify crypto | be out). I am running the 8.2.5 version of ASA code. There is no way to delete the inactive SPIs in this version of code. Has anyone have encountered such a situation and would like to know how to resolve this issue.

When the traffic is not reachable no SAs are formed between the peer for those subnets but i can see for those subnets in the sh asp table classify crypto | be out. Once i bounce the tunnel, SAs are formed but the SPI values are different when compared to those in the sh asp table classify crypto | be out.

I've been seeing something

James Leinweber — Tue, 23 Feb 2016 23:37:01 GMT

I've been seeing something similar on versions 8.2, 9.2, 9.4 first on 5520's and later on 5525-x. I have a bunch of subnets carried over an IPsec tunnel, and occasionally two of them stop communicating. It's not always the same two. Often this is in conjunction with an IKE phase I error such as %ASA-5-750007 "peer lost", particularly if the WAN link between the firewalls gets lossy for a while.

Scuttlebutt at the University of Wisconsin - Madison is that I'm not the only one suffering from the problem. I had a TAC cases open in 2013 and 2015 about this but didn't get any resolution.

-- Jim Leinweber, WI State Lab of Hygiene

Have you tried disabling the

Marius Gunnerud — Wed, 24 Feb 2016 07:50:01 GMT

Have you tried disabling the keepalives at both ends of the VPN tunnel? That way the tunnel should never be torn down and this issue "should" not be seen. Not a permanent solution but possibly a workaround:

tunnel-group <PEER IP> ipsec-attributes

isakmp keepalive disable

Please remember to select a correct answer and rate helpful posts

Thanks for your reply. I have

vishnureddy1979 — Wed, 24 Feb 2016 14:27:36 GMT

Thanks for your reply. I have disabled keepalives for that particular tunnel and will monitor for some time.

Did you find a fix to this?

cw.ashton — Thu, 15 Sep 2016 07:42:38 GMT

Did you find a fix to this? What was it please?

I believe it was because of a

vishnureddy1979 — Thu, 15 Sep 2016 12:50:19 GMT

I believe it was because of a cisco ASA buggy IOS. I have to upgrade to this 8.4(7)30 version. Its working fine now.

Another possibility is that

James Leinweber — Thu, 15 Sep 2016 16:08:20 GMT

Another possibility is that IKEv2 negotiations are buggier than IKEv1. I'm getting better tunnel stability with the latter, sadly.