Why do two branch routers pair GRE with IPsec to run OSPF over the internet, instead of using a policy-based IPsec tunnel alone?
answer
- each covers the other's gap
- OSPF hellos go to a multicast group
- the SPD has no multicast entries
- one selector: protocol 47 between endpoints
basics
~20 sGRE gives the routers a point-to-point link that carries OSPF's multicast hellos and any routed subnet; IPsec encrypts and authenticates that single GRE flow. Policy-based IPsec alone matches unicast subnet pairs and gives OSPF no interface to run on.
solid answer
~40 sEach protocol covers the other's gap. A policy-based IPsec tunnel protects traffic that matches Security Policy Database selectors — local and remote addresses, a next-layer protocol, ports — and RFC 4301 notes that the SPD holds no multicast address entries, so OSPF hellos sent to `224.0.0.5` (AllSPFRouters) match nothing, and there is no interface on which an adjacency could form. GRE supplies that interface: hellos, link-state updates and every routed subnet become payload inside unicast GRE packets between the two public addresses. GRE is cleartext and unauthenticated, so IPsec protects the GRE flow, and the policy shrinks to one selector — IP protocol `47` between `198.51.100.1` and `203.0.113.2`. A new subnet becomes a routing change, not a new selector pair on both ends. The price is more overhead and a lower tunnel MTU.
go deeper
Recall the division of labour: GRE carries routing traffic and any subnet, IPsec encrypts and authenticates, and the combination gives two sites both.
Explain why OSPF's multicast hellos match no SPD entry, how GRE turns them into unicast protocol 47, and why the IPsec policy collapses to one selector.
Show the packet build order, the overhead and MTU consequence, and how you would localise a fault to the IPsec layer, the GRE layer or the OSPF adjacency.
Weigh GRE over IPsec against a route-based IPsec interface or a different tunnel family for a growing estate: overhead, operational layers, interoperability and how each scales to many sites.
## The scenario Two branches, each with one router and one internet connection, want their LANs to reach each other privately and want **OSPF** to keep the routes right as subnets come and go. | | Branch A | Branch B | |---|---|---| | Public (underlay) address | `198.51.100.1` | `203.0.113.2` | | LAN | `10.1.0.0/24` | `10.2.0.0/24` | | Tunnel addresses | `172.16.0.1/30` | `172.16.0.2/30` | Two jobs have to be done: **carry the routing protocol and every subnet**, and **protect the traffic on the internet**. No single tool in this picture does both. ## What a policy-based IPsec tunnel can and cannot carry IPsec (RFC 4301) decides what to protect by matching each packet against the **Security Policy Database (SPD)**. Its selectors are addresses, a next-layer protocol and ports. A policy-based site-to-site tunnel typically lists subnet pairs: `10.1.0.0/24` to `10.2.0.0/24`. - **No interface.** The protection is a policy applied to matching packets, not a link. OSPF needs an interface to send hellos on and a neighbour on the other end of it. - **No multicast in the SPD.** OSPF sends its hellos to `224.0.0.5`, AllSPFRouters (RFC 2328). RFC 4301 section 4.4.1.1 states that the SPD "does not include support for multicast address entries"; multicast needs group security associations and a group SPD, a different architecture from a two-router tunnel. - **Subnets live in the policy.** Unless the selectors are written very broadly, a third LAN behind Branch B means new selectors on *both* routers, and a mismatch silently drops that traffic. ## What GRE adds GRE (RFC 2784) wraps the payload in a 4-byte header and an outer IPv4 header with protocol **47**. Implementations present the tunnel as a point-to-point interface: - OSPF runs on it as on any link; the hello to `224.0.0.5` becomes the *payload* of a unicast GRE packet from `198.51.100.1` to `203.0.113.2`. - Any subnet routed into the tunnel interface is carried, so adding a LAN is a routing event OSPF handles by itself. - GRE alone is cleartext and unauthenticated — a gap IPsec fills. ## Putting GRE inside IPsec The sending router builds the packet in this order: 1. A packet from `10.1.0.5` to `10.2.0.9` is routed, by OSPF's route, into the tunnel interface. 2. GRE adds its header and the outer IPv4 header `198.51.100.1` → `203.0.113.2`, protocol 47. 3. That outer packet matches the one SPD entry — next-layer protocol 47 between the two public addresses — and IPsec applies ESP. 4. On the wire the observer sees IPv4 protocol **50** (ESP) between the two public addresses, or ESP inside UDP if a NAT sits between them. 5. Branch B reverses the steps: ESP is authenticated and decrypted, GRE is removed, and the inner packet is forwarded on its own destination. Because the GRE endpoints are also the IPsec endpoints, many designs use IPsec transport mode here; tunnel mode would add a second outer IP header. Choosing between the modes is IPsec's own subject. | Need | Policy-based IPsec alone | GRE alone | GRE over IPsec | |---|---|---|---| | OSPF adjacency and multicast | No | Yes | Yes | | New subnet without a policy change | Usually not | Yes | Yes | | Confidentiality and peer authentication | Yes | No | Yes | RFC 2890 makes the pairing a requirement in one case: when the GRE Sequence Number field is used, ESP or AH **MUST** protect the GRE header, because forged sequence numbers can deny service. ## What it costs - **Overhead.** GRE adds 24 bytes over IPv4 before ESP adds its own, so the tunnel's IP MTU and TCP MSS have to come down. - **Two layers to operate.** A fault can live in the IPsec security associations, in GRE reachability or in OSPF; each is checked separately. - **NAT.** GRE has no ports, so a port-translating NAT cannot multiplex it; once it is inside ESP, getting through a translator is the IPsec layer's problem. - **Routing hygiene.** The tunnel's own endpoint addresses must stay reachable through the underlay, never through OSPF over the tunnel. ## The boundary of the answer A route-based IPsec design that gives the security association its own interface is the other common answer to "run a routing protocol over IPsec"; it is a separate design with its own trade-offs. The point here is the division of labour: GRE is transport for anything, IPsec is protection for one unicast flow.
- In GRE over IPsec, what changes in the IPsec policy when a third LAN is added behind Branch B?Nothing. The policy selects IP protocol 47 between the two public addresses, so any subnet routed into the GRE tunnel is already covered. OSPF advertises the new LAN across the tunnel and both routers learn it, with no change to selectors or security associations.
- Does any GRE RFC make IPsec mandatory?Only in one case. RFC 2784 does not require it. RFC 2890 says that when the Sequence Number field is used, ESP or AH MUST protect the GRE header, because forged sequence numbers can be injected to deny service. It also notes that the Key field provides no security.
- What does an on-path observer see of GRE over IPsec between the two branches?Outer IPv4 packets with protocol 50, ESP, between the two public addresses (ESP inside UDP port 4500 if NAT traversal is in use). The GRE header, the OSPF updates, the inner addresses and the data are encrypted. Packet sizes, timing and volume remain visible.
saying these in an interview costs you the question
- ESP cannot protect a multicast packet under any circumstances, which is why GRE is needed.
- GRE is added because it supplies encryption that the IPsec tunnel lacks.
- The IPsec policy still has to list every branch subnet pair once GRE is inside it.
- With GRE over IPsec, OSPF hellos cross the internet to 224.0.0.5 in clear.
- Running GRE inside IPsec costs nothing beyond what IPsec alone costs.