GRE over IPsec Tunnel Configuration

1. The Best of Both Worlds: Why Combine GRE and IPsec?

To understand why we combine these two technologies, let's first look at what each one does well and where it falls short.

• Generic Routing Encapsulation (GRE): GRE is a tunneling protocol developed by Cisco. Its primary strength is its incredible flexibility. It can encapsulate a wide variety of network layer protocols inside IP tunnels. Crucially for us, it can carry multicast and broadcast traffic. This is essential for dynamic routing protocols like EIGRP and OSPF, which use multicast to discover neighbors and exchange updates.

  • The Downside: GRE provides zero encryption. All traffic inside a GRE tunnel is sent in cleartext, making it completely insecure for transport over the internet.

• IPsec (Internet Protocol Security): As we learned in the last lesson, IPsec is a robust framework that provides strong confidentiality (encryption), integrity, and authentication.

  • The Downside: Standard IPsec can only protect unicast IP packets. It cannot natively transport the multicast traffic required by most routing protocols.

This presents a dilemma: we want the routing flexibility of GRE but the robust security of IPsec. The solution is to use them together in a specific order: GRE over IPsec.

The logic is simple:

1. We first take our original traffic—including the multicast packets from our routing protocol—and encapsulate it inside a GRE packet. A GRE packet itself is a standard unicast IP packet.
2. We then take this GRE packet and protect it using IPsec.

This two-step process allows us to securely transport any traffic that GRE can carry.

This layered encapsulation results in a packet structure like the one below. Notice how the original IP packet is wrapped first by GRE, and then the entire GRE packet is encrypted and wrapped by IPsec (ESP).

2. Configuration: From Crypto Maps to IPsec Profiles

In our previous lesson, we applied a crypto map to a physical, public-facing interface. For GRE over IPsec, we use a more modern and elegant method: an IPsec Profile applied directly to the virtual tunnel interface.

Here's a comparison:

We will now walk through the configuration for the topology shown below. We'll build a secure GRE tunnel between R1 and R3.

The configuration process follows these logical steps:

1. Configure the basic (unsecured) GRE tunnel.
2. Configure the IKEv2 and IPsec security parameters.
3. Create an IPsec Profile to bundle the security parameters.
4. Apply the profile to the GRE tunnel interface to secure it.

For a detailed guide with command-line examples, we'll use an article from "sendthepayload.com" that clearly outlines this modern approach.

Let's break down the configuration, combining the concepts from the article with Cisco's official syntax.

Step 1: Configure the Unsecured GRE Tunnel

First, we establish a standard GRE tunnel between the two routers. At this point, the tunnel is functional but completely insecure.

On Router R1:

! Create the virtual tunnel interface
interface Tunnel0
 ! The tunnel interface's own IP address
 ip address 172.16.0.1 255.255.255.252
 ! The public IP of this router
 tunnel source GigabitEthernet0/1
 ! The public IP of the remote router (R3)
 tunnel destination 22.22.22.6

On Router R3:

! Create the virtual tunnel interface
interface Tunnel0
 ! The tunnel interface's own IP address
 ip address 172.16.0.2 255.255.255.252
 ! The public IP of this router
 tunnel source GigabitEthernet0/2
 ! The public IP of the remote router (R1)
 tunnel destination 11.11.11.5

After this, you should be able to ping the remote tunnel IP address (e.g., from R1, ping 172.16.0.2).

Step 2: Configure IKEv2 and IPsec Parameters

This part is very similar to our last lesson, defining the security policies for IKE Phase 1 and IPsec Phase 2.

! === IKEv2 Configuration (Phase 1) ===

! Define the IKEv2 Proposal (encryption, integrity, DH group)
crypto ikev2 proposal GRE-PROP
 encryption aes-cbc-256
 integrity sha256
 group 19

! Define the IKEv2 Policy and attach the proposal
crypto ikev2 policy GRE-POL
 proposal GRE-PROP

! Define the pre-shared key for authentication
crypto ikev2 keyring GRE-KEYRING
 peer R3
  address 22.22.22.6
  pre-shared-key MyCcnpSecretKey
 !
