Hi Laz,
Thanks for the explanation. I just want to clear something up.
The multicast traffic only flows directly to a spoke once a unicast packet sent to that spoke has caused a tunnel to be built. i.e. the multicast traffic itself cannot cause the tunnel to be built. Is that correct?
Thanks.
Sam
Hello Samir
Yes you are correct. Multicast traffic will not be able to initiate the creation of point to point GRE tunnel between spokes. If this tunnel does not exist, multicast traffic will be routed via the hub. Only unicast traffic will trigger the creation of a spoke-to-spoke tunnel. This is simply due to the design and behavior of the NHRP protocol.
Specifically, the NHRP resolution process is triggered only by unicast traffic and not multicast traffic.
When multicast traffic is sent to the hub, it is forwarded to all registered spokes. Since the multicast traffic is not specifically addressed to a single spoke, it does not provide an opportunity for NHRP to learn about the other spokesâ public IP addresses or establish direct GRE tunnels.
This is a design choice for NHRP, which helps to optimize network traffic flow and reduce unnecessary overhead. If multicast traffic were used to establish spoke-to-spoke tunnels, it could result in numerous unnecessary tunnels being built, which could consume additional resources and complicate the network. Thus it is more efficient to rely only on unicast to trigger the NHRP resolution process.
I hope this has been helpful!
Laz
I had a question, is there anyway we can get a lesson with DMVPN and IPsec with OSPF instead of RIP?
Hello David
If you have suggestions for specific lessons and lesson topics, feel free to use the Member Ideas page below. There you can make your suggestions for additional lessons that Rene can add in the future. You may find that others have suggested something similar, so you can add your voice to theirs.
In the meantime, take a look at the following Cisco documentation which describes a scenario where DMVPN with IPSec and OSPF are being used, along with a few more features.
Doing a search online, I was able to find some additional resources that describe such a setup.
I hope this has been helpful!
Laz
Hello!
Can you provide any resources I can use to better understand the IKEV2 configuration on an iOS router using DMVPN & Cisco router for a PKI server.
Hello James
The following lesson shows how to set up DMVPN with IPsec:
This doesnât include the use of a PKI server, however you can find further information about that for a DMVPN environment at the following Cisco documentation:
This documentation describes a DMVPN network using IPSec along with a CA server, a role which is played by the hub of the DMVPN topology.
If you would like Rene to create a new lesson with your particular setup in mind, feel free to make your suggestion at the following member ideas page:
There, you may find that others have made similar suggestions, and you can add your voice to theirs.
I hope this has been helpful!
Laz
Greetings,
This may be simple, and I might be overthinking it but this part right here
Keep in mind that encryption occurs before multipoint GRE / NHRP.
Would it be possible to elaborate further? I always run into issues at work when troubleshooting DMVPN/IPEC and when I am told Encryption happens before multipoint GRE/ NHRP, how is that exactly?
Thank you for your time
Hakeem
Hello Hakeem
The statement that âencryption occurs before multipoint GRE/NHRPâ is simply highlighting the sequence of operations in the DMVPN/IPSec setup. Encryption, provided by IPSec, happens before the encapsulation of data into multipoint GRE and the NHRP protocol. In other words, data is encrypted first by IPSec to ensure confidentiality, then encapsulated in multipoint GRE for routing, and finally, NHRP is used for address resolution.
This means that the GRE headers and the NHRP additional information remain unencrypted. Does that make sense?
I hope this has been helpful!
Laz
Lazarus,
Yes it does, I was overthinking it. Thanks much for the explaination.
Have a great weekend.
-Hakeem
Hello again,
I was a bit curious about the crypto map command. When I was doing a practice quiz on boson with IPSec I got it incorrect because I set up as seen here instead using a transform-set instead of using a crypto-map. How can I tell when I am supposed to use the crypto-map command instead.
Thank you!
Hello Cameron
The crypto-map command is used to bind or tie together all the various IPSec configuration elements. This includes the transform-set, the ACL that identifies the traffic, and the peer at the other end of the IPSec tunnel.
On the other hand, a transform-set is a combination of security protocols and algorithms. When you define a transform-set, you are essentially defining the methods and protocols that IPSec should use to secure your data.
So, you canât really replace one with the other. They both serve different purposes in the IPSec configuration process.
In general, you should use the crypto-map command when you are ready to tie together your IPSec configuration and apply it to an interface.
I hope this has been helpful!
Laz
I am going to be setting this up, phase 1 DMVPN only, where the spokes are behind CG-NAT and multiple spokes may be behind the same CG-NAT public IP, will this work? I see articles suggest using tunnel mode for IPSec then. Essentially double tunneling. I am not overly familiar with setting up VPN tunnels unfortunately. Is there a way to do this such that the HUB configuration does not need to grow for every spoke that is added (like with DMVPN)?
Hello Lucas
This is indeed a very interesting scenario. Although I donât have direct experience with such a production network, I can share with you some thoughts about it that may help you in your learning pathâŚ
So will DMVPN Phase 1 work behind CG-NAT? Yes, but with some important limitations. The spokes behind the CG-NAT can initiate connections to the hub, but spoke to spoke communication will be hampered because NHRP doesnât function when spokes are behind NAT, especially if multiple spokes are behind the same IP address!! NHRP relies on publicly reachable IP addresses, which donât exist in a CG-NAT environment.
The solution for this is indeed using IPsec tunnel mode or double tunneling. You can use IPsec tunnel mode (or alternatively GRE with IPsec), which is often used in such cases. IPsec tunnel mode, especially with IKEv2 and VTIs, is quite NAT-friendly, so this is usually the preferred solution. Now, all of this adds overhead and complexity, but it does work.
Keep in mind that if the level of complexity of such a solution gets out of hand, you may consider other solutions such as FlexVPN which works behind CG-NAT.
I hope this has been helpful!
Laz
Thanks for the answer
It is tough to tell but based on your answer do you believe that Phase 1 DMVPN will still work if two of the spokes are behind the same public facing IP (CG-NAT)? I believe it would be broken as the NMBA table would have two tunnel endpoints, at the same public IP. I am not sure how DMVPN handles PAT in general, as IPSec adds a UDP header with port 4500, but I do not see any documentation on DMVPN stating it saves port information for tunnel connections.
I am asking because if Phase 1 will work I would be happy; as I do not need spoke-to-spoke - but it seems like even Phase 1 may be broken with this configuration.
Suppose Phase 1 is broken and I have to head down the path of configuring DMVPN over a second IPsec tunnel to handle the CG-NAT, do you have articles teaching on how to configure an IPsec tunnel for a hub and spoke design. Specifically when the spokes have dynamic IP addresses (acting as DHCP clients) and are behind a NAT device doing PAT (CG-NAT), though I believe NAT-T will naturally kick in for that case.
Assuming I get that IPSec in dynamic spoke-hub working - I believe my last step would be to setup a DMVPN without IPSec configuration, and use the IPsec Tunnels as the Public IPs of the DMVPN setups. (This is needed for dynamic routing protocols between the spoke and hub)
I canât use flexVPN because some of the spokes will use linux based and other routing systems that are IPsec and DMVPN capable, but I believe flexVPN is Cisco proprietary.
Thanks!
Hello Lucas
Sorry for not being clearer on this point. No, Phase 1 DMVPN will not work âout of the boxâ when multiple spokes are behind the same public IP using CG-NAT. Indeed, it would be broken for the reasons you shared in your post. However, GRE over IPsec tunnel mode, using IPsec will solve the issue of the two spokes behind the same public IP. It works because with double tunneling each spoke first creates an IPsec tunnel in tunnel mode to the hub. Inside that IPsec tunnel, it establishes the GRE tunnel for use with DMVPN. From the hubâs point of view, each spoke appears to come from a unique IP.
For DMVPN over IPsec in general, take a look at this lesson here:
This Cisco reference may also be useful:
We donât have a lesson with double tunneling, but if youâre interested, you can make a suggestion for such a lesson in the Member Ideas page below:
Yes, what youâre saying is indeed on the right track. You can run DMVPN (GRE/NHRP/dynamic routing) over dynamically established IPsec tunnels in tunnel mode when dealing with CG-NAT and dynamic IPs. This is a clean and scalable design pattern for NAT-challenged deployments.
Youâre right, FlexVPN is Cisco-specific. Itâs based on IKEv2 with Cisco-specific enhancements, and while the IKEv2 part is standards-based, features like dynamic VTIs, IKEv2 profiles, and Easy VPN group policies make it not fully interoperable with non-Cisco gear.
I hope this has been helpful!
Laz
I did put a in a request for a lesson on this as they literally donât exist anywhere on the web. Based on the available resources online one would think it is not possible to have DMVPN setup with IPsec in tunnel mode. Thanks for all the great information!
Also sorry I did think of one more thing. I originally thought that when sending traffic from the hub to the spokes that the inner GRE IP header, and the outer IPSec Tunnel IP header would have the same source and destination IP addresses, but that is only true after they go through the NAT device, I think. Here is my thoughts on what the IP headers will look like:
If we were trying to ping from the mGRE tunnel to the GRE tunnel. The original, or innermost, IP header would have a source IP address of the mGRE interfaceâs IP address and a destination of the spokeâs GRE Tunnel IP address. Obviously the link local route would then push this packet into the mGRE tunnel interface.
The second IP header would be added by the mGRE tunnel, I would expect the new mGRE added IP Header to have the source address of the public interface on the HUB, and the destination address to be the private IP address of the spokeâs public facing interface. Sounds weird to say but with CG-NAT, the public interface of the spoke is really a private address because it was NATted by the ISP, DMVPN will not know this since it was protected from this carnage by the IPsec tunnel.
finally, the packet enters IPSec Tunnel which is configured on the mGRE. I would expect the new IPSec Header added by IPsec to have the same source as the mGRE header, that is the public interface of the HUB. The destination however would be different, it would be the public IP address of the NATting router. IPsec would also add a UDP header with the unique port shared by the router for this particular spokes connection.
The packet would traverse the internet and enter the NAT router, I would expect the outermost header to be changed, such that the destination is now the the spokes NAT address (private address). At this point the mGRE and IPsec IP headers look the same. The UDP header would have the destination port changed to 4500. and the packet would be delivered to the spokes.
I tried to make this as easy to follow without diagrams, does the IP addressing of the packets sound correct to you?
Hello Lucas
Good job in requesting that, I think itâs worth looking into. The truth is it is not as common an implementation, but I believe it is common enough to warrant a lab or demonstration of some kind.
As for your description concerning the source and destination IPs, I believe that your explanation is well done. On the hub end, because we assume the Internet-facing interface has a public IP address that is indeed public, it will be the same IP address used for both the GRE tunnel endpoint and the IPsec tunnel endpoint.
On the other end, if the spoke is behind CG-NAT, the GRE tunnel endpoint will indeed use the spoke;s public facing interface, which is a private address because itâs behind the CG-NAT.
And finally, the IPsec tunnel header, which performs the NAT traversal, will have the public NATted IP of the spoke (as allocated by the NAT device) as the destination. Once NAT is traversed, the destination address in this header will be that of the public-facing interface of the spoke, which is a private address because itâs behind CG-NAT.
Based on your description, Iâd have to say that your understanding is spot on. Kudos on a clear and thorough investigation!
I hope this has been helpful!
Laz