Cisco IPSec traffic is sent but not received

[arturo-mosegui]

Hello,

I have two ISR1000 routers with the security license activated.

securityk9 (ISR_1100_4P_Security):
  Description: securityk9
  Count: 1
  Version: 1.0
  Status: IN USE
  Export status: NOT RESTRICTED
  Feature Name: securityk9
  Feature Description: securityk9
  Enforcement type: NOT ENFORCED
  License type: Perpetual

I am trying to establish a ikev2 IPSec tunnel between them. The tunnels go up correctly and the traffic is sent, but it is not received on the other side:

local  ident (addr/mask/prot/port): (A/255.255.255.248/0/0)
   remote ident (addr/mask/prot/port): (B/255.255.255.255/0/0)
   current_peer C port 4500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 215, #pkts encrypt: 215, #pkts digest: 215
    #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0

     local crypto endpt.: D, remote crypto endpt.: C
     plaintext mtu 1430, path mtu 1492, ip mtu 1492, ip mtu idb Dialer1

It works a few days and suddenly stopped. What can the problem be?

Thank you,

[paul driver]

Hello
can you confirm your crypto profiles either side of the gre tunnel have parity 
can you ping either side of the tunnel BEFORE you apply ipsec?

[arturo-mosegui]

Hello,

We cannot check the parity because one of the routers is installed in a client. We think that that's not the issue, as the tunnel is UP-ACTIVE.

Yes, we can ping the other side of the tunnel.

Crypto Map IPv4 "SDM_CMAP_1" 80 ipsec-isakmp

         Peer = Z

         Access-List SS dynamic: False

         Extended IP access list consum

         Current peer: Z

         Security association lifetime: 48000 kilobytes/28800 seconds

         Dualstack (Y/N): N

         Responder-Only (Y/N): N

         PFS (Y/N): Y

         DH group:  group2

         Mixed-mode : Disabled

         Transform sets={

                 consum:  { esp-aes esp-sha-hmac  } ,

         }

Interface: Dialer1
Session status: UP-ACTIVE
Peer: X port 4500
  Session ID: 0
  IKEv1 SA: local Y/4500 remote Z/4500 Active
  IPSEC FLOW: permit ip   F/255.255.255.0 E/255.255.255.0
        Active SAs: 2, origin: crypto map
  IPSEC FLOW: permit ip   F/255.255.255.0 G/255.255.255.0
        Active SAs: 2, origin: crypto map

     inbound esp sas:
      spi: 0x9D9549AE(2643806638)
        transform: esp-aes esp-sha-hmac ,
        in use settings ={Tunnel UDP-Encaps, }
        conn id: 2033, flow_id: ESG:33, sibling_flags FFFFFFFF80004048, crypto map: SDM_CMAP_1, initiator : True
         sa timing: remaining key lifetime (k/sec): (48000/27565)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE(ACTIVE)

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0x108C0132(277610802)
        transform: esp-aes esp-sha-hmac ,
        in use settings ={Tunnel UDP-Encaps, }
        conn id: 2034, flow_id: ESG:34, sibling_flags FFFFFFFF80004048, crypto map: SDM_CMAP_1, initiator : True
         sa timing: remaining key lifetime (k/sec): (47982/27565)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE(ACTIVE)

[Elliot Dierksen]

The side that shows "#pkts decaps: 0" is sending and encrypting traffic. I would look at the other side to make sure the routing table is bringing traffic to the correct out interface first. After that, make sure you ACL that defines the tunnel is a reflection of the ACL on the other side and that your traffic isn't being caught by a NAT rule.