!
 peer R1
  address 11.11.11.5
  pre-shared-key MyCcnpSecretKey
 !

! Create the main IKEv2 Profile to bind everything together
crypto ikev2 profile GRE-PROFILE
 match identity remote address 22.22.22.6
 identity local address 11.11.11.5
 authentication remote pre-share
 authentication local pre-share
 keyring local GRE-KEYRING

! === IPsec Configuration (Phase 2) ===

! Define the IPsec Transform Set (data protection policy)
crypto ipsec transform-set GRE-TSET
 esp-aes 256 esp-sha-hmac
 ! For GRE over IPsec, transport mode is more efficient
 mode transport

A Note on Transport Mode: When securing a GRE tunnel, we use IPsec's transport mode. Why? The GRE encapsulation has already created a "tunnel" with new source and destination IPs. Using IPsec's tunnel mode on top of that would add a redundant, second outer IP header. Transport mode avoids this extra overhead by inserting the ESP header between the GRE outer IP header and the GRE payload, making the process more efficient.

Step 3: Create and Apply the IPsec Profile

Now we create the final object, the IPsec profile, which ties our Phase 2 transform set and Phase 1 IKEv2 profile together. We then apply this single profile to our GRE tunnel interface.

! Create the IPsec Profile
crypto ipsec profile GRE-IPSEC-PROFILE
 ! Set the Phase 2 transform set
 set transform-set GRE-TSET
 ! Set the Phase 1 IKEv2 profile
 set ikev2-profile GRE-PROFILE

! Apply the profile to the GRE tunnel interface
interface Tunnel0
 tunnel protection ipsec profile GRE-IPSEC-PROFILE

As soon as you apply this command on both routers, the IKEv2 negotiation will begin, and the tunnel will be secured.

For a full, end-to-end video demonstration of this configuration flow, the following resource is excellent.

3. Verification

Once the tunnel is configured and traffic is flowing (e.g., from a ping or a routing protocol update), you can verify its status with a few key commands.

• show crypto ikev2 sa: Verifies the IKE Phase 1 tunnel. The status should be READY.
• show crypto ipsec sa: Verifies the IKE Phase 2 tunnel. You should see increasing packet counts for #pkts encaps (outbound) and #pkts decaps (inbound). This is your primary confirmation that traffic is being encrypted.
• show interface Tunnel0: The output will now include a line confirming that the tunnel is protected by your IPsec profile.

Example output from show interface Tunnel0:

R1# show interface Tunnel0
Tunnel0 is up, line protocol is up
  ...
  Tunnel protocol/transport GRE/IP
  Tunnel protection via IPsec profile "GRE-IPSEC-PROFILE"

Conclusion

Congratulations! You have now learned how to configure a scalable, dynamic, and secure site-to-site VPN. This route-based approach is far more powerful than static crypto maps and is a fundamental building block for more advanced WAN designs.

Key Takeaways:

• GRE + IPsec = Flexible Security: GRE provides the flexibility to run dynamic routing protocols, while IPsec provides the necessary encryption.
• Encapsulation Order Matters: Traffic is first encapsulated by GRE, and the resulting GRE packet is then encrypted by IPsec.
• IPsec Profiles are Modern: Applying an ipsec profile to a tunnel interface is the modern, route-based method for securing tunnels. It is simpler and more scalable than using crypto map on a physical interface.
• Use Transport Mode: For GRE over IPsec, IPsec's transport mode is more efficient as it avoids redundant IP headers.

Preview of the Next Lesson:

The point-to-point GRE tunnel we built today is powerful, but what if you have a central hub and dozens or hundreds of spoke sites? Configuring a separate tunnel to each spoke would be a management nightmare. In our next lesson, we will solve this problem by exploring DMVPN (Dynamic Multipoint VPN). We'll see how DMVPN builds upon the GRE and IPsec concepts from today, using technologies like mGRE and NHRP to create a dynamic, scalable VPN solution.