In this section, we will discuss securing your data while transmitting through a GRE tunnel. If you are unfamiliar with GRE tunnels, please take the time to read this post here first. We will use the same topology as the one used in the GRE post. We will just add encryption on top.

It is important to note that the configuration of a plain functional GRE tunnel does not include any encryption whatsoever. In order to secure data passing through a GRE tunnel, we will need to encrypt the traffic by configuring IPSec on top. It is only then, that your GRE tunnel is now secured.

Also note that GRE tunnel are different from Point-to-Point IPSec VPN tunnel. One of the major difference is that GRE allows multicast packets to flow through the tunnel and IPSec VPN tunnel does not. So you can already guess that if you would like to run IGPs to a remote location which needs to peer via a VPN tunnel, then GRE is your best bet.

Let’s dive into the consoles and secure our GRE tunnel. At this point, the tunnel is fully functional and we can ping across. Let’s test from RouteLeak-HQ perspective…

Let’s now securing the tunnel starting with RouteLeak-HQ. Note that there are 2 steps we would need to undergo.
*We would primarily need to configure a ISAKMP policy which is PHASE 1
*Then we would need to configure a IPSec profile and tie it with the ISAKMP policy

Let’s start with Phase 1 on RouteLeak-HQ…

Here we initially defined the isakmp policy then moved on to set the Phase 1 parameters.

-We set the encryption to be AES which  is an advanced encryption standard
-Then we set the hash to md5 (Message Digest 5)
-Then we set the authentication method to use pre-shared key
-We set the group to be used as Diffie-Hellman group 2
-Then we set the session key lifetime to 86400sec (Which is default by the way)

Our next step is to define a pre-shared key for authentication purposes…

Here, we used “RouteLeak-Key” as our pre-shared key and note that you have to specify the remote WAN interface address for all ISAKMP negotiation. Noticed how we needed to get out of the ISAKMP policy mode first ? Also, note that if you were in a scenario where you needed to peer with multiple tunnel endpoints such as in a DMVPN environment, you can use “0.0.0.0” on the hub router when defining your pre-shared key and endpoints addresses.

Let’s now move on to Phase 2…

We need to create a Transform Set for our data protection…

Noticed here how we chose RouteLeak-TS as our Transform Set tag ? We then went ahead and chose esp-aes as our encryption method and md5 as our hashing algorithm.

We need now to set the transform mode…

We just set the IPSec mode to transport. Ok good ! Let’s now create the IPSec profile…

Noticed how we created a IPSec profile and tied the Transform Set to it ? The last step is to apply the IPSec encryption to the GRE tunnel…

The same configuration needs to be applied at the other end of the tunnel except for the peer address. Let’s do that…

All right ! We should be set, let’s generate some traffic and run a quick sanity check…

Let’s now check RouteLeak-HQ while this is running…

The command “show crypto isakmp sa” displays the ISAKMP Secuity Associations between the peers. We can see our peer here and the status is ACTIVE. This is looking good. Let’s check IPSec…

The command “show crypto ipsec sa” displays the IPSec Secuity Associations between the peers. Notice the number of encrypted and decrypted packets which increases as more traffic passes through.

That completes this topic… I’ll talk to you guys later.