In the first part of this article, I presented the following scenario: Site A and Site B have a site-to-site VPN connection between themselves. Site C is a new site that also needs to have VPN access to Site B but, for some reason; this new VPN access has to go through Site A, which will then route it to site B. In the previous two articles, we have been able to successfully bridge the VPNs of both sites B and C through site A; in the first article, we used normal crypto maps and multiple entries in the access lists that defined interesting traffic while we achieved the same thing in the second article using virtual tunnel interfaces (VTIs).
In this article, we will complete our discussion on another method of achieving this on Cisco IOS. In the final (fourth) article, we will see how it can be done on Cisco ASAs. The diagram we have been using is as follows:
Note: For this lab, the Internet cloud is just a router with three interfaces with IP addresses 192.168.10.2, 192.168.20.2, and 192.168.30.2.
Dynamic Multipoint VPN (DMVPN)
There is an article on the Intense School site that gives an introduction to DMVPN, so I will not go over those details again. There is also a great article on the INE blog that discusses DMVPN in detail and, if you are going for a CCIE level exam, then you should definitely read that article.
DMVPN, as we will see in this article, is similar to using VTIs like we did in the last article. However, two major differences exist:
The tunnel mode is different. For DMVPN, we use GRE (multipoint) tunnels. In DMVPN, the hub will require multipoint GRE tunnel interfaces but the spokes do not necessarily require this if they won’t be forming spoke-to-spoke tunnels.
Rather than sending all spoke-to-spoke traffic through the hub, spokes can form dynamic tunnels with each other when they want to communicate. This only works if the spokes are configured with multipoint GRE tunnel interfaces.
The configuration on our routers is as follows:
hostname SITE-A ! crypto isakmp policy 10 hash md5 authentication pre-share ! crypto isakmp key cisco address 192.168.20.1 crypto isakmp key cisco address 192.168.30.1 ! crypto ipsec transform-set TRANS_SET esp-3des esp-md5-hmac ! crypto ipsec profile IPSEC_PROF set transform-set TRANS_SET ! interface Loopback0 ip address 22.214.171.124 255.255.255.255 ! interface FastEthernet0/0 ip address 192.168.10.1 255.255.255.0 no shut ! interface Tunnel0 ip address 10.0.123.1 255.255.255.0 ip nhrp authentication cisco ip nhrp map multicast dynamic ip nhrp network-id 1 tunnel source FastEthernet0/0 tunnel mode gre multipoint tunnel protection ipsec profile IPSEC_PROF ! router eigrp 10 network 126.96.36.199 0.0.0.0 network 10.0.123.0 0.0.255.255 no auto-summary ! ip route 192.168.20.0 255.255.255.0 192.168.10.2 ip route 192.168.30.0 255.255.255.0 192.168.10.2
hostname SITE-B ! crypto isakmp policy 10 hash md5 authentication pre-share crypto isakmp key cisco address 192.168.10.1 ! crypto ipsec transform-set TRANS_SET esp-3des esp-md5-hmac ! crypto ipsec profile IPSEC_PROF set transform-set TRANS_SET ! interface Loopback0 ip address 188.8.131.52 255.255.255.255 ! interface FastEthernet0/0 ip address 192.168.20.1 255.255.255.0 no shut ! interface Tunnel0 ip address 10.0.123.2 255.255.255.0 ip nhrp authentication cisco ip nhrp map 10.0.123.1 192.168.10.1 ip nhrp map multicast 192.168.10.1 ip nhrp network-id 1 ip nhrp nhs 10.0.123.1 tunnel source FastEthernet0/0 tunnel mode gre multipoint tunnel protection ipsec profile IPSEC_PROF ! router eigrp 10 network 184.108.40.206 0.0.0.0 network 10.0.123.0 0.0.0.255 no auto-summary ! ip route 192.168.10.0 255.255.255.0 192.168.20.2
hostname SITE-C ! crypto isakmp policy 10 hash md5 authentication pre-share ! crypto isakmp key cisco address 192.168.10.1 ! crypto ipsec transform-set TRANS_SET esp-3des esp-md5-hmac ! crypto ipsec profile IPSEC_PROF set transform-set TRANS_SET ! interface Loopback0 ip address 220.127.116.11 255.255.255.255 ! interface FastEthernet0/0 ip address 192.168.30.1 255.255.255.0 no shut ! interface Tunnel0 ip address 10.0.123.3 255.255.255.0 ip nhrp authentication cisco ip nhrp map 10.0.123.1 192.168.10.1 ip nhrp map multicast 192.168.10.1 ip nhrp network-id 1 ip nhrp nhs 10.0.123.1 tunnel source FastEthernet0/0 tunnel mode gre multipoint tunnel protection ipsec profile IPSEC_PROF ! router eigrp 10 network 18.104.22.168 0.0.0.0 network 10.0.123.0 0.0.0.255 no auto-summary ! ip route 192.168.10.0 255.255.255.0 192.168.30.2
I have purposely left some configuration out just for explanatory purposes later on in this article. After I pasted this configuration on my routers, the EIGRP relationships came up on the tunnel, so I know my configuration works.
I can check that the spokes can reach the hub and that this traffic is protected by the VPN tunnel. First, I will verify on SITE-B:
The reason we have such a high amount of encrypted/decrypted packets is because the EIGRP traffic is also being sent over the tunnel and is protected. Below, we see that SITE-C can also reach the hub:
Sending spoke-to-spoke traffic via the hub
If we check the routing table of the spokes, we will not see the network of the other spoke there.
However, the hub (SITE-A) knows about these networks:
Even though the hub knows about these networks via EIGRP, it will not share the information with the spokes because of the split horizon rule. Therefore, we need to disable split-horizon on the tunnel interface of the hub.
interface tunnel0 no ip split-horizon eigrp 10
Now if you check the routing tables of the spokes, you will see that not only do they have the other spoke’s network, they can also access that network.
This spoke-to-spoke traffic is actually going via the hub. I know this because Site B’s router learns about the 22.214.171.124/32 (Site C) network via 10.0.123.1, which is the tunnel interface IP address of Site A’s router. I can also confirm by checking the number of VPN tunnels are active on the spoke:
If this is what we wanted to achieve, then we didn’t even have to use multipoint GRE tunnel interfaces on the spoke routers, only on the hub.
Spoke-to-spoke communication via dynamic tunnels
Let’s now consider the usefulness of the mGRE tunnel interfaces on the spokes. To ensure that spoke-to-spoke dynamic tunnels are built, we need the hub router to leave the next-hop address of each spoke’s network unchanged when advertising it to the other spoke. The default behavior is that the hub will replace the next-hop address with its own IP address and that is why we see “10.0.123.1” as the next hop IP address above.
To achieve this, we issue the following command under the tunnel interface of Site A’s router: no ip next-hop-self eigrp 10.
Now when we check the routing table of Site B’s router, we see that the next-hop address is that of Site C’s router:
For the spokes to communicate with each other, they first need to ask the NHRP server for the public IP address of the other spoke so that they can form dynamic tunnels. For example, if Site B’s router wants to ping 126.96.36.199, it will ask its NHRP server (which we configured as Site A’s router) for the public IP address of the router at 10.0.123.3. The NHRP server will check its NHRP cache, find that the public IP address is 192.168.30.1 and then reply to the requesting spoke.
That spoke now has what it needs to form a dynamic tunnel and will attempt to form this tunnel. In our case, this tunnel will not come up because, as I said, I purposely left out some key configuration:
I only added a pre-shared key for Site A on both Site B and Site C. Each spoke does not have a pre-shared key for the other spoke.
Each spoke only has a static route for the hub, not for the other spoke.
Note: Even though the dynamic tunnel will not be formed, traffic will still get to the other spoke successfully as it will be sent via the hub.
The configuration addition on Site B’s router is as follows:
crypto isakmp key cisco address 192.168.30.1 ! ip route 192.168.30.0 255.255.255.0 192.168.20.2
The configuration to be added on Site C’s router is as follows:
crypto isakmp key cisco address 192.168.20.1 ! ip route 192.168.20.0 255.255.255.0 192.168.30.2
Now when we ping from one spoke to another, a dynamic tunnel is formed and traffic is sent over this tunnel:
You can also check the IPsec SA formed for the spoke router and see that traffic is going over that tunnel:
After a period of inactivity, the dynamic tunnel between the spokes is torn down. If you want to see the dynamic tunnel destroyed, you can reduce the NHRP holdtime value on the spokes to something short, like 60 seconds. If you don’t send anything over the tunnel after a few minutes, then the dynamic tunnel will be destroyed.
In this article, we have seen how DMVPN can be used to bridge the tunnels of two spoke sites together. In the next article, we will see how to achieve this VPN bridging on Cisco ASAs.
I hope you have found this article useful.
References and Further Reading
DMVPN Explained: http://blog.ine.com/2008/08/02/dmvpn-explained/
Configuring Dynamic Multipoint VPN (DMVPN) using GRE over IPSec between Multiple Routers: http://www.cisco.com/c/en/us/support/docs/security-vpn/ipsec-negotiation-ike-protocols/29240-dcmvpn.html