Loading learning content...
When Cisco engineers developed Generic Routing Encapsulation (GRE) in the late 1990s, they created what would become one of the most versatile and widely deployed tunneling protocols in networking history. The genius of GRE lies in its name—it is genuinely generic. Unlike purpose-built tunneling protocols that handle only specific traffic types, GRE can encapsulate virtually any network layer protocol, making it the Swiss Army knife of tunneling.
GRE's elegance comes from its simplicity. It adds minimal overhead to packets, requires no complex negotiation or key exchange, and integrates seamlessly with existing IP infrastructure. This simplicity has made GRE the foundation for countless network designs, from basic site-to-site connections to sophisticated multicast-enabled overlay networks.
By the end of this page, you will understand: the GRE protocol architecture and header format; how GRE achieves protocol-independence through its Protocol Type field; optional GRE features including checksums, keys, and sequence numbers; GRE configuration on enterprise routers; multicast and routing protocol support over GRE; and GRE's security limitations and how to address them.
Generic Routing Encapsulation (GRE) is a tunneling protocol developed by Cisco and standardized in RFC 2784 (and RFC 2890 for extensions). It provides a mechanism for encapsulating packets of one protocol inside the payload of another protocol, enabling the creation of point-to-point virtual links across IP networks.
Defining characteristics of GRE:
1. Protocol Independence GRE can encapsulate nearly any network layer protocol—IPv4, IPv6, CLNP, IPX, AppleTalk—making it truly generic. The encapsulated protocol is identified by a Protocol Type field in the GRE header.
2. Stateless Operation GRE tunnels are stateless. There is no connection establishment phase, no keepalive negotiation (though keepalives can be added), and no teardown. Packets are simply encapsulated and transmitted.
3. Minimal Overhead The basic GRE header is only 4 bytes. With all optional fields enabled, it can grow to 16 bytes, but typical deployments use 4-8 bytes of overhead.
4. IP Protocol Number 47 GRE is assigned IP protocol number 47. When an IP packet carries a GRE payload, its protocol field is set to 47, signaling that the payload should be processed as a GRE header followed by the encapsulated packet.
| Attribute | Value | Notes |
|---|---|---|
| IP Protocol Number | 47 | Identifies GRE payload in outer IP header |
| Standardization | RFC 2784, RFC 2890 | Base protocol and extensions |
| Minimum Header Size | 4 bytes | Basic header without optional fields |
| Maximum Header Size | 16 bytes | All optional fields present |
| Encryption Support | None | GRE provides no native encryption |
| Authentication | None | GRE provides no native authentication |
| Multicast Support | Yes | GRE supports multicast traffic natively |
GRE was originally specified in RFC 1701 and 1702 (1994), which defined a more feature-rich but complex protocol. RFC 2784 (2000) simplified GRE significantly, deprecating rarely-used features. RFC 2890 (2000) reintroduced optional key and sequence number fields. Modern implementations follow RFC 2784/2890.
The GRE header sits between the outer IP header and the encapsulated (inner) packet. Understanding its structure is essential for packet analysis, troubleshooting, and advanced configuration.
GRE HEADER FORMAT (RFC 2784 / RFC 2890)═══════════════════════════════════════════════════════════════════════════ BASIC GRE HEADER (4 bytes - always present)─────────────────────────────────────────── 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1├─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┤│C│ Rsvd0 │ Ver │ Protocol Type │├─┴───────┴─────┴───────────────────────────────────────────────┤ Bit 0: C = Checksum Present (1 = checksum and reserved fields present) Bits 1-12: Reserved (must be 0) Bits 13-15: Version (0 for GRE) Bits 16-31: Protocol Type (Ethertype of encapsulated protocol) EXTENDED GRE HEADER (with optional fields)────────────────────────────────────────── 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1├─┼─┼─┼─┼─┼───────┼─────┼───────────────────────────────────────┤│C│ Rsvd0 │K│S│ Rsvd0 │ Ver │ Protocol Type │├─┴───────┴─┴─┴───────┴─────┴───────────────────────────────────┤│ Checksum (optional) │ Reserved1 (opt) │├─────────────────────────────────────────┴─────────────────────┤│ Key (optional, 4 bytes) │├───────────────────────────────────────────────────────────────┤│ Sequence Number (optional, 4 bytes) │├───────────────────────────────────────────────────────────────┤│ ││ Encapsulated Payload (variable length) ││ │└───────────────────────────────────────────────────────────────┘ FIELD DESCRIPTIONS:─────────────────── C (Checksum Present) - Bit 0: 0 = Checksum and Reserved1 fields not present 1 = Checksum (2 bytes) and Reserved1 (2 bytes) fields present K (Key Present) - Bit 2 (RFC 2890): 0 = Key field not present 1 = Key field (4 bytes) present for tunnel identification S (Sequence Number Present) - Bit 3 (RFC 2890): 0 = Sequence Number field not present 1 = Sequence Number field (4 bytes) present for ordering Version - Bits 13-15: 000 = Standard GRE (RFC 2784/2890) 001 = PPTP enhanced GRE (RFC 2637) Protocol Type - Bits 16-31: Ethertype of the encapsulated protocol 0x0800 = IPv4 0x86DD = IPv6 0x6558 = Transparent Ethernet Bridging (L2 over GRE) 0x0806 = ARP 0x8847 = MPLS unicast 0x8035 = RARPHeader field deep dive:
Protocol Type (16 bits) This is the most important field in the GRE header. It uses standard Ethertype values to identify the encapsulated protocol, enabling GRE's protocol independence. Common values:
Checksum (optional, 16 bits) When present (C bit = 1), the checksum covers the GRE header and the encapsulated payload. It enables detection of corruption during transit. However, since IP already has a header checksum and most transport protocols (TCP, UDP) have checksums, the GRE checksum is often omitted.
Key (optional, 32 bits) The key field serves two purposes:
Sequence Number (optional, 32 bits) Used for packet ordering and detecting out-of-order delivery. Some applications require in-order delivery; the sequence number allows the receiver to reorder packets or detect gaps.
Despite its name, the GRE key field provides no real security. It is transmitted in plaintext and easily observed by anyone capturing traffic. The key is useful for tunnel demultiplexing but should never be relied upon for authentication or access control. For secure tunneling, GRE must be combined with IPSec.
A complete GRE tunnel packet consists of multiple nested layers. Understanding this structure is crucial for packet analysis, MTU calculations, and troubleshooting.
COMPLETE GRE TUNNEL PACKET STRUCTURE═══════════════════════════════════════════════════════════════════════════ Minimum With All Options ──────── ────────────────┌───────────────────────────┐│ OUTER IP HEADER │ 20 bytes 20 bytes (+options)│ ┌─────────────────────┐ ││ │ Version: 4 │ ││ │ IHL: 5 (20 bytes) │ ││ │ Total Length: X │ ││ │ Protocol: 47 (GRE) │ ││ │ Source: Tunnel Src │ ││ │ Dest: Tunnel Dst │ ││ └─────────────────────┘ │├───────────────────────────┤│ GRE HEADER │ 4 bytes 16 bytes (max)│ ┌─────────────────────┐ ││ │ C|K|S|Rsv|Ver|Proto │ ││ │ [Checksum|Reserved] │ │ (if C=1: +4 bytes)│ │ [Key] │ │ (if K=1: +4 bytes)│ │ [Sequence Number] │ │ (if S=1: +4 bytes)│ └─────────────────────┘ │├───────────────────────────┤│ INNER (ORIGINAL) IP │ 20 bytes 20 bytes (+options)│ ┌─────────────────────┐ ││ │ Version: 4 or 6 │ ││ │ Source: Original Src│ ││ │ Dest: Original Dst │ ││ │ Protocol: TCP/UDP...│ ││ └─────────────────────┘ │├───────────────────────────┤│ TRANSPORT HEADER │ 20 bytes 60 bytes (TCP w/opts)│ (TCP/UDP/ICMP/etc.) │├───────────────────────────┤│ ││ APPLICATION PAYLOAD │ Variable│ │└───────────────────────────┘ OVERHEAD CALCULATION:──────────────────── Minimum GRE Overhead: Outer IP Header: 20 bytes GRE Header: 4 bytes ──────────────────────────── Total Minimum: 24 bytes Maximum GRE Overhead (all options): Outer IP Header: 20 bytes (60 with IP options) GRE Header: 16 bytes (C, K, S all set) ──────────────────────────── Total Maximum: 36 bytes (76 with IP options) Typical GRE Overhead: Most deployments: 24-28 bytes (basic or with key) EXAMPLE MTU IMPACT:────────────────── Standard Ethernet MTU: 1500 bytes Minus minimum GRE overhead: - 24 bytes ──────────────────────────────────────────── Maximum inner packet: 1476 bytes If running OSPF over GRE with IP options: Standard Ethernet MTU: 1500 bytes Minus typical GRE overhead: - 28 bytes Minus IP options (if any): - 40 bytes ──────────────────────────────────────────── Maximum inner packet: 1432 bytesKey observations about packet structure:
1. Double IP Headers GRE IPv4-in-IPv4 tunnels have two complete IP headers—the outer header for tunnel transport and the inner header containing the original addressing. This redundancy enables the virtual link abstraction.
2. TTL Handling The outer TTL is set by the ingress endpoint (typically to a default value or copied from the inner packet). The inner TTL is decremented only at true routing hops—the tunnel counts as one hop, not many.
3. ToS/DSCP Copying Many implementations copy the Type of Service (ToS) or Differentiated Services Code Point (DSCP) from the inner header to the outer header. This preserves QoS marking through the tunnel.
4. Fragmentation Considerations If the complete GRE packet exceeds the path MTU, fragmentation is required. Best practice is to fragment before encapsulation (pre-fragmentation) rather than after (post-fragmentation), as many paths drop fragments.
Configure the tunnel interface MTU lower than the physical path MTU minus GRE overhead. For a 1500-byte path MTU with 24-byte GRE overhead, set the tunnel MTU to 1476 bytes or less. This causes TCP MSS negotiation to reduce segment sizes, avoiding fragmentation entirely.
GRE tunnels are configured on network devices through tunnel interface creation and parameter specification. The configuration defines tunnel endpoints, addressing, and optional features.
1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980
! ═══════════════════════════════════════════════════════════════════! GRE TUNNEL CONFIGURATION - CISCO IOS! ═══════════════════════════════════════════════════════════════════ ! ─────────────────────────────────────────────────────────────────! SITE A CONFIGURATION (Router A)! ───────────────────────────────────────────────────────────────── ! Step 1: Configure the physical interfaceinterface GigabitEthernet0/0 description WAN Interface to Internet ip address 203.0.113.1 255.255.255.252 no shutdown ! Step 2: Configure the LAN interface interface GigabitEthernet0/1 description Site A LAN ip address 10.1.0.1 255.255.255.0 no shutdown ! Step 3: Create and configure the GRE tunnel interfaceinterface Tunnel0 description GRE Tunnel to Site B ! Assign IP address to tunnel interface (virtual link) ip address 172.16.0.1 255.255.255.252 ! Set tunnel MTU to prevent fragmentation (Path MTU - GRE overhead) ip mtu 1476 ! Adjust TCP MSS to prevent oversized segments ip tcp adjust-mss 1436 ! Define tunnel source (local endpoint) tunnel source GigabitEthernet0/0 ! Alternative: tunnel source 203.0.113.1 ! Define tunnel destination (remote endpoint) tunnel destination 198.51.100.1 ! Specify tunnel mode as GRE over IPv4 (default) tunnel mode gre ip ! Optional: Enable GRE keepalives keepalive 10 3 ! Optional: Add tunnel key for identification tunnel key 12345 no shutdown ! Step 4: Add routing for remote networkip route 10.2.0.0 255.255.255.0 172.16.0.2 ! ─────────────────────────────────────────────────────────────────! SITE B CONFIGURATION (Router B)! ───────────────────────────────────────────────────────────────── interface GigabitEthernet0/0 description WAN Interface to Internet ip address 198.51.100.1 255.255.255.252 no shutdown interface GigabitEthernet0/1 description Site B LAN ip address 10.2.0.1 255.255.255.0 no shutdown interface Tunnel0 description GRE Tunnel to Site A ip address 172.16.0.2 255.255.255.252 ip mtu 1476 ip tcp adjust-mss 1436 tunnel source GigabitEthernet0/0 tunnel destination 203.0.113.1 tunnel mode gre ip keepalive 10 3 tunnel key 12345 no shutdown ip route 10.1.0.0 255.255.255.0 172.16.0.1Configuration breakdown:
Tunnel Source The local endpoint address. This can be specified directly as an IP address or as an interface name (the interface's primary IP will be used). Using an interface name is preferred—if the interface IP changes, the tunnel adapts automatically.
Tunnel Destination The remote endpoint address. Unlike the source, this must be a reachable IP address, not an interface name. The tunnel will only operate when a route to this destination exists.
Tunnel Mode
Specifies the encapsulation type. For IPv4-in-IPv4 GRE: gre ip. For IPv6-in-IPv4 GRE: gre ipv6. For multipoint GRE: gre multipoint.
Keepalives
Optional periodic messages that verify tunnel reachability. The syntax keepalive 10 3 means: send keepalives every 10 seconds, and if 3 consecutive keepalives fail (30 seconds total), mark the tunnel as down.
Tunnel Key When multiple tunnels exist between the same endpoints, the key differentiates them. Both ends must have matching keys.
A critical configuration error is creating a recursive routing loop. If the route to the tunnel destination points through the tunnel interface itself, packets will loop infinitely. Always ensure the tunnel destination is reachable via a physical interface, not the tunnel. Use specific static routes or ensure dynamic routing doesn't advertise tunnel destinations across the tunnel.
One of GRE's most powerful capabilities is its support for multicast traffic, enabling dynamic routing protocols to operate over the tunnel. Unlike IPSec in native mode (which only supports unicast), GRE can carry OSPF Hello packets, EIGRP multicasts, and other routing protocol traffic.
Why routing protocols over GRE matters:
Dynamic routing protocols provide:
Without multicast support, each site would require static routes—manageable for a few sites but exponentially complex as networks scale.
RUNNING OSPF OVER GRE TUNNELS═══════════════════════════════════════════════════════════════════════════ NETWORK TOPOLOGY:───────────────── Site A Site B ┌──────────┐ ┌─────────────────────────┐ ┌──────────┐ │ 10.1.0.0 │ │ GRE Tunnel (OSPF) │ │ 10.2.0.0 │ │ /24 ├──────│ 172.16.0.1 ◄──────────► │──────┤ /24 │ │ (Area 0) │ │ 172.16.0.2 │ │ (Area 0) │ └──────────┘ └─────────────────────────┘ └──────────┘ SITE A CONFIGURATION:──────────────────── interface Tunnel0 description GRE Tunnel to Site B with OSPF ip address 172.16.0.1 255.255.255.252 ip ospf network point-to-point ip ospf hello-interval 10 ip ospf dead-interval 40 ip mtu 1476 tunnel source GigabitEthernet0/0 tunnel destination 198.51.100.1 tunnel mode gre ip interface GigabitEthernet0/1 ip address 10.1.0.1 255.255.255.0 router ospf 1 router-id 1.1.1.1 network 10.1.0.0 0.0.0.255 area 0 network 172.16.0.0 0.0.0.3 area 0 SITE B CONFIGURATION:──────────────────── interface Tunnel0 description GRE Tunnel to Site A with OSPF ip address 172.16.0.2 255.255.255.252 ip ospf network point-to-point ip ospf hello-interval 10 ip ospf dead-interval 40 ip mtu 1476 tunnel source GigabitEthernet0/0 tunnel destination 203.0.113.1 tunnel mode gre ip interface GigabitEthernet0/1 ip address 10.2.0.1 255.255.255.0 router ospf 1 router-id 2.2.2.2 network 10.2.0.0 0.0.0.255 area 0 network 172.16.0.0 0.0.0.3 area 0 VERIFICATION COMMANDS:───────────────────── Router-A# show ip ospf neighborNeighbor ID Pri State Dead Time Address Interface2.2.2.2 0 FULL/ - 00:00:33 172.16.0.2 Tunnel0 Router-A# show ip route ospf 10.0.0.0/24 is subnetted, 2 subnetsO 10.2.0.0 [110/1001] via 172.16.0.2, 00:15:23, Tunnel0 Router-A# show ip ospf interface tunnel0Tunnel0 is up, line protocol is up Internet Address 172.16.0.1/30, Area 0 Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost: 1000 Transmit Delay is 1 sec, State POINT_TO_POINT Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:04 Neighbor Count is 1, Adjacent neighbor count is 1 Adjacent with neighbor 2.2.2.2Key considerations for routing over GRE:
1. Network Type
Configure the tunnel as OSPF network type point-to-point. This eliminates DR/BDR election overhead and treats the tunnel as a simple point-to-point link.
2. MTU Matching
Both ends must have matching MTU configurations. OSPF will not form adjacencies if MTU values differ (unless you disable MTU checking with ip ospf mtu-ignore).
3. Cost/Metric Tuning Tunnel interfaces often have high OSPF costs by default (calculated from interface bandwidth). Manually adjust the cost if the tunnel should be preferred or avoided for specific traffic.
4. Recursive Routing Prevention Ensure the route to the tunnel destination is learned via a non-OSPF path (directly connected, static, or different routing protocol). If OSPF advertises the tunnel endpoint address over the tunnel itself, recursive routing will break the tunnel.
BGP uses TCP unicast, not multicast, so it can operate over any tunnel type. However, GRE is still commonly used for BGP when multiple routing protocols need to share the tunnel, when multicast-based protocols (OSPF, EIGRP) are also required, or when a simple, lightweight tunnel is preferred over complex IPSec configurations.
Pure GRE is stateless—there is no inherent mechanism to detect if the remote endpoint has failed or become unreachable. Packets simply stop arriving, but the tunnel interface remains administratively up. To address this, implementations provide GRE keepalives.
How GRE keepalives work:
GRE keepalives are an interesting mechanism. The local router sends a GRE-encapsulated packet to the remote endpoint. The inner packet is actually an IP packet addressed back to the local router. If the remote endpoint is alive and the tunnel is functional:
GRE KEEPALIVE MECHANISM═══════════════════════════════════════════════════════════════════════════ KEEPALIVE PACKET STRUCTURE:────────────────────────── Outer IP Header: Source: 203.0.113.1 (Local tunnel source) Destination: 198.51.100.1 (Remote tunnel destination) Protocol: 47 (GRE) GRE Header: Protocol Type: 0x0800 (IPv4) Inner IP Header: Source: 198.51.100.1 (Remote's perspective - looks like it came from remote) Destination: 203.0.113.1 (Addressed back to local!) Protocol: 47 (GRE, for secondary encapsulation) Inner GRE Header: Protocol Type: 0x0000 (Null/keepalive indicator) KEEPALIVE FLOW:────────────── Step 1: Router A generates keepalive ┌─────────────────────────────────────────────────────┐ │ Outer IP: 203.0.113.1 → 198.51.100.1 (proto 47) │ │ GRE: Proto 0x0800 │ │ Inner IP: 198.51.100.1 → 203.0.113.1 (proto 47)│ │ GRE: Proto 0x0000 │ └─────────────────────────────────────────────────────┘ │ ▼Step 2: Packet transits to Router B via normal routing │ ▼Step 3: Router B receives packet on physical interface - Matches tunnel destination? Yes (198.51.100.1) - De-encapsulates, revealing inner packet Step 4: Router B examines inner packet - Destination: 203.0.113.1 (not local!) - Must route this packet... - Best route to 203.0.113.1: via Tunnel0 Step 5: Router B encapsulates and sends back ┌─────────────────────────────────────────────────────┐ │ Outer IP: 198.51.100.1 → 203.0.113.1 (proto 47) │ │ GRE: Proto 0x0800 │ │ Inner IP: 198.51.100.1 → 203.0.113.1 (proto 47)│ │ GRE: Proto 0x0000 │ └─────────────────────────────────────────────────────┘ │ ▼Step 6: Router A receives return packet - Recognizes as keepalive response - Resets failure counter - Tunnel remains UP KEEPALIVE CONFIGURATION:─────────────────────── interface Tunnel0 keepalive 10 3 ! Send keepalive every 10 seconds ! If 3 consecutive keepalives fail (30 seconds), mark tunnel DOWN interface Tunnel0 keepalive 5 6 ! More aggressive: every 5 seconds, tunnel down after 30 seconds (5×6) interface Tunnel0 no keepalive ! Disable keepalives (default on some platforms) FAILURE SCENARIOS:───────────────── 1. Remote router down: - Keepalives sent but never return - After 3 failures (30 sec with keepalive 10 3): Tunnel0 → DOWN - Routing protocols detect interface down, reconverge 2. Intermediate path failure: - Outer IP can't reach destination - Same result: tunnel goes DOWN 3. Remote tunnel misconfigured: - Packets reach remote but aren't de-encapsulated - No return path for inner packet - Keepalive fails, tunnel goes DOWNKeepalive timing considerations:
Interval (first number) The time between keepalive transmissions. Smaller values provide faster failure detection but increase overhead. Typical values: 5-30 seconds.
Retries (second number) The number of consecutive failures before the tunnel is marked down. The total detection time is interval × retries. Typical values: 3-6 retries.
Trade-offs:
If running a routing protocol (OSPF, EIGRP) over the GRE tunnel, the routing protocol's own hello/dead timers provide failure detection. GRE keepalives become redundant but can still be useful—they operate at a lower layer and may detect certain failures that routing protocols miss (e.g., tunnel misconfiguration where the interface is up but encapsulation fails).
GRE was designed for flexibility and efficiency, not security. Understanding its security limitations is critical for safe deployment.
GRE provides NO security:
The GRE over IPSec solution:
To secure GRE traffic, the standard approach is to run GRE within an IPSec tunnel. This combines GRE's multicast capability with IPSec's security services:
GRE provides:
IPSec provides:
The result is a secure, multicast-capable tunnel suitable for enterprise deployments.
GRE OVER IPSEC PACKET STRUCTURE═══════════════════════════════════════════════════════════════════════════ Original packet:┌─────────────────┐│ IP Header │ Source: 10.1.0.100, Dest: 10.2.0.100├─────────────────┤│ TCP Header │ Port 443 (HTTPS)├─────────────────┤│ Application Data│ (Sensitive payload)└─────────────────┘ After GRE encapsulation:┌─────────────────┐│ Outer IP Header │ Src: 203.0.113.1, Dst: 198.51.100.1, Proto: 47 (GRE)├─────────────────┤│ GRE Header │ Protocol Type: 0x0800 (IPv4)├─────────────────┤│ Inner IP Header │ Source: 10.1.0.100, Dest: 10.2.0.100 (original)├─────────────────┤│ TCP Header │ Port 443 (HTTPS) (original)├─────────────────┤│ Application Data│ (original payload)└─────────────────┘ After IPSec protection (Transport Mode ESP):┌─────────────────┐│ Outer IP Header │ Src: 203.0.113.1, Dst: 198.51.100.1, Proto: 50 (ESP)├─────────────────┤ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐│ ESP Header │ SPI, Sequence Number │ ENCRYPTED├─────────────────┤ │ AND│ GRE Header │ ◄── Encrypted │ AUTHENTICATED├─────────────────┤ ││ Inner IP Header │ ◄── Encrypted │├─────────────────┤ ││ TCP Header │ ◄── Encrypted │├─────────────────┤ ││ Application Data│ ◄── Encrypted │├─────────────────┤ ││ ESP Trailer │ Padding, pad length, Next Hdr │├─────────────────┤ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┘│ ESP ICV │ Integrity Check Value (auth tag)└─────────────────┘ PROTECTION SUMMARY:────────────────── │ Threat │ Plain GRE │ GRE + IPSec │├────────────────────────┼───────────┼─────────────┤│ Eavesdropping │ Vulnerable│ Protected ││ Data Modification │ Vulnerable│ Protected ││ Replay Attacks │ Vulnerable│ Protected ││ Source Spoofing │ Vulnerable│ Protected ││ Unauthorized Injection │ Vulnerable│ Protected │Plain GRE should only be used in physically isolated networks, within data centers, or for testing purposes. For any traffic traversing the Internet or untrusted networks, always protect GRE with IPSec. Many compliance frameworks (PCI-DSS, HIPAA, SOC2) explicitly require encryption for data in transit.
GRE's combination of simplicity, flexibility, and multicast support has made it one of the most widely deployed tunneling protocols. Let's consolidate the key concepts:
What's next:
While GRE excels at flexibility and simplicity, it lacks the security services required for protecting sensitive traffic. The next page explores IPSec Tunneling, which provides the encryption, integrity, and authentication missing from GRE. You'll learn how IPSec tunnel mode creates complete secure tunnels and how GRE and IPSec combine for the best of both worlds.
You now understand GRE tunneling in depth—its header format, configuration, multicast support, keepalive mechanism, and security limitations. This knowledge forms the foundation for understanding when to use GRE alone, when to combine it with IPSec, and how to troubleshoot GRE-based network architectures.