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.
Solved! Go to Solution.
The problem turned out to be the routed IP subnet supplied by the ISP.
the router picks up an IP address for the WAN interface then the ISP provide me with a /29 subnet to use. this subnet wasnt being routed properly. It was sorted by the ISP and its working now.
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.
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
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?
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.
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?
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.
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.
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?
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.
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.
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.