Based on the explanation that on one side you see decaps but not encaps and the other just encaps looks like a duplicate SPI the ASA might be using the wrong SPI to encrypt the traffic. I will agree that this might not be a configuration issue because the ASA is just randomly just not encrypting traffic and after a reload it works. The workaround for this kind of issues based on this bug is a reload:
https://tools.cisco.com/bugsearch/bug/CSCsu50237
You can check what SPI is in use on the ASA that is showing 0 encaps when this issue is occurring. First run a packet tracer for the traffic that stop working something like this:
packet-tracer input inside icmp 192.168.50.5 8 0 192.168.61.5 de
look for the VPN phase
Phase: 10
Type: VPN
Subtype: encrypt
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
out id=0x3c01878, priority=70, domain=encrypt, deny=false
hits=374, user_data=0x02d5re0e5, cs_id=0x0, flags=0x4000, protocol=0
src ip=192.168.50.0, mask=255.255.255.0, port=0
dst ip=192.168.61.0, mask=255.255.255.0, port=0, dscp=0x0
This is the current SPI 0x02d5re0e5 that is used to encrypt the traffic based on the packet tracer.
Now need to look for the outbound SPI that is in use in the IPsec SA for that particular traffic
"sh crypto ipsec sa peer aa.xx.yy.zz"
peer address: aa.xx.yy.zz
Crypto map tag: xxxx, seq num: 1, local addr:
access-list cryptomap extended permit ip 192.168.50.0 255.255.255.0 192.168.61.0 255.255.255.0
local ident (addr/mask/prot/port): (192.168.50.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (192.168.61.0/255.255.255.0/0/0)
current_peer: aa.xx.yy.zz
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 480, #pkts decrypt: 480, #pkts verify:480 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #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.: , remote crypto endpt.:
path mtu 1500, ipsec overhead 58, media mtu 1500
inbound esp sas:
spi: 0xB2E9E500 (3001672960)
transform: esp-3des esp-sha-hmac no compression
in use settings ={L2L, Tunnel, }
slot: 0, conn_id: 100327424, crypto-map: xxxxx
sa timing: remaining key lifetime (kB/sec): (4374000/1598)
IV size: 8 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
outbound esp sas:
spi: 2a13e894 (957567060)
transform: esp-3des esp-sha-hmac no compression
in use settings ={L2L, Tunnel, PFS Group 2, }
slot: 0, conn_id: 100327424, crypto-map: xxxxx
sa timing: remaining key lifetime (kB/sec): (4373976/1598)
IV size: 8 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
with this we can see that SPI 02d5re0e5 is the current SPI but the SA is doing the encryption with 2a13e894
A command "clear crypto ipsec sa inactive" was introduced starting 9.1 you can try it, this should delete the duplicate SPI entry from the asp table, but some times it doesn't work!
if this doesn't help then need to reload the device every time this happens. No other solution available at the moment.
