Thanks for posting the question.
Both DMVPN and FLEXVPN and considered overlay virtual private network technologies and they both can work on hub-spoke deployments.
DMVPN provides the capability of joining multiple spokes with a hub and also dynamically establishing tunnels between spokes essentially in a phase 3 deployments.
Apart from DMVPN, we also offer other different styles of configurations/deployments like VTI, crypto maps, EZVPN etc. Flex VPN as the name suggests is very flexible and a unified way of dealing with all these options, allowing your network to be prepared to simultaneously handle different VPN models. Here are few key points where Flex VPN differs from DMVPN:
Here's an introductory guide to Flex:
Hope this helps.
Please rate helpful posts
We have some scenarios were the VPN-IPsec gets struck on MSG_5 andf MSG_6 Also would like to understand further more on the MM_MSG_5 and MM_MSG_6 except the PSK and any other parameters are to be checked.
Also to understand further more on the ASP table and to correlate the ASP drops while troubleshooting.
Mostly the tunnel would be stuck at these msgs due to PSK/CERT issue.
Apart from that if there is an issue with UDP 4500 communication, if one end has PFS set and the other end does not. In this case, the error will appear/disappear and the connection is repeatedly torn down.
This msg is also seen when NAT Traversal was on when it needed to be turned off.
Another reason would be if the state goes to MSG6 and the ISAKMP gets reset that means phase 1 finished but phase 2 failed. Check that IPSEC settings match in phase 2 to get the tunnel to MM_ACTIVE.
The Accelerated Security Path (ASP) on the ASA appliance comprises of 2 components; The Fast Path and The Session Management Path.
There can be multiple reasons why ASA drops the packets due to ASP.
It is always good to clear the asp drops on ASA using clear asp drop and then check for the counters while troubleshooting connection related/packet drop issues:
ciscoasa# sh asp drop
Flow is denied by configured rule (acl-drop) 46260
First TCP packet not SYN (tcp-not-syn) 112
TCP RST/FIN out of order (tcp-rstfin-ooo) 9
Slowpath security checks failed (sp-security-failed) 1445
ICMP Inspect seq num not matched (inspect-icmp-seq-num-not-matched) 5
FP L2 rule drop (l2_acl) 870
Interface is down (interface-down) 1
Dropped pending packets in a closed socket (np-socket-closed) 9
Telnet not permitted on least secure interface (telnet-not-permitted) 8
Last clearing: Never
Last clearing: Never
You can even use a capture with a specific filter:
For instance if there is a packet dropped due to No-valid-adjacency you can use the asp drop capture:
cap drop type asp-drop no-adjacency
or lets say for ACL related issues you can use acl-drop filter.
In case you need to check all reasons use all keyword.
cap drop type asp-drop all
The issue can be with any VPN tunnel. The question is whether we can choose a certain root/intermediate certificate to be sent out for each tunnel, as currently we are sending all of the intermediate/root certificates in initial IKEv2 exchange for every tunnel and this approach is making a packet size bigger. The devices at the other end of tunnel which are not able to defragment (or may not even have option to do that) the tunnel is not coming up.
the issue is not with the identity certificate; it is with the amount of intermediate and root certificates been presented on the tunnel.
I’m aware that we can get specific identity certificate (trustpoint) for a specific tunnel. However, it doesn’t help us keep the packet size lower due to the multiple intermediate/root certificates presentation during the initial IKEv2 exchange as mentioned in the key and certificate exchange sections in IKEv2 RFC standards.
Let me try to clarify the issue further.
Let’s say PEER A and PEER B wants to establish a VPN connection, which is certificate-based.
Now, to establish the VPN connection, from the PEER A point of view it will need PEER A’s identity certificate and PEER B’s root/intermediate certificate to be able to trust the certificate and establish the VPN.
Similarly, PEER B also needs its Identity certificate, and root/intermediate certificate of PEER A at its end to establish the VPN tunnel successfully.
After the VPN configurations, the PEER A and PEER B start exchanging IKE Auth and Identifier messages, and because they both trust each other’s certificate, the tunnel gets established successfully. The CRITICAL point here is that PEER A/PEER B (whoever is the initiator) in it’s initial IKEv2 Auth messages, will send all the trust points (root/intermediate) which exists/imported in the database of the Firewall and its identity certificate to another party to successfully establish the tunnel.
Now, trying again to explain the issue, if there are only PEER A and PEER B communication, that is no problem. However, we have more than 100 certificate VPN connections, and now we are getting at the stage wherein our initial messages for IKEV2 because the Firewall will always send all the trust points root/intermediate certificated (NOT talking about identity certificates here) for all other tunnels that the packet size is increasingly getting bigger.
It is a pretty generic behaviour of IKEV2 and accordingly explained in the process RFC standards of IKEv2. The question here is, in the light of RFC standards for IKEv2, is there a ‘hidden’ command or configuration which we can do that for the certificate-based VPN’s, we can not only choose which identity certificate we want to present. Also, critically important, can we select only one or two root/intermediate certificates for each tunnel (instead of the normal IKEv2 behaviour, i.e sending all the root/intermediate certificates for all the other tunnels)?
I would ideally need the config on the device to check the options.
However, let's take an example of ASA on which we can configure a specific Trustpoint with a chain to send to the remote side.
crypto map map-name seq-num set trustpoint trustpoint-name [ chain ]
Another way to overcome this is using IKEv2 fragmentation on the device:
crypto ikev2 fragmentation mtu <>
Not sure what is the remote peer on the other side and also whether the Cisco device is acting as an initiator/responder.
You can make the local device as an initiator so that we send a specific chain of certs.
We are facing issue with one of our clients where the ftd is building vpn with azure. The problem arises when the tunnel flaps either due to no traffic while rekey or any maintenance from the azure end. Azure end supports route based vpn with any any traffic selectors while on ftd end we have policy with specific subnets and azure is initiating the vpn before ftd, as a result the phase 2 negotiation fails. And even though we are initiating traffic from behind the ftd since there is already a phase 1 ftd doesnt initiate a new one.
If we force the ftd to be initiator only, will it not create a phase one when azure initiates?
Also is it possible to put any any in the crypto policy and put in the end so it will not cause any disruption to other traffic?
Any thoughts around this?
This is expected since while rekeying, Azure is sending the unsupported traffic selector (any/any), disrupting the tunnel.
FTD would support Route-based VPN's/VTI in future releases.
However, the only supported resolution is to replace VPN Type Route-based with Policy-based on Azure, which will require:
Connect Azure VPN gateways to multiple on-premises policy-based VPN devices using PowerShell:
This will also require a downgrade of VPN from IKEv2 to IKEv1 on FTD.
I found another helpful link to configure the same on Azure:
Also, regarding your query to use any any at the last (I think you are referring to use ANY/ANY crypto acl) at the last.
However, using this means every traffic would start hitting this tunnel and would even impact the normal outgoing traffic.
AntConnect 4.8 question:
We just deployed AnyConnect 4.8.00175 to our MAC users in anticipation of macOS Catalina (10.15). Cisco AnyConnect 4.8.00175 is the first version that officially supports operation on macOS Catalina and contains no 32-bit code. During the install, some of our users are seeing the following:
From what I can find, manifesttool.exe is part of the AnyConnect installer. This pop-up is in regards to applications running 32 bit code, and not being 64 bit capable. I cannot find a bug report or anything in the release notes regarding this. My concern is that after a MAC user is on 10.15, will that user be able to install AnyConnect 4.8?
Yes, Apple has been preparing its customers for a pure 64-bit operating system while they move to 10.15:
Accoring to the official release notes, anyconnect 4.8 does will support 10.15 and it doesn't contain any 32-bit code:
Please rate helpful posts
And thanks Puneesh for responding. I agree with your comments, and had reviewed both of those links prior to posting here. My question/concern is if 4.8 is purely 64 bit coded, why are some of my users getting the manifesttool alert window during the install?
May I know if you tried re-installing the Anyconnect application again on this affected MAC (after a reboot)?
I checked internally and couldn’t find anything matching on this version.
We may need to check this issue with the developers.
I would request you to open a TAC case with the DART file from the same machine.
Are you referring to the IPS module/Firepower?
If yes, you can refer to the following links:
I had configured IPsec tunnel throw CISCO router. There was a CA with a root and SEGW certificates. I want to configure Cisco router with new configuration - it has changed: Multi-Tier PKI: 6 certificates chain on CA VM, each cert in separete .pem file. How to configure Cisco SEGW router right now - in case Multi-Tier PKI (manual configuration)? I found those steps on CISCO instructions, but there is no information what in case Multi-Tier PKI: