Generic Routing Encapsulation

Generic Routing Encapsulation (GRE) creates an overlay by placing an original packet inside a GRE header and an outer IP header. The outer addresses identify the tunnel endpoints, while the inner addresses identify the communicating workloads or networks. Intermediate routers forward the outer packet without needing routes to the inner destination. At the receiving endpoint, the outer IP and GRE headers are removed and the original packet is forwarded according to the overlay routing configuration.

This creates two separate routing problems. The underlay must provide reachability between the tunnel endpoints, and the overlay must provide routes for the networks carried through the tunnel. For example, two virtual routers can establish a GRE tunnel across a routed private network and exchange branch and application prefixes using BGP over the tunnel. GRE does not discover routes or select paths by itself; static routes, routing protocols, or an SD-WAN control plane perform those functions. Avoid routing the remote tunnel endpoint through the tunnel itself, which can create recursive routing failures.

In cloud architectures, GRE commonly connects software routers and SD-WAN appliances to a routing hub. AWS Transit Gateway Connect is an example: it uses GRE for the data plane and BGP for dynamic route exchange between Transit Gateway and a supported appliance. A Connect attachment uses an existing VPC attachment or AWS Direct Connect attachment as its transport attachment. The GRE peer addresses belong to the transport path, while separate inside addresses support BGP communication. Creating the tunnel is not sufficient: Transit Gateway route table associations, route propagation, appliance routing, and VPC routes must also direct traffic correctly.

A practical design might place redundant SD-WAN appliances in a cloud VPC. Each appliance maintains branch connectivity and establishes Connect peers with Transit Gateway. Branch prefixes are advertised toward the cloud routing hub, and permitted cloud prefixes are advertised back to the appliances. Traffic follows the selected overlay routes while the transport network carries the encapsulated packets. This allows the SD-WAN routing domain to integrate with cloud routing without requiring the underlay to learn every branch prefix.

GRE does not encrypt payloads, authenticate peers, or provide cryptographic integrity. IPsec serves a different purpose by protecting IP traffic. Where confidentiality is required, an architecture can carry GRE inside an appropriately configured IPsec connection or use another supported encrypted transport. This must be validated for the particular endpoints and cloud attachment types; a managed IPsec VPN endpoint does not automatically function as a GRE endpoint. AWS Transit Gateway Connect itself does not add encryption to GRE traffic, and an AWS Site-to-Site VPN attachment is not a supported Connect transport attachment.

Encapsulation also reduces the effective payload size. Basic GRE over IPv4 adds 24 bytes: a 20-byte outer IPv4 header and a 4-byte GRE header. With a 1,500-byte underlay MTU, that leaves 1,476 bytes for the inner IP packet before any additional headers are considered. Optional GRE fields, IPv6 outer headers, and IPsec can increase overhead. Validate path MTU discovery, allow the necessary ICMP messages, and consider TCP MSS adjustment where appropriate; small probes succeeding while large transfers stall is a common MTU symptom.

Operationally, permit IP protocol 47 wherever GRE must cross a firewall or network filter; GRE does not use TCP or UDP port 47. Traditional port-based NAT can complicate GRE connectivity, so endpoint reachability and device support must be checked explicitly. Use redundant endpoints and routing adjacencies, verify return paths, and monitor both underlay reachability and overlay route health. Although GRE can encapsulate multicast traffic, that capability does not mean every cloud GRE integration supports multicast forwarding.