DMVPN - Spokes with different IPsec encryption

[Alexander Rumpf-Luijten]

1. Is it possible to configure on the Hub different IPsec encryptions for different Spokes or must all Spokes configure with the same IPsec encryption?
2. If on two Spokes different IPsec encryptions are configured, can the build a Spoke-to Spoke VPN tunnel with IPsec or is the traffic going over the Hub?

[Giuseppe Larosa]

Hello Alexander,

1)

see

http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/DMVPN_2_Phase2.html#wp93772

>>There must be at least one matching ISAKMP policy between two potential crypto peers

the ISAKMP policy may contain multiple clauses that are attempted in order,  but to build the ISAKMP security association a match is needed, policy sequence number is not important (it doesn't need to match)

2)

as explained above if no agreement is found between the two spokes the spoke to spoke tunnel will not be able to be established.

But because routing information travels only on spoke to hub tunnels with next-hop referring to other spoke (phase 2), you may experience black holing of traffic between the two spokes!

I'm afraid no fallback to hub is possible at least in DMVPN phase 2.

I would say real world implementations use the same encyption methods in a given cloud and PKI to distribute certificates for scalable and secure negotiation.

Hope to help

Giuseppe

[Peter Paluch]

Hello Giuseppe,

I have enjoyed reading your answer very much.

I'm afraid no fallback to hub is possible at least in DMVPN phase 2.

As far as I know - and please correct me if I am wrong as I have not worked with DMVPN solutions extensively - even in DMVPN phase 2, if a translation for another spoke is not currently found in local NHRP cache, the local spoke will send the packet to the hub router. But frankly, that cannot be considered a fallback.

If spoke routers used p2p GRE tunnels then the traffic would always go through the hub router - but that would nullify one of the major advantages of the DMVPN.

I would say real world implementations use the same encyption methods in
 a given cloud and PKI to distribute certificates for scalable and 
secure negotiation.

Absolutely agree. And also, if necessary, each router can be preconfigured with a set of ISAKMP and IPsec policies to be able to cooperate with both better and less capable neighbors.

Best regards,

Peter