I came across an interesting issue today where traffic wasn’t passing across a new IPSec Lan-to-Lan VPN correctly.  On both sides were Cisco ASA firewalls 8.0(2), with the local one managed by me and the remote by a 3rd party. 
Some traffic was flowing correctly and some wasn’t. A packet trace of a failing stream showed the following: 
ASA#packet-tracer input inside tcp 10.1.1.65 16664 20.1.1.1 http 
  Phase: 1
  Type: FLOW-LOOKUP
  Subtype: 
  Result: ALLOW
  Additional Information:
  Found no matching flow, creating a new flow
  Phase: 2
  Type: ROUTE-LOOKUP
  Subtype: input
  Result: ALLOW
  Additional Information:
  in   0.0.0.0         0.0.0.0         outside
  Phase: 5
  Type: NAT-EXEMPT
  Subtype: 
  Result: ALLOW
  Config:
    nat (inside) 0 access-list inside_nat0_outbound
    match ip inside 10.1.1.64 255.255.255.192 outside 20.1.1.0 255.255.255.0
      NAT exempt
      translate_hits = 3, untranslate_hits = 0
  Phase: 6
  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
Clearly the VPN phase shouldn’t have been dropping the traffic.
This was confusing there were no ACLs blocking traffic, the route, nat and crypto acl were all ok. However upon investigation the remote crypto ACL didn’t have an entry for this stream. 
Upon modifying them so they were symmetrical the issue was resolved.
Wednesday, 5 March 2008
[Technical] - “Flow is denied by configured rule” message with ASA packet-tracer and traffic being dropped at the VPN phase.
Labels:
CCIE Security,
Cisco ASA,
Cisco PIX,
IPSec VPN,
Packet-Tracer,
SSL VPN
Subscribe to:
Post Comments (Atom)
 



2 comments:
I had the same problem. Thanks for the tip.
That was the problem for me, as well. Thank you!
Post a Comment