What is Generic Routing Encapsulation (GRE) and how does it differ from IP-in-IP?

What is GRE and how does it differ from IP-in-IP?

GRE and IP-in-IP carry packets between tunnel endpoints across another IP network. Choose a tunnel supported by both your X4B service and your backend operating system. The Tunnels guide describes the available setup paths.

Comparing the protocols

The header sizes assume no IPv4 options, optional GRE fields or additional encapsulation. Optional checksums, keys and sequence numbers increase GRE overhead. The small difference alone does not predict application performance; path MTU, routing and implementation support also matter.

TL;DR:

• IP-in-IP will use very slightly less bandwidth
• GRE is more widely supported
• GRE supports additional features (most of which are not useful in this context)

What is Generic Routing Encapsulation (GRE)?

GRE creates a logical point-to-point path across an IP network, without a connection-establishment handshake. It can connect separated subnets or remote sites across a WAN. GRE adds a header identifying the encapsulated protocol. The outer IP header routes the packet to the other tunnel endpoint, which removes the encapsulation and forwards the inner packet.

GRE can carry IP and non-IP protocols, depending on implementation support. Supported payloads can include IPv4, IPv6 and multicast traffic. Support for a payload or optional field in the protocol does not guarantee that a particular service or operating system supports it. For example, multicast can cross an underlying network that does not route multicast itself. Check the selected tunnel type before using these features.

An optional checksum detects corruption in the encapsulated packet. An optional key distinguishes multiple logical tunnels between the same endpoint addresses. It is not a password.

Optional sequence numbers support in-order delivery, which can benefit applications that require ordered UDP packets. Lost packets are not retransmitted. Neither X4B nor X4BWinTunnel supports GRE sequencing. As of 2026, Linux does not reorder GRE packets using sequence numbers; sequence-based reordering remains a feature for bespoke applications in this context.

What is IP-in-IP?

The IPv4-in-IPv4 encapsulation described here carries an IPv4 packet inside another IPv4 packet. It has a smaller base header than GRE and can be appropriate where both endpoints support it. It is also used by Mobile IPv4. IPv4-in-IPv4 identifies traffic by its outer endpoints rather than a GRE-style tunnel key. A network or device may support one encapsulation protocol better than the other, so check the complete path.

It does not directly carry arbitrary non-IP protocols. Other forms of IP encapsulation, including IPv6 tunneling, have their own specifications and implementation requirements. Multicast support must also be checked for the actual implementation rather than inferred from the tunnel name.

Platform Support

Linux provides tunnel configuration through iproute2; BSD systems use their own networking tools. Windows support depends on the edition, version and networking role. For example, Windows Server RAS Gateway supports GRE, but this does not establish compatibility with every X4B tunnel setup.

X4B’s Windows tunnel client supports GRE and IP-in-IP and is available to all customers. Use the X4B tunnel installation guides for your service and platform. Confirm the supported OS and tunnel-client version before changing a production server's networking.

Choosing a tunnel

GRE is generally recommended when supported by your service and backend; IP-in-IP offers slightly lower encapsulation overhead. Follow the Dashboard's setup instructions for the selected type. Account for MTU and firewall rules when testing; neither protocol is inherently a secure VPN.

Protocol references: IPv4-in-IPv4, GRE, GRE keys and sequencing, and Windows Server GRE.