cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2662
Views
0
Helpful
1
Replies

Receive errors incrementing in IPSEC connection for a specific subnet

In my Cisco ASA IPSEC VPN, observing Recv errors incrementing in a particular IPSEC tunnel connection. Found configuration at both ends are correct. Tunnel is working fine but intermittently some times not working. My side Cisco ASA and Peer end Fortigate firewall. Find logs below.

#pkts encaps: 3747, #pkts encrypt: 3747, #pkts digest: 3747
#pkts decaps: 4080, #pkts decrypt: 4080, #pkts verify: 4080
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 3748, #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
#TFC rcvd: 0, #TFC sent: 0
#Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0
#send errors: 0, #recv errors: 1927

local crypto endpt.: , remote crypto endpt.
path mtu 1500, ipsec overhead 58(36), media mtu 1500
PMTU time remaining (sec): 0, DF policy: copy-df
ICMP error validation: disabled, TFC packets: disabled
current outbound spi: 37D1EC34
current inbound spi : D17F4C4F

inbound esp sas:
spi: 0xD17F4C4F (3514780751)
transform: esp-3des esp-md5-hmac no compression
in use settings ={L2L, Tunnel, IKEv1, }
slot: 0, conn_id: 14467072, crypto-map: VPN1
sa timing: remaining key lifetime (kB/sec): (3914832/2258)
IV size: 8 bytes
replay detection support: Y
Anti replay bitmap:
0xFFFFFFFF 0xFFFFFFFF
outbound esp sas:
spi: 0x37D1EC34 (936504372)
transform: esp-3des esp-md5-hmac no compression
in use settings ={L2L, Tunnel, IKEv1, }
slot: 0, conn_id: 14467072, crypto-map: VPN1
sa timing: remaining key lifetime (kB/sec): (3914742/2243)
IV size: 8 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001


#pkts encaps: 1315, #pkts encrypt: 1315, #pkts digest: 1315
#pkts decaps: 1234, #pkts decrypt: 1234, #pkts verify: 1234
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 1315, #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
#TFC rcvd: 0, #TFC sent: 0
#Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0
#send errors: 0, #recv errors: 600

local crypto endpt.: , remote crypto endpt.: 
path mtu 1500, ipsec overhead 58(36), media mtu 1500
PMTU time remaining (sec): 0, DF policy: copy-df
ICMP error validation: disabled, TFC packets: disabled
current outbound spi: 37D1EC36
current inbound spi : B9976E05

inbound esp sas:
spi: 0xB9976E05 (3113709061)
transform: esp-3des esp-md5-hmac no compression
in use settings ={L2L, Tunnel, IKEv1, }
slot: 0, conn_id: 14467072, crypto-map: VPN1
sa timing: remaining key lifetime (kB/sec): (3914968/2220)
IV size: 8 bytes
replay detection support: Y
Anti replay bitmap:
0xFFFFFFFF 0xFFFFFFFF
outbound esp sas:
spi: 0x37D1EC36 (936504374)
transform: esp-3des esp-md5-hmac no compression
in use settings ={L2L, Tunnel, IKEv1, }
slot: 0, conn_id: 14467072, crypto-map: VPN1
sa timing: remaining key lifetime (kB/sec): (3914953/2218)
IV size: 8 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001

1 Reply 1

Philip D'Ath
VIP Alumni
VIP Alumni

I'll bet it is happening around the tunnel re-negotiation time.  I bet the SPI's are not matching up, preventing the traffic from being decrypted.

See if the remote end supports DPD (dead peer detection) and try enabled it on both ends.

Alternatively, you could change over to use IKEv2 which has this sorted out much better.