4

I am setting up Cisco 5585 ASA for IPsec tunnel with one of cloud company.

we already have lots of tunnel for various cloud provider and life if good but recently this tunnel giving me hard time to setup and here is the debug and config

access-list ACL-VPN-CLOUD extended permit ip any4 object-group obj-NET-CLOUD

tunnel-group 193.164.94.47 type ipsec-l2l
tunnel-group 193.164.94.47 ipsec-attributes
 ikev1 pre-shared-key *****
 isakmp keepalive threshold 10 retry 10

crypto map CRYPTO-MAP 4202 match address ACL-VPN-CLOUD
crypto map CRYPTO-MAP 4202 set pfs group1
crypto map CRYPTO-MAP 4202 set peer 193.164.94.47
crypto map CRYPTO-MAP 4202 set ikev1 transform-set CLOUD-ESP-AES-MD5
crypto map CRYPTO-MAP 4202 set security-association lifetime seconds 86400

nat (any,outside) source static obj-NET-PRIVATE obj-NET-PRIVATE destination static obj-NET-CLOUD obj-NET-CLOUD

I can see Phase-1 is completed in show crypto isakmp sa

16  IKE Peer: 193.164.94.47
    Type    : L2L             Role    : initiator
    Rekey   : no              State   : MM_ACTIVE

But Phase-2 having issue to bring tunnel up, you can see full debug here https://pastebin.com/fX2tz29G

In debug i have noticed following errors, I have cross check all transform-set & ACL and all looks good so far.

Sep 15 03:14:33 [IKEv1]Group = 193.164.94.47, IP = 193.164.94.47, QM FSM error (P2 struct &0x00007f41f1085ae0, mess id 0xb6aed5ce)!
Sep 15 03:14:33 [IKEv1 DEBUG]Group = 193.164.94.47, IP = 193.164.94.47, IKE QM Initiator FSM error history (struct &0x00007f41f1085ae0)  <state>, <event>:  QM_DONE, EV_ERROR-->QM_WAIT_MSG2, EV_TIMEOUT-->QM_WAIT_MSG2, NullEvent-->QM_SND_MSG1, EV_SND_MSG-->QM_SND_MSG1, EV_START_TMR-->QM_SND_MSG1, EV_RESEND_MSG-->QM_WAIT_MSG2, EV_TIMEOUT-->QM_WAIT_MSG2, NullEvent
2
  • debug crypto ipsec 127 will provide the missing information on why phase 2 is failing to complete. Jan 17, 2020 at 2:16
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can post and accept your own answer.
    – Ron Maupin
    Nov 19, 2022 at 21:37

1 Answer 1

1

This is a pretty old question, so I would assume the OP doesn't need the answer anymore. But I thought I would add some comments for anyone who comes along later and is bumping into similar things.

As a side note, there appears to be something weird with line 2, because it mentions inside interface. I'm not sure why it says that, but it might just be mentioning the ingress interface of the packet that triggered the processing. Not sure. Your NAT is tied to outside, plus the MM processing worked, so this is an issue that i will ignore.

Anyways, moving on. In the debug output, everything seems to be going just fine until about line 76 when your side sends a Quick Mode packet. (This means Main Mode finished successfully, as line 58 confirms.) After that point, your side receives nothing back from the cloud side aside from DPD probes (because lines 77-100 are all DPD chatter). The line you highlighted, line 102, contains a historical list of states of the connection, newest listed first. You can see a while back that it was waiting for Message2 to arrive and it timed out (QM_WAIT_MSG2, EV_TIMEOUT). So, it resent Message1 (QM_SND_MSG1, EV_RESEND_MSG), it started a new timer (QM_SND_MSG1, EV_START_TMR), and then it timed out again waiting for Message2 to arrive (QM_WAIT_MSG2, EV_TIMEOUT). So, your side gives up with an error (QM_DONE, EV_ERROR). Lines 103-118 are all about tearing down the connection, and line 119 mentions the reason: Lost Service (basically "communication failed").

In my experience, the cloud providers don't build VPN tunnels the same way network engineers build VPN tunnels. In an ASA, for example, we fully define all the details of how a tunnel should work. And we always make sure that both sides match each other. And we make sure the ACLs match each other except flipped direction. But, the cloud providers don't configure all of that, just most of it. They stay flexible because they don't know exactly what you are going to configure on your side.

In this case, when Phase 2 was establishing, your "local proxy" (or "interesting traffic", or "encryption domain") is set to 0.0.0.0/0 (lines 2, 71 & 108), which is "any". At this point, the other side goes completely silent and never replies.

What I think has happened here is that the remote side has received your local proxy address, and installed it into its routing logic (that's how they stay flexible with you, since they don't ask you what addresses you will use on your side; instead, they LEARN what addresses you use and they dynamically install them, unlike how we do it on an ASA where it's manually defined). That installation has affected its path to you and it sees you through the tunnel, rather than through the internet. It creates a chicken-and-egg scenario where the remote side can't reach you anymore. When it attempts to send Message2, it never gets to you because QM didn't finish establishing the SA yet.

If my hypothesis is correct, the solution is to use smaller blocks for your local proxy. Here is one example, but there are many correct ways to break it up.

access-list ACL-VPN-CLOUD extended permit ip object-group obj-NET-PRIVATE object-group obj-NET-CLOUD
no access-list ACL-VPN-CLOUD extended permit ip any4 object-group obj-NET-CLOUD

That relies on the object-group you already have called obj-NET-PRIVATE. For someone else on a different firewall, just specify the numeric subnets, like:

access-list ACL-VPN-CLOUD extended permit ip 10.0.0.0 255.0.0.0 10.200.4.0 255.255.255.0
access-list ACL-VPN-CLOUD extended permit ip 192.168.0.0 255.255.0.0 10.200.4.0 255.255.255.0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.