GRE vs IPSec — Tunnel Comparison

Generic Routing Encapsulation (GRE) is a tunneling protocol developed by Cisco that encapsulates a wide variety of network layer protocols inside IP tunnels. It is defined in RFC 2784 and uses IP protocol number 47. GRE creates a virtual point-to-point link between two routers, allowing them to exchange traffic as if they were directly connected. The key advantage of GRE is its ability to carry multicast and broadcast traffic, as well as non-IP protocols (e.g., IPX, AppleTalk), over an IP-only network. This makes GRE essential for routing protocols like OSPF and EIGRP that rely on multicast or broadcast for neighbor discovery.

When a router sends a packet through a GRE tunnel, it performs the following steps: 1. The router receives an original packet (e.g., an IP packet destined for a remote network). 2. It adds a GRE header (typically 4 bytes: 2 bytes for flags/version, 2 bytes for protocol type). Optionally, GRE can include a key (4 bytes) for authentication, a sequence number (4 bytes), or checksum (2 bytes). 3. The router encapsulates the entire original packet (including its header) inside a new IP header. The source IP is the tunnel source (local router's physical interface), and the destination IP is the tunnel destination (remote router's physical interface). The protocol field in the new IP header is set to 47 (GRE). 4. The resulting packet is forwarded over the physical network to the remote router. 5. The remote router strips the outer IP header and GRE header, recovers the original packet, and forwards it to the destination.

Configuring a GRE tunnel on Cisco IOS involves creating a tunnel interface and specifying the source, destination, and IP address for the tunnel itself. Here is a basic example:

interface Tunnel0
 ip address 10.0.0.1 255.255.255.252
 tunnel source GigabitEthernet0/0
 tunnel destination 192.168.1.1

This creates a tunnel between two routers. The tunnel interface gets an IP address (usually from a private subnet), and the tunnel source/destination are the actual physical interfaces. To verify the tunnel:

show interface tunnel0

Look for "Tunnel0 is up, line protocol is up". The line protocol stays up only if the tunnel destination is reachable (i.e., there is a route to the destination IP).

IP Security (IPSec) is a suite of protocols that provides confidentiality, integrity, and authentication for IP packets. It operates at the network layer (Layer 3) and can protect traffic between two hosts (transport mode) or between two gateways (tunnel mode). IPSec uses two main protocols: Authentication Header (AH, protocol 51) for integrity and authentication, and Encapsulating Security Payload (ESP, protocol 50) for confidentiality (encryption) plus optional integrity. In tunnel mode, IPSec encrypts the entire original IP packet and adds a new IP header, creating a secure tunnel.

IPSec uses a two-phase process defined by Internet Key Exchange (IKE): 1. IKE Phase 1: The two peers establish a secure, authenticated channel (ISAKMP SA). This can be done in Main Mode (6 messages, more secure) or Aggressive Mode (3 messages, faster but less secure). Default: Main Mode. The peers authenticate using pre-shared keys, digital certificates, or other methods. They also negotiate encryption algorithms (e.g., AES-256, 3DES), hash algorithms (e.g., SHA-256), Diffie-Hellman groups (e.g., Group 14), and lifetime (default 86400 seconds). 2. IKE Phase 2: The peers negotiate the IPSec Security Association (SA) parameters for the actual data encryption. This uses Quick Mode (3 messages). They agree on transform sets (e.g., esp-aes 256 esp-sha-hmac), and create two unidirectional SAs (one inbound, one outbound). The default lifetime for IPSec SAs is 3600 seconds (1 hour) or 4608000 kilobytes.

Once the SAs are established, traffic is encrypted. For example, if ESP is used in tunnel mode, the original packet is encrypted and placed inside a new IP packet with protocol 50. The receiving peer decrypts and forwards the original packet.

Here is a minimal IPSec site-to-site VPN configuration on Cisco IOS:

crypto isakmp policy 10
 authentication pre-share
 encryption aes 256
 hash sha256
 group 14
 lifetime 86400
crypto isakmp key cisco123 address 192.168.1.1
!
crypto ipsec transform-set TSET esp-aes 256 esp-sha-hmac
 mode tunnel
!
crypto map CMAP 10 ipsec-isakmp
 set peer 192.168.1.1
 set transform-set TSET
 match address 100
!
interface GigabitEthernet0/0
 crypto map CMAP
!
access-list 100 permit ip 10.0.0.0 0.255.255.255 192.168.0.0 0.0.255.255

This protects traffic between two private networks. The ACL defines interesting traffic that triggers IPSec.

GRE over IPSec combines the flexibility of GRE with the security of IPSec. The GRE tunnel is created first, then the entire GRE tunnel traffic is encrypted by IPSec. This is commonly used for DMVPN and FlexVPN. The configuration involves setting up a GRE tunnel and then applying a crypto map to the tunnel interface or the physical interface. A simpler approach is to use IPsec VTI (Virtual Tunnel Interface), which integrates IPSec directly on the tunnel interface without a separate crypto map.

In enterprise networks, GRE tunnels are often used to connect remote branches that run routing protocols like OSPF or EIGRP over a WAN. For example, a company with multiple sites might use GRE tunnels to form a full mesh of virtual point-to-point links, allowing dynamic routing across the MPLS cloud. However, since GRE provides no encryption, traffic is sent in clear text—a major security risk. This is where IPSec comes in. A common design is 'GRE over IPSec': the GRE tunnel carries routing protocol updates and multicast traffic, and IPSec encrypts the entire GRE stream. Cisco's Dynamic Multipoint VPN (DMVPN) is a classic implementation: it uses mGRE (multipoint GRE) for dynamic tunnel establishment and IPSec for encryption. Network engineers deploy this when they need scalable, secure site-to-site connectivity without a full mesh of static tunnels. Performance considerations: GRE adds 24 bytes of overhead (20 IP + 4 GRE), and IPSec adds more (typically 50-60 bytes for ESP in tunnel mode). This can impact MTU, so engineers often lower the tunnel MTU or enable TCP MSS clamping. Misconfiguration is common: forgetting to add routes for the tunnel destination, mismatched pre-shared keys, or ACLs that don't match the correct traffic. In production, you might see 'show crypto isakmp sa' showing MM_NO_STATE, indicating Phase 1 failure. Another scenario: using IPSec alone without GRE—this works for unicast IP traffic but breaks routing protocols that rely on multicast (e.g., OSPF hello packets are dropped). Therefore, for dynamic routing over VPNs, GRE over IPSec or VTI is essential. On the CCNA exam, you may be asked to identify why OSPF neighbors fail over an IPSec-only VPN—the answer is that IPSec does not forward multicast traffic.