ipsec vpn tunnel issue

[Benjamin Saito]

I have a vpn tunnel that has been working but just recently stopped. I haven't made any changes on my end but I am not convinced that they haven't on the remote end. Here is what I get when doing a show crypto isakmp sa detail:

6   IKE Peer: 1.1.1.1
    Type    : user            Role    : initiator
    Rekey   : no              State   : MM_WAIT_MSG2
    Encrypt : aes-256         Hash    : SHA      
    Auth    : preshared       Lifetime: 0

The peer IP has been edited. I know that the MM_WAIT_MSG2 means that I am not receiving a response back, but what I am concerned about it the "Type: user". I am not sure why it is not "L2L" like a normal vpn tunnel. Any information would be much appreciated. This is on a 5510 code version 8.0(4). Remote device is also an ASA but I am not sure what code version or platform.

[Jouni Forss]

Hi,

As I already expected the "Type" field is not documented very well (or at all) in the Command Reference for ASA.

It would seem to (on the basis of testing a dummy L2L VPN connection that can not receive a reply) that while the Phase1 negotiation is incomplete (or atleast waiting for the MSG2) the "Type" is listed as "user". When the connection is negotiated the "Type" field is "L2L".

I don't really have an indepth knowledge of what happens during these negotiations but I would imagine that since the Phase2 has not yet been negotiated the device "does not know" that this connection is going to be a L2L VPN connection and therefore lists it as "user". But this is just pure speculation and guessing on my part.

With regards to the actual problem I guess the only thing you can do is to ask the remote end to double/triple check their configurations and perhaps share them with you. As they are using an ASA they might be able to use a "packet-tracer" command that SHOULD go the L2L VPN connection and then check that it truly does match the L2L VPN configurations.

Though seeing as the remote end ASA does not even reply to the first Phase1 message it would seem like there might even be a problem between the ASAs. Maybe something on the remote end is blocking the UDP/500 traffic?

If possible I guess you could ask them to genetraffic the VPN negotiation from their end and configure a traffic capture on your ASA to capture UDP/500 (perhaps you can just capture "ip") traffic between your ASAs WAN IP and the remote VPN peers IP address and then confirm if anything is even getting to your ASA.

The most typical scenario where I see this problems is usually when configuring a new L2L VPN connection and the remote end has not yet configured their device. Has also happened in some migrations that the remote site routing has been the cause of the problem.

So check configurations, test connections from both ends, capture traffic and so on. Naturally if you have logs going to a Syslog server you could check the logs around the time the connection started having this problem.

- Jouni