GRE Tunnel: Understand How It Works and When to Use It
A GRE tunnel creates a virtual connection between two network endpoints by wrapping one network packet inside another packet. GRE stands for Generic Routing Encapsulation, and it allows traffic to travel across a network that may not directly support the original protocol. The result behaves like a logical point-to-point link between routers, firewalls, servers or cloud gateways.
Businesses commonly use GRE tunnels to connect branch networks, transport routing protocols or carry multicast traffic across an IP network. The tunnel can make two distant routers appear directly connected even though several internet or service-provider devices sit between them. This flexibility makes GRE useful for enterprise networking, labs, cloud connectivity and temporary migration projects.
GRE is an encapsulation protocol rather than a complete security solution. It can carry traffic between locations, but it does not provide strong encryption, identity verification or confidentiality by itself. Sensitive GRE traffic is therefore commonly protected with IPsec or another secure transport mechanism when it must cross an untrusted network.
This guide explains how GRE tunnelling works, what appears inside a GRE packet and how GRE differs from a traditional VPN. It also covers GRE over IPsec, routing protocols, multicast, MTU, fragmentation, configuration planning and troubleshooting. The goal is to help you decide whether GRE is suitable for your network and deploy it more reliably.
What Is a GRE Tunnel?
A GRE tunnel is a logical interface that transports one network-layer protocol through another network-layer protocol. RFC 2784 defines GRE as a method for encapsulating an arbitrary network-layer protocol inside another network-layer protocol. In a common deployment, an original IPv4 packet is placed inside GRE and then carried inside a new outer IPv4 packet.
The original packet is known as the payload or inner packet. GRE adds a header that identifies the protocol being transported, while an outer IP header provides the real addresses used to move the packet between tunnel endpoints. Intermediate routers normally examine the outer header instead of making routing decisions from the encapsulated inner addresses.
At the receiving endpoint, the outer IP header and GRE header are removed. The original packet is then forwarded according to the destination information it contained before encapsulation. Devices located behind the tunnel endpoints can therefore communicate through private addressing or routing relationships without needing to understand how the underlying transport network is organised.
GRE can carry IPv4, IPv6, MPLS and other supported network-layer payloads. IPv6 can also be used as either the carried protocol or the delivery protocol under the GRE procedures defined in RFC 7676. This flexibility makes GRE broader than a basic IP-in-IP tunnel that supports fewer payload combinations.
How a GRE Tunnel Works
The process begins when a router receives a packet whose destination is reachable through the tunnel interface. Instead of forwarding the packet directly through a physical interface, the router treats it as tunnel payload. It preserves the original packet and prepares it for transportation across the network between the configured GRE endpoints.
The router adds a GRE header in front of the original packet. That header contains a protocol-type field identifying the encapsulated payload and may contain optional information. The device then adds a new outer IP header containing the source address of the local tunnel endpoint and the destination address of the remote tunnel endpoint.
The underlay network routes the encapsulated packet according to the outer destination address. Routers between the endpoints do not need routes for the private networks carried inside the tunnel. They only require sufficient routing information to move the outer packet from the tunnel source to the configured tunnel destination.
When the packet reaches the remote endpoint, that device removes the outer IP and GRE headers. It then processes the restored inner packet as though it had arrived through a direct logical interface. The receiving router uses its normal routing table to deliver the packet to a local network, another interface or a different destination.
GRE Header Explained
The basic GRE header contains flags, a version field and a protocol-type field. The protocol type identifies what kind of payload follows the GRE header. This field allows the tunnel to carry different protocols instead of assuming that every encapsulated packet contains the same type of network-layer information.
GRE can include an optional checksum and reserved field. When the checksum-present bit is enabled, the receiver can check the GRE header and payload for accidental corruption. A checksum can detect transmission errors, but it does not provide authentication because an attacker could create a new packet and calculate a matching checksum.
RFC 2890 defines optional Key and Sequence Number fields. The Key field can identify a particular traffic flow or logical tunnel, while the Sequence Number field can help maintain packet ordering. These fields expand GRE’s flexibility when several traffic streams share the same endpoints or when order-sensitive delivery needs additional support.
The GRE Key should not be treated as a password, encryption key or authentication credential. RFC 2890 explicitly states that it is not involved in security despite its name. Network teams should protect important GRE traffic with an actual security protocol instead of assuming that a matching tunnel key prevents interception or packet injection.
Common GRE Tunnel Uses
One common use is connecting private networks across an existing IP infrastructure. A company can create a logical link between two branch routers even when the service provider does not carry the organisation’s private routing information. Only the public or transport addresses of the tunnel endpoints need to be reachable through the underlay.
GRE is also useful for transporting dynamic routing protocols between remote sites. The tunnel behaves like a logical interface, allowing routers to exchange route information across it. This can simplify large environments where manually maintaining static routes for every remote network would become difficult and increase the risk of configuration errors.
Another important use is carrying multicast or broadcast-dependent traffic across an underlay that mainly provides unicast connectivity. Routing protocols and applications that depend on multicast can operate through a suitable GRE design because the original packets are encapsulated before crossing the underlying network.
GRE can also support migrations, testing environments and temporary network overlays. Engineers may use a tunnel to preserve existing addressing while infrastructure is moved between sites or cloud environments. GRE should still be designed carefully because a quick temporary tunnel can become a permanent dependency without proper capacity, security or monitoring controls.
GRE Tunnel vs VPN
A VPN is a broad category of technologies used to create a private logical connection across another network. A GRE tunnel can provide logical connectivity, so it is sometimes casually described as a VPN. However, people commonly expect a business VPN to include encryption, authentication and integrity protection, which GRE alone does not provide.
GRE focuses on encapsulation and protocol flexibility. It can carry several network-layer payloads and support routing relationships that may be difficult with a simpler encrypted tunnel. Its basic design does not hide the contents of encapsulated traffic from someone who can observe the outer path.
Technologies such as IPsec focus more directly on protecting IP communication. IPsec can authenticate endpoints, verify integrity and encrypt packet contents. It is therefore more appropriate than plain GRE when confidentiality is the main requirement, although its operating mode may not provide every routing and multicast capability desired by the network design.
The practical choice is not always GRE or VPN. Many organisations combine GRE with IPsec to gain both flexible encapsulation and cryptographic protection. GRE carries the required protocols, while IPsec protects the GRE packet as it crosses the public or otherwise untrusted underlay.
GRE Tunnel vs IPsec
GRE and IPsec solve different networking problems. GRE creates a tunnel capable of carrying multiple network-layer protocols through another network. IPsec is a security framework used to authenticate and protect IP packets. Comparing them as direct substitutes can therefore hide the reason they are often deployed together.
Plain GRE can easily support traffic such as dynamic routing updates and multicast inside the tunnel. Traditional policy-based IPsec commonly focuses on selected unicast IP traffic that matches defined security policies. Modern route-based IPsec designs can provide greater routing flexibility, but the exact features depend on the platform and configuration.
IPsec adds encryption and integrity protection that GRE lacks. GRE adds another encapsulation option and logical interface that may simplify routing. When GRE is carried through IPsec, the original packet becomes GRE payload, and the resulting GRE packet is then protected before crossing the underlay.
The combination introduces more overhead than using either technology alone. Every added IP, GRE, ESP, authentication and encryption field consumes space. Engineers must account for this overhead when selecting an MTU, calculating TCP MSS and estimating throughput, particularly when the physical path already contains PPPoE, cloud or additional tunnel headers.
How GRE Over IPsec Works
In a GRE-over-IPsec design, the router first identifies traffic routed through the GRE tunnel. It adds the GRE and outer tunnel IP headers, creating a new GRE packet addressed to the remote tunnel endpoint. IPsec then protects that GRE packet according to the configured security policy or tunnel profile.
Encryption hides the GRE header and its original payload from ordinary observers when ESP is correctly configured. Integrity checks help detect unauthorised modification, while peer authentication helps confirm that the protected connection terminates on an approved device. GRE continues to provide the logical interface and protocol-carrying capability inside that protected relationship.
At the remote endpoint, IPsec verifies and decrypts the protected packet. The router then processes the exposed GRE header, removes the GRE encapsulation and forwards the restored original packet. The receiving network sees the original private or routed traffic rather than the transport headers used across the public path.
RFC 2890 recommends using IP security protocols when GRE extensions require protection and clarifies that the optional GRE Key is not a security control. Organisations should also use strong modern IPsec algorithms, secure credentials and appropriate key rotation rather than depending only on the presence of encryption.
GRE Tunnel MTU and Overhead
Encapsulation increases packet size because GRE adds new headers around the original packet. A basic GRE-over-IPv4 packet commonly adds a 20-byte outer IPv4 header and a minimum 4-byte GRE header. This creates 24 bytes of overhead before optional GRE fields, IPsec protection or other lower-layer encapsulation are considered.
When the physical interface supports a 1500-byte IP packet, a basic GRE tunnel may use an inner IP MTU of 1476 bytes. A full 1500-byte inner packet would become 1524 bytes after basic GRE-over-IPv4 encapsulation. It must therefore be fragmented, reduced or handled by a path supporting larger packets.
Additional protection lowers the available inner MTU further. GRE over IPsec may include an extra outer header, ESP fields, authentication data, padding and other information determined by the selected mode and algorithm. The correct MTU cannot be assumed from GRE overhead alone when several encapsulation layers exist.
The safest approach is to calculate the known overhead and then verify the usable Path MTU through testing. Network teams should account for every tunnel, provider and cloud layer between endpoints. Choosing a value with enough room for all headers helps prevent packet fragmentation, retransmissions and applications that work only with small transfers.
Fragmentation and Path MTU
Fragmentation occurs when an encapsulated packet is larger than a link can carry. GRE creates a special challenge because the tunnel source adds headers after receiving the original packet. RFC 7588 documents widely deployed procedures for handling fragmentation in point-to-point GRE tunnels that carry IPv4, IPv6 or MPLS payloads.
One option is to fragment the inner IPv4 packet before adding GRE encapsulation. Each fragment receives its own GRE and outer IP headers, increasing the total number of packets. Another option is to encapsulate first and allow the outer IPv4 packet to be fragmented later, requiring the tunnel endpoint to reassemble it before GRE decapsulation.
Path MTU Discovery can reduce unnecessary fragmentation by learning the smallest supported MTU between endpoints. When a packet with the Don’t Fragment bit encounters a smaller link, the router drops it and returns an ICMP message containing the limiting MTU. The sender can then reduce future packet sizes.
PMTUD depends on the tunnel endpoint receiving the required ICMP messages. Blocking all ICMP traffic can create an MTU black hole in which small packets work but larger transfers fail. Cisco recommends ensuring the relevant ICMP feedback is permitted before relying on tunnel Path MTU Discovery.
GRE and TCP MSS
TCP MSS represents the largest amount of TCP data an endpoint is prepared to receive in one segment. Because the MSS excludes IP and TCP headers, it must be lower than the tunnel’s effective MTU. A correct MSS helps endpoints create packets that fit through the GRE path without unnecessary fragmentation.
For a basic GRE tunnel with an inner IPv4 MTU of 1476 bytes, a simplified TCP MSS may be 1436 bytes after subtracting 20 bytes for the IPv4 header and 20 bytes for the TCP header. TCP options, IPsec and additional encapsulation can require a lower value.
Routers can adjust the MSS advertised in TCP connection-opening messages. This process, often called MSS clamping or TCP MSS adjustment, encourages both endpoints to send smaller TCP segments even when they do not understand the tunnel overhead. It is commonly used when PMTUD is unreliable or network devices block required feedback.
MSS adjustment only affects TCP traffic. UDP, ICMP and other protocols do not use the TCP MSS field, so the tunnel MTU and Path MTU still need correct configuration. Cisco recommends fixing PMTUD when possible and presents TCP MSS adjustment as another method for keeping TCP packets within the usable size.
Routing Over a GRE Tunnel
A GRE tunnel normally appears in the routing system as a logical interface with its own address. Routes can point toward that interface in the same way they point toward a physical connection. Traffic matching those routes is encapsulated and sent to the configured tunnel destination through the underlying network.
Static routes are suitable for small or stable environments. The administrator manually identifies which remote prefixes should use the GRE interface. This approach is simple but becomes harder to manage when many branches, failover paths or frequently changing networks must be maintained.
Dynamic routing protocols can exchange route information through the tunnel, allowing routers to learn remote prefixes automatically. The underlay must still maintain a separate path to each tunnel endpoint. A route to the tunnel destination must never depend entirely on the tunnel itself, or recursive routing can prevent the GRE connection from operating.
Network teams should separate overlay and underlay routing logically. The underlay provides reachability between tunnel endpoints, while the overlay carries business routes through GRE. Clear route filtering, metrics and failover policies help prevent loops, unstable paths and accidental use of the public interface for private traffic.
Multicast Over GRE
GRE can encapsulate multicast packets inside unicast outer IP packets. This allows multicast traffic to cross an underlay that does not provide native multicast routing between the sites. The endpoints treat the original multicast packet as payload and transport it through the logical GRE link.
This capability is useful for routing protocols, service discovery and applications that rely on multicast distribution. A point-to-point GRE tunnel can make two remote routers behave as though they share a logical network connection, allowing suitable multicast-dependent protocols to form relationships through it.
Multicast over GRE still consumes bandwidth on the tunnel path. Replication may occur at tunnel endpoints, and several point-to-point tunnels can create duplicate copies of the same traffic. Large deployments require careful planning to avoid inefficient hub processing, unnecessary bandwidth consumption or excessive tunnel-interface state.
Administrators should also consider quality of service and packet loss. Cisco tunnel interfaces support several QoS functions, including traffic shaping and policing options, allowing important tunneled traffic to receive defined treatment. The exact capabilities and commands depend on the router platform and software release.
Benefits of GRE Tunnelling
The main benefit is protocol flexibility. GRE can carry multiple network-layer protocols through a common transport network rather than being limited to one simple payload type. This helps organisations preserve routing behaviour or connect networks that would otherwise require major addressing and application changes.
GRE also provides a logical point-to-point interface that integrates naturally with routing. Administrators can apply routes, monitoring and selected network policies to the tunnel instead of managing every private destination directly through the underlay. This separation can make overlay designs easier to understand and modify.
Another advantage is broad vendor support. RFC 7588 notes that GRE has been implemented by many vendors and is widely deployed. This maturity makes it available across routers, firewalls, operating systems and cloud environments, although optional fields and operational features may still differ between implementations.
GRE can also be combined with other technologies. It may operate through IPsec for security, use IPv4 or IPv6 as transport and carry IPv4, IPv6 or other supported payloads. This adaptability makes it useful when a single tunnel must satisfy routing, protocol and transport requirements that simpler tunnelling methods cannot meet.
GRE Limitations and Risks
The biggest limitation is the absence of built-in confidentiality. Anyone able to capture a plain GRE packet may be able to inspect the encapsulated traffic. The checksum, Key and Sequence Number fields do not replace encryption or cryptographic authentication, so they cannot make an untrusted public route secure.
GRE also adds overhead and can create MTU problems. Networks that ignore the extra headers may experience fragmentation, failed large transfers or reduced throughput. These problems become more likely when GRE is combined with IPsec, PPPoE, cloud overlays or another tunnel operating across the same physical path.
A basic point-to-point GRE tunnel depends on the reachability and stability of both configured endpoints. If the underlying route fails, the logical interface may stop carrying useful traffic. Some implementations may continue showing the tunnel interface as administratively available even when the remote endpoint is not forwarding packets correctly.
GRE uses IP protocol number 47 rather than TCP or UDP port 47. Firewalls and network address translation devices must understand and permit the protocol. A rule that opens TCP port 47 does not allow GRE traffic, and some consumer NAT environments may have difficulty tracking multiple GRE sessions.
GRE Tunnel Configuration Planning
Begin by selecting stable and reachable tunnel source and destination addresses. Loopback addresses can provide resilience when the router has several physical paths, while interface addresses may be easier in a small environment. The underlay routing table must reach the remote endpoint without depending on the GRE overlay.
Choose tunnel interface addresses from a dedicated subnet and document which networks each endpoint will advertise or route. Avoid overlapping addresses between sites because GRE does not automatically resolve duplicate private networks. Network address translation or a redesigned addressing plan may be needed when both locations use the same prefixes.
Calculate MTU and MSS requirements before moving production traffic. Include the outer IP header, GRE fields, optional GRE extensions, IPsec overhead and any provider encapsulation. Test large packets in both directions because asymmetric routing or different access technologies can produce different usable Path MTU values.
Finally, define the security and availability design. Decide whether the tunnel requires IPsec, which peers are allowed, how keys or certificates will rotate and what should happen when the primary underlay path fails. Monitoring, logging and ownership should be established before the tunnel becomes a critical business dependency.
GRE Tunnel Troubleshooting
When a tunnel fails completely, first verify underlay reachability between the configured source and destination addresses. Test the real transport addresses rather than the private networks carried inside GRE. If the endpoints cannot reach each other through the underlay, changing tunnel routes or GRE settings will not restore connectivity.
Next, check firewall and access-control policies for IP protocol 47. Confirm that network address translation devices support the intended GRE flow and that no security appliance is treating GRE as an unsupported protocol. Remember that permitting TCP or UDP port 47 does not permit GRE.
When small packets succeed but websites, file transfers or applications fail, investigate MTU and fragmentation. Check the tunnel MTU, test Path MTU, confirm that required ICMP messages are not blocked and review TCP MSS adjustment. Cisco identifies blocked ICMP as a common cause of PMTUD failure in GRE and IPsec environments.
If the tunnel is reachable but routes are missing, inspect the overlay routing table and protocol neighbour relationships. Verify that the remote prefixes point toward the tunnel and that endpoint routes remain in the underlay. Also check for recursive routing, duplicate tunnel addresses, route filtering and authentication mismatches in the routing protocol.
GRE Security Best Practices
Do not send confidential or sensitive information through plain GRE across an untrusted network. Protect the tunnel with IPsec or another security layer that provides encryption, integrity and peer authentication. The GRE Key field may separate flows, but RFC 2890 states that it does not provide security.
Restrict which addresses can send GRE packets to each tunnel endpoint. Firewall rules should permit protocol 47 only from authorised peers rather than accepting it from the entire internet. When IPsec protects GRE, restrict the associated security negotiation and encrypted traffic to the approved endpoint addresses as well.
Use route filtering to control which networks can be learned or accepted through the tunnel. A compromised or misconfigured peer should not be able to advertise every destination into the organisation. Authentication for dynamic routing protocols provides another control, although it does not replace encryption of the underlying GRE traffic.
Monitor tunnel status, packet loss, latency, interface errors and unusual route changes. Review encryption status separately when using GRE over IPsec because the GRE interface may appear active even when the security association is unavailable. Alerts should identify both overlay and underlay failures so teams can find the correct layer quickly.
FAQs
What is a GRE tunnel in simple terms?
A GRE tunnel wraps one network packet inside another packet so it can travel between two remote endpoints. It creates a logical connection across an existing IP network.
Is a GRE tunnel encrypted?
No. Basic GRE provides encapsulation but not strong encryption or authentication. GRE traffic should be protected with IPsec when it crosses an untrusted network.
What port does GRE use?
GRE does not use a TCP or UDP port. It uses IP protocol number 47, so firewalls must permit the protocol rather than opening port 47.
What is the standard MTU for a GRE tunnel?
A basic GRE-over-IPv4 tunnel on a 1500-byte path commonly uses an inner MTU of 1476 bytes because the outer IPv4 and minimum GRE headers add 24 bytes.
What is the difference between GRE and IPsec?
GRE provides flexible packet encapsulation and supports several payload types. IPsec provides encryption, integrity and authentication, so both technologies are often combined.
GRE Tunnel: Final Takeaways
A GRE tunnel creates a logical connection by encapsulating one network-layer packet inside another. The outer IP header transports the packet between tunnel endpoints, while the GRE header identifies the encapsulated payload. The receiving device removes those headers and forwards the restored original packet.
GRE is useful for connecting private networks, transporting routing protocols and carrying multicast traffic across an IP underlay. It supports several payload and delivery combinations, including IPv4 and IPv6. This flexibility makes GRE valuable in enterprise, service-provider, cloud and migration environments.
GRE does not provide encryption or reliable identity verification by itself. Organisations should protect sensitive tunnels with IPsec, restrict protocol 47 to trusted peers and apply route filtering. The optional GRE Key may identify a flow, but it should never be treated as a security credential.
Successful deployment also depends on MTU, Path MTU Discovery and underlay reachability. Calculate encapsulation overhead, permit necessary ICMP feedback and test large transfers before production use. A properly planned GRE tunnel can provide flexible connectivity without creating hidden fragmentation, routing or security problems.
