This topic is to discuss the following lesson:
Excellent write up. I’ll be testing this in a lab here soon!
I am to write up the lab for my upcoming CCNP Security.
I have a question the cloud in the drawning is it also a router ?
Or am I wrong ?
DMVPN is often used on the Internet so the cloud represents a bunch of routers from different ISPs.
For the phase 1 if we have multiple policy, then how we can define which policy we should use.
Your example use the crypto isakmp policy 10.
When you have multiple statements in the policy then the routers will negotiate to figure out which policy to use. You can’t configure explicitly which one to use.
Ok. Noted. Thanks
What is the meaning of “works fine only downside is many tunnels hub so badly scalable. therefore getvpn in a different lesson” in your conclusion?
The most security solution is to use a pre-shared key for each hub/spoke combination. If you have 100 spokes, you’ll need to configure 100 pre-shared keys. For a few spoke routers this is no problem but if you have a lot then this will become an administrative nightmare. GETVPN is more suitable for larger setups, that’s something I’ll cover in another lesson
Do you have lab talk about IPsec Profile Name with keyword shared?
I don’t have a complete example but it’s easy to replicate. First, you will need this topology:
And then you can use the IPsec configuration from this example:
The only change is that you will need to use “tunnel protection ipsec profile DMVPN_PROFILE shared” on the spoke routers instead of “tunnel protection ipsec profile DMVPN_PROFILE”.
No need for an ACL here?
You mean to select traffic that should be protected by IPsec?
We don’t need it here since we use the tunnel protection ipsec profile command on the tunnel interfaces.
how many crypto isakmp policies can have in a router, one or more…?
You can create a lot of policies:
Router(config)#crypto isakmp policy ? <1-10000> Priority of protection suite
Up to 10000 on this router (Cisco 1841)
Can you please clear something for me. I understand with policy based vpns we don’t nat vpn traffic via the no nat acl or the twice nat command. How does route based know not to nat traffic? Is it simply because there is no nat configuration attached to the tunnel? Does the same logic apply to cisco and palo alto route based vpns?
That’s exactly right. A route based VPN incorporates a routed tunnel interface, and just like any routed interface, NAT will be employed only if there is a “NAT configuration attached” to the interface, as you say. Policy based VPNs on the other hand encrypt and encapsulate a subset of traffic flowing through an interface according to a defined policy. We have to specifically state that this traffic is exempt (or not) from any NAT rules that may be configured on the interface.
I hope this has been helpful!
just 2 questions
i can’t understand the following sentence :
werkt prima enige nadeel is veel tunnels op hub dus slecht schaalbaar. daarom getvpn in een andere lesson.
any tuto coming soon about getvpn ? since we know now that DMVPN is not scalable in with secure constraints …
Thank you !
The first part is a leftover from my notes (in Dutch). Just removed it.
Get VPN is something I’ll work on soon.