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 did some searching and found a bug ID for a filed bug about not having documentation for this syslog message. It is  CSCtg25127. If you have a support contract I would suggest that you open a case with Cisco TAC about this. Perhaps they might find an explanation. If not you can request that they associate your case with this bug.

Well I did some more searching and did find this in a Cisco doc

713905

Error Message %ASA-6-713905: Descriptive_event_string .

Explanation Information status details appear, which are used to track events that have occurred.

Recommended Action None required.

Here is the link if you want to see the specific entry

https://www.cisco.com/c/en/us/td/docs/security/asa/syslog/b_syslog/syslogs7.html?dtid=osscdc000283#con_4776486

I still have not yet found an explanation for the isakmp vm bit.

Your report has several interesting aspects

1) the possibility that the issue might be directional

2) the fact that the ASA has multiple site to site tunnels but that only 1 seems to be affected

3) the suggestion that it might be related to version of software. The possibility that it might be an interaction between versions of software might help explain both why it might be directional, and explain why on an ASA with multiple tunnels only one of them seems to be affected.

I still encourage someone who is experiencing this symptom to open a case with Cisco TAC.

HTH

Rick

[alexray]

Interestingly, we just yesterday started experiencing the same problem, again, but with two different tunnels to two different clients in two different states with two different firewall vendors (Cisco and Fortigate), though both on Integra for ISP.  We have 90 other IPSec VPNs are are up fine.  Sending traffic from one side or the other doesn't seem to help either, so I don't think it's directional.

Last time we had this error with a different client, it went away on its own after several hours without any further changes.

[alexray]

What firmware version are you on?

[alexray]

What firmware version are you on?

[mickyq · Accepted 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.

[Richard Burts]

Thanks for posting back to the forum to let us know that you have solved the issue and that it had to do with the provider subnet not being routed correctly. +5 for that. I am a bit puzzled what about routing of the provider subnet would create this kind of issue in ISAKMP. And I am curious about this bit but am not sure that we will get an explanation of it.

HTH

Rick

[mickyq]

Hi Rick

The debug message did not actually have any meaning as to what was causing
the problem. Both ends of the VPN were configured correctly but they didn't
seem to be able to reach each other. Once the routed IP subnet was sorted
the tunnel came up.

Looking at other people who have commented with the same issue but more
intermittent could be a routing issue?

There was a post where a vpn was only possible to establish from the remote
end. Ive got one with the same problem. That to me seems like the broadband
router is somehow nating the remote outbound but retaining its source
address. The head end is configured to only accept a connection from a
specific IP. The head end cant open a vpn to the remote as it cant get to
the firewall IP behind the nat.

Thanks for your help and suggestions. Much appreciated.

[Richard Burts]

It is certainly possible for routing issues to prevent a site to site VPN from working. I just would like to know what is this ISAKMP VM bit and how does that relate to a routing problem.

There are some legitimate situations where a site to site vpn can only be initiated by one end but not the other. One of these situations is where one peer has a static IP address and the other peer is behind a nat (especially a dynamic nat). The vpn can be initiated from the nat peer but not able to initiate from the peer with the static address. Perhaps this is what you are describing.

HTH

Rick

[esa_fresa]

@mickyq Hey Mickyq, would you mind marking the response about the ISP as the answer? Sounds like quite a few people are having this same problem.