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