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

GRE over IPsec tunnels (Part 1)

Why a IPsec over a GRE tunnel? A couple of things come to mind. Things like encryption of tunneled traffic and the possibility to send multicast traffic over the tunnel.

GRE on itself only tunnels traffic by encsapsulating the traffic within an additional GRE and IP header. But if you Wireshark the traffic it’s just plain text and therefore readable. In a plain IPsec tunnel it is not possible to send multicast traffic over the IPsec tunnel. But if you’re using OSPF or EIGRP you need to be able to send multicast traffic over the IPsec tunnel.

To prove the above I created a case study. First I will show how to configure a normal GRE tunnel, after that a GRE over IPsec tunnel with static routes. In a separate post I will write about GRE over IPsec tunnel with dynamic routing.

So for this case study I used the topology as shown below.

GRE_over_IPsec

Below the configuration of the HQ router, the branch router is the same but use different IP addresses.

First configure the physical internet facing interface, the vlan interface for the internal subnet and the needed routes.

!
interface FastEthernet1/0
ip address 109.232.100.1 255.255.255.0
duplex auto
speed auto
!
!
interface Vlan10
ip address 10.10.10.1 255.255.255.0
!
ip route 10.10.11.0 255.255.255.0 172.18.2.1
!

Then create the tunnel interface

!
interface Tunnel0
ip address 172.18.2.2 255.255.255.0
ip mtu 1400
tunnel source FastEthernet1/0
tunnel destination 109.232.100.2
!
Don’t forget to change the MTU size to 1400, because of the overhead created by the GRE encapsulation.

Now it’s possible to ping from PC1 at HQ to PC3 at the bracnch office. If you look at the traffic you will see it’s encapsulated in a GRE packet, but there is no encryption:
GRE_capture

To create an IPsec connection do the following on the HQ and Branch routers:
!
crypto isakmp policy 1
authentication pre-share
crypto isakmp key sjiekismiechdat address 109.232.100.2
!
!
crypto ipsec transform-set test esp-3des esp-md5-hmac
!
!
access-list 101 permit gre host 109.232.100.1 host 109.232.100.2
!
!
crypto map s-2-s 10 ipsec-isakmp
set peer 109.232.100.2
set transform-set test
match address 101
!
!
interface Tunnel0
crypto map s-2-s
!
!
interface FastEthernet1/0
crypto map s-2-s
!

Now send some traffic from PC1 to PC3 and use the “show crypto session” command to verify that the GRE over IPsec connection is established:
crypto_session

Now we know the tunnel is up and it’s possible to exchange traffic between PC1 at the HQ and PC3 at the branch office. Now let’s look at the traffic with Wireshark.
ESP

As you can see there are only ESP packets, in other words the encryption of the IPsec tunnel is working.

In my next post I will talk about dynamic routing with GRE over IPsec.