"IPsec over GRE" and "GRE over IPsec" sound like the same thing said two ways. They are not. They are two different designs with the encapsulation layers stacked in the opposite order, and the order changes what gets encrypted, what is visible on the wire, and which one you should actually deploy. This post explains IPsec over GRE specifically, contrasts it cleanly with the more common reverse, and shows when each belongs.
For the cluster overview, see the GRE complete guide.
Why two protocols at all
GRE and IPsec each do half a job, and a secure site-to-site tunnel needs both halves.
- GRE can encapsulate anything - multicast, broadcast, non-IP protocols - which means it can carry a routing protocol like OSPF or EIGRP across the tunnel. But GRE provides no encryption. A GRE packet is readable by anyone on the path.
- IPsec encrypts and authenticates, but standard IPsec only protects unicast IP. It will not, on its own, carry the multicast that routing protocols depend on.
Pair them and you get both: GRE carries the routing protocol, IPsec provides the encryption. The only question is which one wraps the other - and that is the whole "IPsec over GRE" versus "GRE over IPsec" question.
What "over" means here
The protocol that comes after "over" is the outer, transporting layer. The protocol before "over" rides inside it.
- GRE over IPsec - GRE is the passenger, IPsec is the carrier. GRE encapsulates the original packet first, then IPsec encrypts the resulting GRE packet. IPsec is the outermost header.
- IPsec over GRE - IPsec is the passenger, GRE is the carrier. Traffic is protected by IPsec first, then the GRE tunnel transports the IPsec-protected traffic. GRE is the outermost header.
IPsec over GRE: how it is built
In IPsec over GRE, you build the GRE tunnel first as a normal tunnel interface between the two sites. Then you apply IPsec to traffic traversing that GRE tunnel - the crypto policy sits inside the GRE relationship rather than wrapping the whole thing.
The encapsulation order for a packet is: original packet, then IPsec protection applied to selected traffic, then GRE encapsulation, then the physical transport header. The GRE header ends up on the outside, exposed.
That exposed GRE header is the defining characteristic. Anyone watching the path sees a GRE tunnel between the two endpoint addresses. They cannot read the IPsec-protected payload, but the tunnel itself, its endpoints, and any traffic in the GRE tunnel that was not selected for IPsec are all visible.
GRE over IPsec: the reverse, and the default choice
In GRE over IPsec, the GRE tunnel is encapsulated inside IPsec. IPsec is configured to match and protect the GRE traffic (IP protocol 47) between the two endpoints. Because IPsec wraps the entire GRE packet, everything inside the GRE tunnel is encrypted - the user data and the routing-protocol traffic alike - and the GRE header itself is hidden under the IPsec header.
This is the design almost every modern deployment uses, and DMVPN is built on this model. The companion article on GRE over IPsec covers it in full.
Side by side
When would you use IPsec over GRE?
Honestly, rarely. It exists for the narrow case where a single GRE tunnel must carry a mix of traffic and you want to encrypt only part of it - leaving the rest as plain GRE for cost, performance, or policy reasons. It can also appear when an existing GRE tunnel topology is already in production and IPsec is being layered onto specific flows without rebuilding the tunnel design.
For a brand-new secure site-to-site link, IPsec over GRE is the wrong default. It leaves the GRE header exposed, and it makes it easy to forget to protect the routing-protocol traffic - which means your OSPF or EIGRP adjacency could be crossing the internet in clear text while you believe the tunnel is "encrypted." GRE over IPsec avoids both problems by encrypting the whole GRE tunnel as one unit.
Configuration shape
GRE over IPsec - the recommended design - protects the GRE flow itself. The crypto policy matches GRE between the two physical endpoints:
! GRE over IPsec - IPsec protects the GRE traffic (protocol 47)
crypto ipsec profile PINGLABZ_PROFILE
set transform-set PINGLABZ_TS
!
interface Tunnel0
ip address 10.30.30.1 255.255.255.252
tunnel source GigabitEthernet0/0
tunnel destination 192.0.2.2
tunnel protection ipsec profile PINGLABZ_PROFILEThe single line tunnel protection ipsec profile is what makes everything entering Tunnel0 - including the routing protocol - encrypted. That one command is why GRE over IPsec is both simpler and safer, and why it is the design to reach for unless you have a specific reason not to.
Common gotchas
Key takeaways
IPsec over GRE and GRE over IPsec stack the same two protocols in opposite order, and the order matters. The protocol after "over" is the outer carrier. IPsec over GRE puts GRE on the outside, exposes the GRE header, and encrypts only the traffic explicitly selected inside the tunnel - which makes it easy to accidentally leave routing-protocol traffic unencrypted. GRE over IPsec puts IPsec on the outside, hides the GRE header, and encrypts the entire GRE tunnel including the routing protocol, in one line of config. IPsec over GRE has narrow niche uses; for any new secure site-to-site tunnel, GRE over IPsec is the correct default.
For the GRE cluster, see the GRE pillar.
