Cisco Support Community
Community Member

IPSec VPN encryption drop


I have an issue establishing or connectivity between to Sites configured through a IPsec vpn tunnel.


all ACL rules are in place and the tunnel is up but the device on B side cannot establish connection via the tunnel to destination device located on Aside.


I run a packet-tracer and the output displays the following:

interface: outside

    Crypto map tag: dynmap, seq num: 10, local addr:


      local ident (addr/mask/prot/port): (

      remote ident (addr/mask/prot/port): (



      #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0    à this is my concern

      #pkts decaps: 17, #pkts decrypt: 17, #pkts verify: 17


Phase: 7

Type: VPN

Subtype: encrypt  à 2nd concern

Result: DROP


Additional Information:

Forward Flow based lookup yields rule:

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

        hits=133, user_data=0x0, cs_id=0x7686cf98, reverse, flags=0x0, protocol=0

        src ip=, mask=, port=0

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



input-interface: inside

input-status: up

input-line-status: up

output-interface: outside

output-status: up

output-line-status: up

Action: drop

Drop-reason: (acl-drop) Flow is denied by configured rule


Anyone who has come across this issue please share any ideas of where I can start troubleshooting



Super Bronze

Hi, So your above output



So your above output shows both that the actual VPN connections is up and also the output of some "packet-tracer" command that suggests that what you have tested matches some VPN configuration BUT does not go through completely. Did you issue the "packet-tracer" command twice as if the VPN connection is down while doing this the first time issuing the command will only initiate the VPN negotiation while the second one would go through in a normal situation as the VPN connection would then already be negotiatiated.


What catches my eye first in the outputs is that the "show crypto ipsec sa"  command shows that its somehow related to Dynamic Map or a map named that way. It also shows only traffic incoming from the remote end. Also when we consider that your "packet-tracer" fails (which I assume is aimed from your LAN to the remote LAN?) it leads me to belive that you have somehow missconfigured your "crypto map" configurations which in turn enabled the remote end to negotiate the VPN up but not letting you negotiate the VPN up.


Personally I would be interested in looking at the output of


show run crypto map


This would tell me how this L2L VPN connections configurations are done and if there is perhaps some configuration there that is preventing the connection working from your side.


Naturally we would need the output of the


show run access-list <acl name of acl used in crypto map>


show run tunnel-group <remote peer ip>


We would also need the NAT configurations related to this L2L VPN connection and the full output of the "packet-tracer" command used.


- Jouni


CreatePlease to create content