"Should I use GRE, IPsec, or GRE over IPsec?" is the question that lives at the start of every site-to-site tunnel design conversation. The answer is not "always GRE over IPsec" the way some templates suggest. It depends on what you actually need to carry and where the tunnel is going. This article is the decision framework: a side-by-side comparison of the three options, the cases where each is the right answer, and a worked example for the most common decision points.
This is part of the PingLabz GRE Tunnels: The Complete Guide cluster. For protocol theory, start at the pillar. For configuration, see the GRE config lab and the GRE over IPsec walkthrough.
Side-by-Side Comparison
| Property | Plain GRE | IPsec (tunnel mode) | GRE over IPsec |
|---|---|---|---|
| Encryption | None | Yes (AES, ChaCha20, etc) | Yes (IPsec layer) |
| Authentication | None | Yes (PSK, certificates) | Yes (IPsec layer) |
| Integrity | Optional checksum | Yes (HMAC, ICV) | Yes (IPsec layer) |
| Carries multicast | Yes | No (without GRE) | Yes |
| Carries non-IP protocols | Yes (any EtherType) | No | Yes |
| Routing protocols (OSPF, EIGRP) | Yes | No (without GRE) | Yes |
| iBGP neighbor over tunnel | Yes | Yes (unicast) | Yes |
| Per-packet overhead | ~24 bytes | ~50-60 bytes | ~70-80 bytes |
| Stateful (per-session) | No (stateless) | Yes (SA per peer) | Yes (IPsec) + No (GRE) |
| NAT traversal | No (no UDP/TCP) | Yes (NAT-T over UDP 4500) | Yes (via IPsec NAT-T) |
| Config complexity | Low (3 lines) | Medium (IKE + transform + crypto map / profile) | High (both) |
| CPU cost | Negligible | Significant (encryption) | Significant |
| Suitable for public internet | No (no encryption) | Yes | Yes |
| Suitable for trusted underlay | Yes | Overkill | Overkill |
The Decision Tree
Three questions, in this order:
- Does the path need encryption? If the tunnel rides over the public internet, an internet-VPN underlay, or any network you do not control end to end: yes. If the path is your own private MPLS, your own internal data center fabric, or a lab: no.
- Do you need to carry routing-protocol multicast or non-IP traffic through the tunnel? If yes (you are running OSPF/EIGRP across the tunnel, or carrying IPv6 in IPv4, or doing something that needs the EtherType field): you need GRE. If no (the only thing crossing is unicast IP between specific subnets): you do not need GRE.
- Do you anticipate scaling to many sites with NHRP and dynamic spoke-to-spoke (DMVPN)? If yes: GRE over IPsec is the natural foundation, since DMVPN is mGRE plus IPsec plus NHRP.
The decision falls out:
- Encryption needed + routing protocols / multicast / DMVPN potential: GRE over IPsec.
- Encryption needed + plain unicast IP only: IPsec alone, in tunnel mode.
- No encryption needed + routing protocols / multicast: Plain GRE.
- No encryption needed + plain unicast IP only: No tunnel, just route through the underlay.
When Plain GRE Is the Right Answer
Plain GRE has a smaller place in 2026 than it did in 2010 because the public internet is now the default underlay for most enterprise WAN, but the cases still exist:
- Lab and learning environments. You are studying for CCNP and want to see OSPF form a neighbor across a routed lab without the IPsec complication. Plain GRE.
- Private MPLS or carrier Ethernet underlays. The underlay is contractually private and you have decided the carrier counts as trusted. GRE adds the routing-protocol-multicast capability your design needs without the encryption overhead.
- Internal data-center overlays. Inside a DC you trust, a GRE tunnel between two routers that need a specific traffic-engineering path can be plain GRE. Most DC overlays in 2026 have moved to VXLAN (driven by EVPN), but legacy GRE designs still exist.
- IPv4-IPv6 transition tunnels (6in4). The classic 6to4 / 6in4 tunnel is plain GRE with IPv6 inside an IPv4 outer header. No encryption is typically used because the IPv6 traffic itself is internet-facing and end-to-end secured by application-layer protocols.
- Service-provider PE-CE sub-protocols. Some service-provider designs use GRE to carry MPLS labels or IS-IS frames across an IP-only segment. Plain GRE because the SP backbone is trusted.
When IPsec Alone Is the Right Answer
This is the right answer more often than engineers expect:
- Site-to-site between two firewalls with simple unicast traffic. A branch site connecting to HQ over the internet, where the only traffic is users in the branch reaching corporate apps in HQ. No routing protocol needed (a static route at each end is enough). IPsec in tunnel mode is simpler, has lower overhead, and one fewer thing to misconfigure.
- Cloud VPN gateways. AWS Site-to-Site VPN, Azure VPN Gateway, GCP HA VPN all default to IPsec without GRE. They use BGP over the IPsec tunnel for dynamic routing (BGP is unicast TCP, no GRE required), so the multicast-needs-GRE argument does not apply.
- Remote access VPN. Client VPN like Cisco AnyConnect or strongSwan is IPsec (or SSL/TLS), not GRE. Each user gets a unicast tunnel to the headend.
- WireGuard as an alternative. Modern deployments increasingly choose WireGuard over IPsec for its simpler config and faster crypto. WireGuard is also unicast-only without GRE. If you find yourself reaching for IPsec-alone, WireGuard is worth comparing.
When GRE over IPsec Is the Right Answer
- Branch sites running OSPF or EIGRP across an internet underlay. The classic case. You need routing-protocol-multicast (which IPsec alone cannot carry) plus encryption (which plain GRE does not provide).
- DMVPN deployments. DMVPN is built on mGRE plus IPsec plus NHRP. Even DMVPN Phase 1 (no spoke-to-spoke) uses GRE over IPsec; the difference between DMVPN and a static GRE-over-IPsec mesh is the NHRP and the multipoint tunnel mode, not the encapsulation order.
- Hub-and-spoke overlays where the hub runs iBGP RR with spokes. iBGP is unicast TCP and would work over plain IPsec, but if you also want OSPF on the same overlay (for example, OSPF for IGP between hub and spokes plus iBGP for customer routes), you are back to GRE over IPsec.
- Path-control or traffic engineering with policy routing. Some PBR designs use GRE to fix a specific next-hop and IPsec to encrypt. The combination is what you need; either alone is insufficient.
Alternatives Worth Knowing
The GRE-vs-IPsec decision is not the only one. In 2026 there are tunneling protocols that did not exist or were not mainstream when GRE was the default answer.
| Protocol | What it is | When to consider it |
|---|---|---|
| VXLAN | L2-over-UDP tunnel; the dominant data-center overlay | L2 stretch inside a DC fabric or between DCs; not for branch WAN |
| WireGuard | Modern crypto VPN; UDP-based, simple config | Simple unicast site-to-site; remote-access; cloud labs |
| SD-WAN overlays | Vendor-specific encrypted overlay (Cisco SD-WAN, FortiGate IPsec mesh, VeloCloud) | Multi-site enterprise WAN with centralized policy and orchestration |
| L2TPv3 | Layer-2 over IP tunneling (frame relay, Ethernet pseudowire) | Service-provider PWE3 use cases |
| IPv6-in-IPv6 / 6in4 | IPv6 transition tunneling | Specific dual-stack migration scenarios |
| MPLS-in-GRE / MPLS-in-UDP | Carrying MPLS over an IP backbone | SP designs that bridge MPLS islands across an IP core |
For a typical enterprise WAN in 2026, the choice is usually GRE over IPsec (or DMVPN) for legacy / Cisco-centric designs, vs an SD-WAN overlay (Cisco, Fortinet, Palo Alto, VMware) for greenfield deployments. WireGuard fills the smaller-scale and cloud-lab gap.
Worked Example: 30-Site Enterprise WAN
Concrete scenario: 30 branch sites, two data center hubs, each branch has a single 200 Mbps internet-only WAN circuit. The applications are a mix of cloud SaaS, internal apps in the DC, and voice/video collaboration. The team wants per-site routing flexibility and dynamic failover between branches when a DC link fails.
Walk through the decision tree:
- Encryption needed? Yes - public internet underlay.
- Routing protocols needed? Yes - 30 sites are too many to manage with static routes; OSPF or iBGP needed.
- Scaling to many sites with NHRP? At 30 sites, hub-and-spoke is fine but full mesh would be 870 tunnels. NHRP and DMVPN are the way to handle dynamic spoke-to-spoke for direct branch-to-branch voice/video.
Conclusion: DMVPN (mGRE + IPsec + NHRP). For the hub-side IPsec config, this is essentially "GRE over IPsec" multiplied across many spokes, with NHRP doing the dynamic destination resolution. That is the canonical Cisco answer.
Alternatively, the same scenario in 2026 is increasingly answered with SD-WAN: deploy Cisco Catalyst SD-WAN (formerly Viptela) or a competitor, and let the SD-WAN platform handle the overlay tunnels (still IPsec, often without GRE in the modern data plane), the routing (OMP or BGP), and the policy. The trade-off is operational complexity vs flexibility: DMVPN is simpler to understand for a Cisco-trained team but harder to scale beyond a few hundred sites; SD-WAN is more capable but adds a control-plane platform to operate. Both are valid 2026 answers.
Summary
The choice between GRE, IPsec, and GRE over IPsec comes down to two questions: does the path need encryption (yes for the public internet, no for a trusted underlay), and does the traffic need GRE's multi-protocol / multicast capabilities (yes for OSPF/EIGRP/IPv6-in-IPv4, no for plain unicast IP). Plain GRE is for trusted networks plus routing protocols. IPsec alone is for encrypted unicast IP between two endpoints. GRE over IPsec is for encrypted routing-protocol-aware overlays - and for any deployment that will eventually become DMVPN.
If you are designing a new enterprise WAN in 2026, the modern answers are usually DMVPN (Cisco-centric) or an SD-WAN overlay (vendor-flexible). Both build on IPsec; DMVPN explicitly uses GRE over IPsec, SD-WAN platforms often skip GRE entirely. For lab work and small deployments, plain GRE remains a perfectly good answer. For the protocol depth, see the PingLabz GRE pillar; for vendor-specific config, see GRE over IPsec and mGRE and DMVPN Introduction.