GRE over IPsec tunnels (Part 2)

In my last post I wrote about GRE over IPsec, but only with static routes. One of the benefits of GRE over IPsec tunnels is that you can send multicast traffic  over the tunnel. With a plain IPsec tunnel this is not possible. So to prove that multicast traffic can cross the GRE over IPsec tunnel I took the topology of my last post and removed the static routes from the configuration of the HQ and Branch routers.
Below the used topology:
GRE_over_IPsec

Then configure the EIGRP configuration on both routers.

R1#sh run | se eigrp
router eigrp 10
network 10.10.10.0 0.0.0.255
network 172.18.2.0 0.0.0.255
no auto-summary
R1#

The syslog below confirms that the EIGRP adjacency is up and running:
EIGRP_adj

Then use the “debug ip packet detail” command to verify that multicast is used and allowed:
EIGRP_multicast

To prove the solution is working check the routing table.
sh_ip_route

And that’s all there to configure dynamic routing over a GRE over IPsec tunnel.

Advertisements

DMVPN

One of the parts of my CCIE study is DMVPN’s. With this technique it’s very easy to built full meshed VPN networks without the need to connect every (branch) office physically with each other. DMVPN’s are built in a hub and spoke manner. Between the hub and the spoke tunnels (VPN’s) are built for connectivity. It’s also possible to connect a branch to a branch, without sendig all the traffic to the Hub, but directly to the spoke site.
To make all of this happen, DMVPN’s use a technique which is called NHRP.

NHRP*
In a computer network, the Next Hop Resolution Protocol (NHRP) is a protocol or method that can be used so that a computer sending data to another computer can learn the most direct route (the fewest number of hops to the receiving computer. If the receiving computer is in the same subnetwork, the use of NHRP will tell the sending computer that the receiving computer is local and it can send subsequent data packets directly to the receiving computer using its subnetwork address rather than its global network address. If the receiving computer is not in the same subnetwork, the use of NHRP will tell the sending computer the computer in the subnetwork whose router provides the most direct path to the receiving computer and the sender can now forward subsequent data packets to that router. In a way NHRP functions almost as a DNS server.

In the picture below the topology I used for this case study. The internetcloud is in my GNS3 configuration a router which routes the used subnets.

DMVPN

 

First configure the DMVPN hub, in my case this is router R1. I think configuring the local and external addresses a pretty forward, so I will only show the tunnel configuration.

R1 Tunnel0
!
interface Tunnel0
ip address 10.0.0.1 255.255.255.0
no ip redirects
ip nhrp authentication DMVPN
ip nhrp network-id 1
tunnel source FastEthernet1/0
tunnel mode gre multipoint
tunnel protection ipsec profile MGRE
!

As can be seen in the above configuration there is no tunnel destination configured. Instead of this the tunnel mode is configured as “tunnel mode gre multipoint”. With this configuration it is possible to connect several branches (spokes) to the same interface.

To connect a spoke to the hub location the following configuration is necessary on the spoke router.

R2
!
interface Tunnel0
ip address 10.0.0.2 255.255.255.0
no ip redirects
ip nhrp authentication DMVPN
ip nhrp map 10.0.0.1 201.1.1.1
ip nhrp network-id 1
ip nhrp nhs 10.0.0.1
tunnel source FastEthernet1/0
tunnel mode gre multipoint
tunnel protection ipsec profile MGRE
!

To connect a branch office to the hub location, you have to point the tunnel to the tunnel and external address of the hub location.

To check if the connection succeeded, use the “show dmvpn” command on the hub and spoke router.

R1
show_dmvpn_R1

R2
show_dmvpn_R2

As can be seen there is DMVPN connectivity between the hub and the spoke router. Only the traffic is not encrypted yet. For that we have to configure a crypto IPSEC profile. This can be done as below, I will not discuss this part of the configuration. For this I will write a seperate blogpost.

Configure on router R1
!
crypto isakmp policy 1
encr aes
hash md5
authentication pre-share
group 2
crypto isakmp key HEGGEL address 0.0.0.0 0.0.0.0
!
!
crypto ipsec transform-set MYSET esp-aes esp-md5-hmac
!
crypto ipsec profile MGRE
set security-association lifetime seconds 86400
set transform-set MYSET
!

Configure on router R2
!
crypto isakmp policy 1
encr aes
hash md5
authentication pre-share
group 2
crypto isakmp key HEGGEL address 0.0.0.0 0.0.0.0
!
!
crypto ipsec transform-set MYSET esp-aes esp-md5-hmac
!
crypto ipsec profile MGRE
set security-association lifetime seconds 86400
set transform-set MYSET
!

Now the traffic between hub and spoke are encrypted. To check this, you can make use of wireshark. I will ping the 10.10.10.254 interface of router R1 with a source address of 192.168.1.254.

wireshark_encr

When you open one of these packets you can see that ESP is used to encypt the packet

ESP

ESP*
Encapsulating Security Payload (ESP) is a member of the IPsec protocol suite. In IPsec it provides origin authenticity, integrity and confidentiality protection of packtes. ESP also supports encryption-only and authentication-only configurations, but using encryption without authentication is strongly discouraged because it is insecure. Unlike AH, ESP in transport mode does not provide integrity and authentication for the entire IP packet. However, in Tunnel mode, where the entire original IP packet is encapsulated with a new packet header added, ESP protection is afforded to the whole inner IP packet (including the inner header) while the outer header (including any outer IPv4 options or IPv6 extension headers) remains unprotected. ESP operates directly on top of IP, using IP protocol number 50.

To create a spoke-to-spoke connection, let’s say between R2 and R4, only the routes necessary have to be configured on R2 and R4. In a large scale full mesh network it’s easier to use a dynamic routing protocol. But in my example I want to show it’s also possible to connect only two spoke’s instead of a totally meshed network.

Configure on R2 the route to the LAN of R4
!
ip route 192.168.2.0 255.255.255.0 10.0.0.4
!

Configure on R4 the route to the LAN of R2
!
ip route 172.18.1.o 255.255.255.0 10.0.0.2
!

If you use the “show dmvpn” command on R2 and R4, there is an extra tunnel built between spoke routers R2 and R4.

R2
show_dmvpn_R2_HS

R4
show_dmvpn_R4_HS

As can be seen in the picture above, the tunnel between R2 and R4 is a dynamic tunnel. If you remove the previously created routes, the tunnel will be terminated.

 

 

*Source is http://www.cisco.com