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;
[box]
Phase: {number} Type: VPN Subtype: encrypt Result: DROP Config: Additional Information: Result: Drop-reason: (acl-drop) Flow is denied by configured rule
[/box]
I replicated the error on the test bench.
Solution
Below is the full packet trace;
[box]
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
[/box]
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.
[box]
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
[/box]
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
Great solution! thank
This post saved my day… Thanks a lot!..
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.
Thank you! The post helped a lot!
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.
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?
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.
Great article Pete
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
Thanks for the feedback.
I have seen similar message for wrong password
Excelente Respuesta. Fue de mucha ayuda.