Point-to-Point Generic Routing Encapsulation ( GRE ) over IP Security ( IPSEC )

Numerous technologies are available to connect remote branch sites to HQ or central hub. P2P Generic Routing Encapsulation ( GRE ) over IPSEC is an alternative design to classic WAN technologies, such as ATM, Frame Relay and Leased lines. GRE over IPSEC is a common deployment model to connect a number of remote branch sites to one or more central site.

Design topologies include Hub-and-Spoke, Partial mesh, and Full mesh. Both partial and full mesh topologies experience limitations by routing protocol support. A full mesh design is limited by the overhead required to support a design with a full mesh of tunnels. Following a full mesh requirement, a popular design option would be to deploy Dynamic Multipoint VPN ( DMVPN ). Regarding the context of direct connectivity from branch to hub only, Hub-and-Spoke is by far the most common design.


Head-end Architectures – Single Tier and Dual Tier

Head-end architectures include a Single Tier Head-end were both the p2p GRE and crypto functionality co-exist on the same device. Dual Tier designs is where the p2p GRE and crypto functionality are not implemented on the same device. Dual tier designs, the routing and GRE control planes are located on one device while the IPSEC control plane is housed on another.


Headend Architecture

Headend Architecture


Headend Router Crypto Crypto IP GRE GRE IP Tunnel Protection
Single Tier Headend Static or dynamic Static p2p GRE static Static Optional
  Branch Static Static or dynamic p2p GRE static Static Optional
Dual Tier Headend Static or dynamic Static p2p GRE static Static Not Valid
  Branch Static Static or dynamic p2p GRE static Static Not Valid


“Tunnel protection” requires the same source and destination IP address for both the GRE tunnel and the crypto tunnel. Implementations of dual tier separates these functions resulting in different IP address for GRE tunnel and the crypto tunnel. Tunnel protection is invalid with dual tier mode.


Preliminary Design Considerations

Diverse multi-protocol traffic requirements force the use of a Generic Routing Encapsulation ( GRE ) envelope within the IPSEC tunnel. The p2p GRE tunnel is encrypted inside the IPSEC crypto tunnel. Native IPSEC is not multi-protocol and has no support IP multicast or broadcast traffic. As a result, proper propagation of routing protocol control packets cannot take place in a native IPSEC tunnel. OSPF design cases are available where you can run OSPF network type non-broadcast and explicitly configure the remote OSPF neighbors, resulting in OSPF over the IPSEC tunnel without GRE.

With a p2p GRE over IPsec design, all traffic between hub and branch sites is firstly encapsulated in the p2p GRE packet BEFORE the encryption process takes place.

Generic Routing Encapsulation

Generic Routing Encapsulation


Redundant design are implemented with the branch having two or more tunnels to the campus head. The head-end routers can be geographic separated or co-located. Routing protocols are used with redundant tunnels providing high availability with dynamic path selection. The head-end router can either propagate a summary route ( ) or a default route ( ) to the branch sites and a preferred routing metric will be used for the primary path.  If OSPF is RP, head-end selection is based on OSPF costs.


Recursive Routing

Each branch will have to add a static route for each head-end to their respective ISP IP addresses. The static avoid recursive routing through the p2p GRE tunnel. Recursive routing takes place when the route to GRE tunnel source outside IP address of the opposing router is learned via a route with a next hop of the inside IP address of the opposing p2p GRE tunnel. Recursive routing causes the tunnel to flap and the p2p GRE packets to route into its own p2p GRE tunnel.


%TUN-5-RECURDOWN: Tunnel0 temporarily disabled due to recursive routing


To overcome recursive routing, my best practice is to ensure that the outside the tunnel is routed directly to ISP instead of inside the p2p GRE tunnel.


Split Tunneling

If the head-end advertises a summary route to the branch, split tunneling is enabled on all packets that are not destined for the summary. Any packets that are not destined for the summary are split-tunneled to the Internet. In a design that the head-end router advertises a default route ( ) through the p2p GRE tunnel; split tunneling is not used for the branch sites.


Control Plane

Routing protocol HELLO packets initiated from the branch office force the tunnel to establish. Routing protocol control plane packets are used to maintain and keep the tunnel up. HELLO packets provide a similar function to GRE keepalives. Routing protocol HELLO operates at Layer 3 and GRE keepalives at Layer 2.


Branch Router Considerations

The branch router can have p2p GRE over IPSEC with a static public address or dynamic public address. With a static public IP address both the GRE and crypto tunnels are sourced from a static address. With dynamic address allocation, the GRE sourced from a loopback address that is privately assigned ( nonroutable ) and the crypto tunnel sourced from a dynamically assigned public IP address.


Key Design Points:


  • Deploy IPSEC in tunnel mode for flexibility with NAT. Tunnel mode, which is the default mode adds an additional 20 bytes to the total packet size. However, transport mode does not work with when the crypto tunnel transitions either a NAT or PAT device.


  • With GRE IPSEC tunnel mode, the entire GRE packet ( which includes the original IP header packet ) is encapsulated and encrypted. No part of the GRE tunnel is exposed.


  • Use routing protocols for dynamic redundancy but scaling routing protocols can affect CPU overhead. Keep in mind that a higher-end limit to the number of routing protocol peers.


  • Implement GRE for routing protocol support. GRE requires that additional headers are added to the beginning of each packet; the header must also be encrypted hence affecting performance of a router.


  • GRE is stateless and by default offers limited flow control mechanisms.


  • Configure redundant tunnels for high availability but with scalability limitations. For example, P2P GRE limited to 2047 tunnels with VPN SPA and 2000 tunnels with SUP720.


  • Implement Triple DES ( 3DES ) or AES for encryption of transmitted data. Little or no variation in the performance of these even considering AES has a wider key length.


  • Implement Dead Peer Detection ( DPD ) to detect loss of ISAKMP peer. Alternatively, IPSEC tunnel protection can be considered for single-tier head architecture.


  • Hardware accelerated encryption is useful to protect the routers CPU from intensive processing.


  • Set the local Maximum Transmission Unity ( MTU ) and Path MTU to minimize fragmentation.


  • For a small number of sites, one can use pre-shared keys for tunnel authentication. Large deployments look into Digital Certificates / PKI.


  • Keep CPU at head-end and branch sites around the 65% – 80% mark.









About Matt Conran

Matt Conran has created 184 entries.

Leave a Reply