08-31-2015 06:54 AM
Hello. We're trying to establish site-to-site VPN between two ASA firewalls, let's call them ASA1 and ASA2. Problem is that ASA1 can't initiate connection. ISAKMP packets from ASA1 reach ASA2, but get dropped by some implicit rule.
When ASA2 initiates, everything's OK. And while the flow exists on ASA2, ASA1 uses that flow so it can initiate VPN also.
Here's output from packet-tracer on ASA2:
ASA2# packet-tracer input outside udp ASA1_IP isakmp ASA2_IP isakmp detailed
Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xaffd1bc8, priority=13, domain=capture, deny=false
hits=14830976, user_data=0xaee75a18, cs_id=0x0, l3_type=0x0
src mac=0000.0000.0000, mask=0000.0000.0000
dst mac=0000.0000.0000, mask=0000.0000.0000
input_ifc=outside, output_ifc=any
Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
in id=0xae06b0c0, priority=1, domain=permit, deny=false
hits=16921285389, user_data=0x0, cs_id=0x0, l3_type=0x8
src mac=0000.0000.0000, mask=0000.0000.0000
dst mac=0000.0000.0000, mask=0100.0000.0000
input_ifc=outside, output_ifc=any
Phase: 3
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in ASA2_IP 255.255.255.255 identity
Phase: 4
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
in id=0xad731f30, priority=0, domain=permit, deny=true
hits=60834932, user_data=0x9, cs_id=0x0, use_real_addr, flags=0x1000, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
input_ifc=outside, output_ifc=any
Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: NP Identity Ifc
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule
Adding ASA1 to inbound ACL on ASA2's outside interface didn't help. Using packet tracer in ASDM didn't point to any specific rule, it just displayed entire list of ACL rules. Using capture type asp-drop displayed the same drop reason as packet-tracer without any further details. Setting ASA2 to answer-only didn't help.
How to interpret values from phase 4, i.e. to find the rule which causes the drops, based on id and other data? There's no such id in sh access-lists.
Any other ideas? Thank you very much.
Solved! Go to Solution.
08-31-2015 07:51 AM
And one more idea :)
May be you have something like this on ASA2:
access-group outside_access_in in interface outside control-plane
?
By control-plane keyword in access-group sentence, the traffic, which is destinated to ASA's interface, can be dropped. Please, see the following discussion:
https://supportforums.cisco.com/discussion/11130691/access-group-control-plane-cisco-pixasa
09-01-2015 05:34 AM
Problem solved when I created new ACL and new incoming access group on outside interface with control-plane option. Looks like packets destined for ASA must have that option to be processed!?!
Boris, thanks a lot, you gave me inspiration for this! Best regards.
08-31-2015 07:43 AM
Hello, Sasha.
Very strange situation. Try to use:
show asp drops
on ASA2, while ASA1 is initiating the tunnel. Issue this command several times and try to find out, what counters are increasing.
08-31-2015 07:46 AM
Also, try to use on ASA2
debug crypto ikev1 127
debug crypto ipsec 127
terminal monitor
08-31-2015 07:51 AM
And one more idea :)
May be you have something like this on ASA2:
access-group outside_access_in in interface outside control-plane
?
By control-plane keyword in access-group sentence, the traffic, which is destinated to ASA's interface, can be dropped. Please, see the following discussion:
https://supportforums.cisco.com/discussion/11130691/access-group-control-plane-cisco-pixasa
09-01-2015 02:43 AM
Thanks for your ideas, but:
- We've already tried asp drops (I mentioned it in my first post)
- We use debug crypto etc., but the traffic gets dropped before it is passed to IKE process - nothing is displayed by that debugs except when the flow already exists
- We don't have control-plane option in the access-group command
Thanks anyway :-)
09-01-2015 02:57 AM
Could you, please, post the whole config from both ASAs?
Could you, please, post the output of show ver from both ASAs?
09-01-2015 05:34 AM
Problem solved when I created new ACL and new incoming access group on outside interface with control-plane option. Looks like packets destined for ASA must have that option to be processed!?!
Boris, thanks a lot, you gave me inspiration for this! Best regards.
09-01-2015 05:45 AM
Great news!
But the solution is still not clear for me too :)
Usually, you don't have to use control-plane option. The ISAKMP Packets, which are destinated to ASA's interface, are usually permitted.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide