IPSec DVTI <> Crypto Map

[Soma-II]

First of all, we're currently testing different IPsec scenarios. This particular device (ROUTER_SPOKE_CRYPTO) is proving to be especially difficult when it comes to establishing an IPsec connection. This scenario does not involve any VRF awareness.

I have ROUTER_HUB, which has a tunnel successfully established with another spoke router using SVTI. Now, I’m trying to set up a second tunnel, but this time using a Crypto Map (I know it's a bit outdated, but I have to use it). I’ve encountered a problem that seems simple, but I can’t figure out why it’s not working.

For reference, there are other VTIs working on this device (ROUTER_SPOKE_CRYPTO), but none of them use a Crypto Map.

Here are some details:
- Phase 1 is established
- Phase 2: no SAs are being established
- Ping works unless we use a loopback as the source — in that case, the ping test fails (more details are in the file)

It seems to be an ACL issue, but I’ve tried several different configurations without success. I’ve also tried an alternative method to apply the crypto map, changing some commands, but still no luck.

I would really appreciate any help — I’m honestly stuck. I have a feeling it’s something obvious that I just can’t see.

[Rob Ingram · Accepted solution]

@Soma-II first off, you don't need to mirror the crypto ACL, you just need one ACE - from your local source IP to the destination.

The output of "show crypto ipsec sa" implies traffic that matches your crypto ACL is a virtual-access interface, not a crypto map - which is what I would expect.

interface: Virtual-Access1
Crypto map tag: Virtual-Access1-head-0, local addr 172.21.55.70

protected vrf: (none)
local ident (addr/mask/prot/port): (55.55.55.3/255.255.255.255/0/0)
remote ident (addr/mask/prot/port): (55.55.55.1/255.255.255.255/0/0)
current_peer 172.22.55.70 port 500

The configuration of the hub does not have a crypto map configuration, are you attempting to use a crypto map on the spoke and a dVTI on the other (hub)? You would need to use a crypto map on Amsterdam, with a crypto ACL that mirrors the spoke.

[Soma-II]

Thank you, Rob, for your response.

Regarding the ACL, yes, I know it's not strictly necessary, but I had no idea what was going on with that ping issue, so I kept modifying the ACL again and again. I'll go ahead and leave it with just a single line, then.

So, are you saying it's not compatible to use a Crypto Map spoke with a DVTI hub? I thought the hub could accept requests from any spoke, regardless of their configuration.

If that's not the case, then how is the hub even accepting the ISAKMP configuration from the crypto map spoke?

Thank you so much for your help.

[Rob Ingram]

@Soma-II that's not a supported configuration. If using policy based VPN (crypto maps), use crypto maps on both routers. If using routed based VPN, use VTI on both peers or VTI on the spokes and dVTI on the hub or use multi SA tunnel.

Multi SA tunnel uses a crypto ACL with a tunnel interface https://www.cisco.com/c/en/us/support/docs/security-vpn/ipsec-negotiation-ike-protocols/214728-configure-multi-sa-virtual-tunnel-interf.html. So you could have one router with a crypto map and the other configured with Multi-SA tunnel interface (not dVTI).

In your scenario, the hub matches any identity, so the connection request from the router using the crypto map is probably matching this isakmp profile and that's why it seems to be creating a virtual access interface using VT 555 as the template and is failing.

crypto isakmp profile Isakmp-Profile-ROUTER_HUB
 keyring IPSec_key-ring_ROUTER_HUB 
 match identity address 0.0.0.0 0.0.0.0 
 virtual-template 555

To ensure the connection request from the crypto map does not match the isakmp profile above, you could explictly send the identity from the spokes, such as email, fqdn, keyid and be more specific on matching on the identity, rather than match on 0.0.0.0/0.0.0.0 (any). Therefore the crypto map traffic would not match that isakmp profile and create a VA. Here is an example using identities for IKEV2, the same priniciple should apply for IKEv1.

[Soma-II]

Hello Rob,

Your answer has helped me a lot, thank you for your response.

Just to clarify, should I use IKEv2 both on the hub and the spokes to support this broader scenario? It's crucial for us to build a hub that can accept any potential connection.

Thanks again for your help.

[Rob Ingram · Accepted solution]

@Soma-II to be clear, you can only establish a tunnel when both peers support the same IKE version. However a router can be configured to support both IKEv1 and IKEv2 at the same time and establish a tunnel using IKEv1 to one peer and IKEv2 with another peer.

I'd recommend migrating all tunnels to IKEv2 as it supports the strongest crypto algorithms compared to IKEv1, and possibly less complexity.

[Soma-II]

Okay Rob, thank you so much for your help.
Looks like I have quite a bit of work to do, and a lot of new things to learn!

Thanks again for sharing your knowledge.

[Soma-II]

Hello Rob!!

First and foremost, sorry for writing here again even though this post is marked as solved, but... I found the problem! The crypto map can be used when connecting to a DVTI hub! I couldn’t do it before because there was an issue with the spoke router, it turns out it was just too old to complete Phase 2. I moved the configuration to another spoke router, and it worked instantly.

Don’t get me wrong, I really appreciate all your help. That’s why I wanted to share this good news with you.

I've attached some tests.

Thank you!