Ignoring IKE SA (dst) witho ut VM bit set

[mickyq]

trying to add a new l2l vpn with the same config thats been deployed to many sites between asa 5505 (remote) and asa5550 (head end)

with this new one we are using a new type of broadband router and im seeing debug error:

       Ignoring IKE SA (dst) without VM bit set

is it nat-t?

nat-t is turned on at the remote end but not the head end. if i turn it on will that affect any of the established vpns?

what is the VM bit. how do i set it.

[Richard Burts]

I doubt that it is nat-t. nat traversal should be enabled by default. Explicitly turning it on should not impact established vpn. I am not familiar with isakmp vm bit. I have done a little searching without finding anything helpful which is surprising and disappointing. If you have a support contract it might be worth opening a case with Cisco TAC.

HTH

Rick

[mickyq]

thanks for the reply Rick

I couldnt find anything either. Broadband routers are becoming a bit of a pain.

cheers

[alexray]

I'm actually having the same problem - starting just today, I'm seeing this message on one of my tunnels.  I've never seen it before, have tried rebuilding the tunnel on both sides several times, etc, no dice.  I have 80 other VPNs with the same configuration and have set up hundreds in the past, for the life of me I can't figure it out.  And there is virtually no documentation on that 713905 "VM bit" error.

I did some additional debugging and saw this:

Mar 22 08:19:08 [IKEv1 DEBUG]IP = [peer IP], IKE MM Initiator FSM error history (struct &0xb0b4c690) <state>, <event>: MM_DONE, EV_ERROR-->MM_WAIT_MSG2, EV_RETRY-->MM_WAIT_MSG2, EV_TIMEOUT-->MM_WAIT_MSG2, NullEvent-->MM_SND_MSG1, EV_SND_MSG-->MM_SND_MSG1, EV_START_TMR-->MM_SND_MSG1, EV_RESEND_MSG-->MM_WAIT_MSG2, EV_RETRY
Mar 22 08:19:08 [IKEv1 DEBUG]IP = [peer IP], IKE SA MM:e7d20701 terminating: flags 0x01000022, refcnt 0, tuncnt 0
Mar 22 08:19:08 [IKEv1 DEBUG]IP = [peer IP], sending delete/delete with reason message
Mar 22 08:19:08 [IKEv1]IP = [peer IP], Warning: Ignoring IKE SA (dst) without VM bit set

Mar 22 08:19:11 [IKEv1 DEBUG]Pitcher: received a key acquire message, spi 0x0
Mar 22 08:19:11 [IKEv1]IP = [peer IP], IKE Initiator: New Phase 1, Intf OSPF, IKE Peer [peer IP] local Proxy Address [local subnet], remote Proxy Address [remote subnet], Crypto map (outside_map)
Mar 22 08:19:11 [IKEv1 DEBUG]IP = [peer IP], constructing ISAKMP SA payload
Mar 22 08:19:11 [IKEv1 DEBUG]IP = [peer IP], constructing NAT-Traversal VID ver 02 payload
Mar 22 08:19:11 [IKEv1 DEBUG]IP = [peer IP], constructing NAT-Traversal VID ver 03 payload
Mar 22 08:19:11 [IKEv1 DEBUG]IP = [peer IP], constructing NAT-Traversal VID ver RFC payload
Mar 22 08:19:11 [IKEv1 DEBUG]IP = [peer IP], constructing Fragmentation VID + extended capabilities payload
Mar 22 08:19:11 [IKEv1]IP = [peer IP], IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 328

Mar 22 08:19:19 [IKEv1]IP = [peer ip], IKE_DECODE RESENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 328

[mickyq]

Hi

That looks like the same debugs I was seeing.

We use a broadband router with routed public IP's. we out a public ip on the
router LAN interface then another on the firewall outside. Usually we can
hit the firewall no problem but for some reason with a new type of router
supplied by the ISP we cant get through.

Debugs at the other end suggested the WAN IP of this router was being used.
There seems to be some sort of nat going on.

