Site-to-site VPN initiates in one direction only

[sasha]

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.

[Boris Uskov]

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.

[Boris Uskov]

Also, try to use on ASA2

debug crypto ikev1 127

debug crypto ipsec 127

terminal monitor

[Boris Uskov · Accepted solution]

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

[sasha]

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

[Boris Uskov]

Could you, please, post the whole config from both ASAs?

Could you, please, post the output of show ver from both ASAs?

[sasha · Accepted solution]

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.

[Boris Uskov]

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.