Site to site VPN problem

[IT Asitis]

Hi,

Im setting up a site to site VPN between an ASA 5510 and a fortigate firewall.

i have set everything upp and i cant see anything wrong with the setup, however now traffic is flowing. I did a packet trace and it gets droped by an acl in the tunnel if i understand the acl correct. but i cant figure out what rule that is.

any ideas?

/Hilmar

Packet Tracer

Result of the command: "packet-tracer input Inside tcp 10.42.10.70 80 192.168.74.14 80 xml"

<Phase>
<id>1</id>
<type>ACCESS-LIST</type>
<subtype></subtype>
<result>ALLOW</result>
<config>
Implicit Rule
</config>
<extra>
MAC Access list
</extra>
</Phase>

<Phase>
<id>2</id>
<type>ROUTE-LOOKUP</type>
<subtype>input</subtype>
<result>ALLOW</result>
<config>
</config>
<extra>
in   0.0.0.0         0.0.0.0         WAN1
</extra>
</Phase>

<Phase>
<id>3</id>
<type>ACCESS-LIST</type>
<subtype>log</subtype>
<result>ALLOW</result>
<config>
access-group Internt_access_in in interface Inside
access-list Internt_access_in extended permit ip any object site-Asitis
</config>
<extra>
</extra>
</Phase>

<Phase>
<id>4</id>
<type>CONN-SETTINGS</type>
<subtype></subtype>
<result>ALLOW</result>
<config>
</config>
<extra>
</extra>
</Phase>

<Phase>
<id>5</id>
<type>IP-OPTIONS</type>
<subtype></subtype>
<result>ALLOW</result>
<config>
</config>
<extra>
</extra>
</Phase>

<Phase>
<id>6</id>
<type>NAT</type>
<subtype></subtype>
<result>ALLOW</result>
<config>
nat (Inside,WAN1) source static NETWORK_OBJ_10.42.10.0_24 NETWORK_OBJ_10.42.10.0_24 destination static site-Asitis site-Asitis no-proxy-arp route-lookup
</config>
<extra>
Static translate 10.42.10.70/80 to 10.42.10.70/80
</extra>
</Phase>

<Phase>
<id>7</id>
<type>VPN</type>
<subtype>encrypt</subtype>
<result>DROP</result>
<config>
</config>
<extra>
</extra>
</Phase>

<result>
<input-interface>Inside</input-interface>
<input-status>up</input-status>
<input-line-status>up</input-line-status>
<output-interface>WAN1</output-interface>
<output-status>up</output-status>
<output-line-status>up</output-line-status>
<action>drop</action>
<drop-reason>(acl-drop) Flow is denied by configured rule</drop-reason>
</result>

[Jouni Forss · Accepted solution]

Hi,

The Phase 7 DROP can be result of a mismatched parameters in the L2L VPN configuration. So it might not have anything to do with any ACL rules.

So the next step would be to either debug the VPN and/or check logs through ASDM in realtime and see if the logs give a specific reason for this.

What you could also do is

• Give us the L2L VPN peer IP address or atleast the start
• Issue the same "packet-tracer" command above once or twice
• Right after the packet tracer issue the command "show crypto isakmp sa"  
  • Copy the output of the command here
  • Issue the above command several times also and see if theres difference in the output for the VPN state
• If you see "MM_ACTIVE" (or something to that direction) with the above command, it should to my understanding mean that the Phase1 of the L2L VPN is fine.

Most usual errors/missmatches in L2L VPN are the PSK/Pre-Shared-Key and in the ACL that defines the interesting traffic (Encryption Domain)

Also usually the configuration missmatch with Cisco devices is related to the Phase2 parameters as all connections share the Phase1 parameters. Once you have created some very common crypto isakmp policy/crypto ikev1 policy, you wont have configure it for another connection. And usually especially through using ASDM, you already have many predefined Phase1 policys.

Have you asked the remote end to check and send their parameters (other than the PSK) to you so you could confirm they match?

- Jouni

[IT Asitis]

Ok i did the commands and the output of the "show crypto isakmp sa" changes. first i get 3 hits and then i get 4 hits.

this is the one im looking for, however it says MM_wait not Active.

4   IKE Peer: 88.234.33.142

    Type    : user            Role    : initiator

    Rekey   : no              State   : MM_WAIT_MSG2
  

Is it waiting for the other end?

I control both the firewalls so i have done all the settings on both ends.

[IT Asitis]

Ok i have solved the issue.

I have another firewall there that is also an ASA and using it there is no problem. The tunnel goes up in a flash.

Thanks for your time.

/H

[Jouni Forss]

Hi,

MM_WAIT_MSG2 would indicate that the remote end (from the perspective of this host naturally) doesnt respond at all.

There should be MM_WAIT_MSG1 - 6 before MM_ACTIVE

MSG1 is the one that the initiator sends and MSG2 is the one that it is waiting from the remote VPN peer.

Could there be something blocking the connection from the direction of the this VPN peer to the other?

- Jouni