Cisco ASA – Packet Tracer Fails VPN:Encrypt:Drop

KB ID 0001198

Problem

Sometimes when troubleshooting VPN traffic, you may choose to use the ‘packet-tracer’ command to simulate interesting traffic. I did this today and got;

Phase: {number}
Type: VPN
Subtype: encrypt
Result: DROP
Config:
Additional Information:

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

I replicated the error on the test bench.

Solution

Below is the full packet trace;

Petes-ASA(config)# packet-tracer input inside tcp 192.168.254.1 www 10.254.254.10 www

Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   0.0.0.0         0.0.0.0         outside

Phase: 2
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (inside,outside) source static Obj-SiteA Obj-SiteA destination static Obj-SiteB Obj-SiteB no-proxy-arp route-lookup
Additional Information:
NAT divert to egress interface outside
Untranslate 10.254.254.10/80 to 10.254.254.10/80

Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group outbound in interface inside
access-list outbound extended permit ip any any
Additional Information:

Phase: 4
Type: CONN-SETTINGS
Subtype:
Result: ALLOW
Config:
class-map class-default
 match any
policy-map global_policy
 class class-default
  set connection decrement-ttl
service-policy global_policy global
Additional Information:

Phase: 5
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (inside,outside) source static Obj-SiteA Obj-SiteA destination static Obj-SiteB Obj-SiteB no-proxy-arp route-lookup
Additional Information:
Static translate 192.168.254.1/80 to 192.168.254.1/80

Phase: 6
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 7
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 8
Type: VPN
Subtype: encrypt
Result: DROP
Config:
Additional Information:

Result:
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

This is an annoying error, that is difficult to solve. The reason you are seeing this error is because the ACL that defines the ‘interesting traffic’ for the VPN, does not a MIRROR IMAGE ACL on the OTHER VPN endpoint. As soon as this was rectified the packet-trace ran successfully.

Petes-ASA(config)# packet-tracer input inside tcp 192.168.254.1 www 10.254.254.10 www

Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   0.0.0.0         0.0.0.0         outside

Phase: 2
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (inside,outside) source static Obj-SiteA Obj-SiteA destination static Obj-SiteB Obj-SiteB no-proxy-arp route-lookup
Additional Information:
NAT divert to egress interface outside
Untranslate 10.254.254.10/80 to 10.254.254.10/80

Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group outbound in interface inside
access-list outbound extended permit ip any any
Additional Information:

Phase: 4
Type: CONN-SETTINGS
Subtype:
Result: ALLOW
Config:
class-map class-default
 match any
policy-map global_policy
 class class-default
  set connection decrement-ttl
service-policy global_policy global
Additional Information:

Phase: 5
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (inside,outside) source static Obj-SiteA Obj-SiteA destination static Obj-SiteB Obj-SiteB no-proxy-arp route-lookup
Additional Information:
Static translate 192.168.254.1/80 to 192.168.254.1/80

Phase: 6
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 7
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 8
Type: VPN
Subtype: encrypt
Result: ALLOW
Config:
Additional Information:

Phase: 9
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (inside,outside) source static Obj-SiteA Obj-SiteA destination static Obj-SiteB Obj-SiteB no-proxy-arp route-lookup
Additional Information:

Phase: 10
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:

Phase: 11
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 12
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 13
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 359, packet dispatched to next module

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow

Related Articles, References, Credits, or External Links

Troubleshooting Phase 1 Cisco Site to Site (L2L) VPN Tunnels

Troubleshooting Phase 2 Cisco Site to Site (L2L) VPN Tunnels

Author: PeteLong

Share This Post On

12 Comments

  2. Alex

    22/03/2019

    This post saved my day… Thanks a lot!..

    Post a Reply
  3. Maciej Stolarczyk

    11/12/2019

    Yeah came across this today as well, I ended up creating a nat rule for my remote subnets to present source as one of the ip’s on the local subnet. Might not be applicable in all cases but for me it’s just a single service so it’s whatever.

    Post a Reply
  4. John

    13/05/2020

    Thank you! The post helped a lot!

    Post a Reply
  5. C.Paquet

    14/08/2020

    Maybe it’s a stupid question but here it is: you wrote about the packet-tracer vpn drop “The reason you are seeing this error is because the ACL that defines the ‘interesting traffic’ for the VPN, does not a MIRROR IMAGE ACL on the OTHER VPN endpoint.”

    But how would ASA-A know what is the crypto-acl on ASA-B? ASAs don’t exchange that type of info.

    Post a Reply
    • PeteLong

      14/08/2020

      Hi, Maybe my wording is causing the confusion (sorry) The ACLs don’t get exchanged you are correct! but the A allowed to B at Site A must be INCLUDED in the B to A at Site B (it might be a different A at both sites and a different B at both sites (because subnets are variable and can overlap). BUT the interesting traffic itself needs to be allowed and be mirrored at the other site.

      Perhaps a better wording would have been the ‘interesting traffic’ that matches your ACL needs to be allowed on the other VPN endpoint as a MIRROR IMAGE?

      Does that make more sense?

      Post a Reply
      • Ali

        05/09/2020

        Hi Petelong,

        I think you mean Interesting traffic must be allowed on both endpoints. For example, if site A ACL is permit source 1.1.1.1 to 2.2.2.2, then Site B will need to have to do the same but in reverse so that it will be to permit source 2.2.2.2 to 1.1.1.1. I guess this is what you meant.

        Post a Reply
  7. Rafeeq

    16/10/2020

    Thanks Pete.

    Was haunted by this issue on a on-prem(ASA) to Azure VPN, with same output as you have on the packet tracer. The tunnel was up and all the remote(Azure) subnets was communicating with local(on-prem) subnets, except one local(site-D) subnet. Our setup is like Site-A(azure) >>VPN>> Site-B(on-prem) >>MPLS>> Site-C(on-prem) >>VPN>> Site-D(remote vendor). The issue was like Site-A cannot reach Site-D with all the ACL’s and other VPN requirements in place. There was a outbound Allow rule on our MPLS interface on Site-B ASA (Site-D subnet to Site-A subnet) and Outbound rule on the Site-A (Site-A subnet to Site-D subnet).

    What resolved the issue is to add below rule (although, I can’t still find the logical reasoning for that) on Site-B(on-prem) MPLS interface:
    Source: Site-A subnet , Destination: Site-D subnet, Action: Allow

    Post a Reply
  8. Subrun

    15/01/2021

    I have seen similar message for wrong password

    Post a Reply
  9. Reynaldo Churata

    28/10/2022

    Excelente Respuesta. Fue de mucha ayuda.

    Post a Reply

Submit a Comment

Your email address will not be published. Required fields are marked *