If I get to the bottom of it ill post the solution.

[Richard Burts]

I hope that you do make progress and if you do that you will post back to the forum about it. I have a couple of thoughts about this. The error message suggests that it is complaining about an isakmp packet from the remote peer. What do we know about that remove peer? What kind of device is it? Any chance of getting config information from it? Any chance of getting any debug information from it?

HTH

Rick

[mickyq]

Hi Richard

The l2l vpn is between an ASA 5540 (head end) and a remote asa 5505.

The head end terminates several vpns of the same type. The configs are the same on each vpn. The only difference in this case is the broadband router. Im working with the ISP to try and resolve the problem.

ill post the solution when I get it.

cheers

[LesterClayton]

I just wanted to add that I've also had this problem recently, and the solution for us was to replace the CPE from the internet service provider. Sadly, I did not get any information on what equipment the CPE was nor what it was replaced it. I asked for it but was not provided. The ISP in question was Altibox in Norway. I know this isn't a helpful reply, but I think you need to focus on replacing the CPE rather than spend time on the ASA configurations.
Lester

[Richard Burts]

You have mentioned a couple of times that you are using a different broadband router and associate the problem with this. I have trouble seeing how the broadband router would impact the ISAKMP negotiation which takes place between the two peers. If your head end 5540 has site to site vpn with several remote 5505 and has a problem with only this one then I wonder if there is something on this one that is different from the other 5505 which do not have this issue?

Is there a chance that you could get output from the remote 5505 for debug crypto isakmp?

HTH

Rick

[Richard Burts]

Lester provides interesting experience with this problem. If he says that replacing the ISP equipment solved the problem then perhaps you do need to continue to focus on working with the ISP about their broadband router. But I still do not understand how the broadband router could do something that impacts the data for the ISAKMP negotiation between the two ASAs.

HTH

Rick

[alexray]

Interestingly, the problem resolved itself.  I had tried rebuilding the VPN on both sides about six times, restarting equipment, etc, over the course of 3 hours and didn't have a solution.  I let it sit another 6 hours and suddenly it negotiated again.

[Richard Burts]

It is an interesting observation that the problem may be intermittent. Sometimes it is a problem and sometimes it works. I wonder if it might depend on which peer initiated the tunnel?

If the head end has multiple site to site vpn and only one has the issue then it suggests that the head end is ok and the problem may be on the remote. Would one of you be able to test trying to initiate the vpn from the head end and then initiating the vpn from the remote and see if that makes any difference?

HTH

Rick

[alexray]

I did try that, though rather naively by just initiating a ping from one side or the other - didn't seem to make a different.  My working theory is that the ISP was meddling somehow, though I'm still not entirely sure what the error logs I posted mean.

[Richard Burts]

It is good (but disappointing) to know that you tried to initiate the vpn from both sides and it did not seem to make a difference. So there must be some other factor that was making it fail and then allowed the vpn to establish.

I am hoping that we might get a set of debug output from the remote and it might provide some clue to the issue.

HTH

Rick

[tylor_renouard]

Hi 

I am actually seeing the same, or a very similar issue, on an ASA that I manage.

With our tunnel it can be initiated by interesting traffic from the remote end and Phase 1 and 2 come up immediately. However if traffic is initiated from our side towards the remote end the tunnel doesn't even seem to try and complete Phase 1, I only get the error: 

6

May 02 2018

10:15:02

713905

IP = X.X.X.X, Warning: Ignoring IKE SA (dst) without VM bit set

We had a similar issue on another tunnel a few weeks ago, but that may have been related to the remote end of the tunnel as the remote device (Openswan) had a large amount of changes made in order to get the tunnel to come up again.

Interestingly we have 6 other VPNs on the same ASA which have been there for some time with no issues. Based on how recently there seems to be an influx of this issue I'm wondering if it's an IOS bug. I have upgraded the ASA to version 9.6(4)3 to patch the critical vulnerability earlier this year. All tunnels configured before that upgrade work perfectly.