Skip to content
Log in Sign up My account

3.2 Site-to-Site VPN Design

Blueprint 3.2: Site-to-site VPN

  • 3.2.a DMVPN
  • 3.2.b Layer 2 VPN
  • 3.2.c MPLS Layer 3 VPN
  • 3.2.d IPsec
  • 3.2.e Generic Routing Encapsulation (GRE)
  • 3.2.f Group Encrypted Transport VPN (GET VPN)

This page is about picking the right VPN technology for a set of sites. The mechanics of GRE, IPsec, DMVPN and L3VPN are covered in ENCOR and ENARSI, so use these pages for the how and spend this page on the why:

The building blocks and what each one gives you

Technology Encapsulates Encrypts Carries multicast and routing protocols Scales to many sites
GRE Yes (IP in IP, protocol 47) No Yes Poor alone: one tunnel per pair
IPsec (VTI or crypto map) Yes Yes Crypto map: unicast IP only. VTI: yes Poor alone: one SA set per pair
GRE over IPsec Yes Yes Yes Same as GRE
DMVPN (mGRE + NHRP + IPsec) Yes Optional but standard Yes Good: spokes need no per-peer config
GET VPN No (keeps the original IP header) Yes Yes, because the header is the original Good on private WANs
MPLS L3VPN Label stack No (provider isolation only) Via PE-CE routing Provider scale
Layer 2 VPN Ethernet over pseudowire or EVPN No Transparent Limited by Layer 2 domain size

Remember the division of labour. GRE gives you a pipe that carries anything. IPsec gives you confidentiality and integrity. Neither one gives you automatic any-to-any connectivity. DMVPN adds the dynamic part. GET VPN removes the tunnels completely.

IPsec design points

  • IKEv2 over IKEv1 for new designs. IKEv2 has fewer messages, built-in NAT traversal, dead peer detection, and is the base of FlexVPN.
  • Tunnel mode hides the original IP header. When you add GRE under IPsec, you can use transport mode to save the extra outer header, which is the usual choice on DMVPN.
  • Overhead: GRE adds 24 bytes (outer IP 20 plus GRE 4). ESP adds more, depending on cipher and mode. Plan the tunnel MTU and TCP MSS. A tunnel MTU of 1400 with MSS 1360 is a common starting point. The mechanics are in ENCOR GRE and IPsec.
  • Throughput: encryption is the bottleneck on routers. Size the headend to the encrypted throughput, and check the number of tunnels the platform supports, not just the interface speed.
  • Crypto map vs tunnel protection: crypto maps need an ACL per peer and do not carry routing protocols natively. Use virtual tunnel interfaces (VTI) for new designs because they behave like normal interfaces.

DMVPN design

DMVPN is the standard answer for "many sites, mostly hub-and-spoke, some spoke-to-spoke, over the Internet or any IP transport, with dynamic addressing at the spokes".

Phase Spoke-to-spoke path Routing at spokes Design implication
1 Never. All traffic via hub. Hub can send a default or summary. Simple, hub carries everything.
2 Direct, learned through NHRP resolution. Spokes need specific routes with the next hop preserved. No hub summarisation. Scale limited by routing table.
3 Direct, triggered by NHRP redirect and shortcut. Hub can summarise or send default. Best scaling. Preferred for new designs.

Scaling and resilience choices:

  • Dual hub, single cloud: two hubs on the same DMVPN network. Simple, but one misconfigured tunnel or one transport failure affects both.
  • Dual hub, dual cloud: one DMVPN per transport (for example MPLS and Internet), each with its own hubs. This is the classic hybrid WAN pattern.
  • Routing protocol: EIGRP and BGP are the common choices. OSPF is harder to scale on DMVPN because of its network type requirements (point-to-multipoint or broadcast with DR placement at the hub). For a large DMVPN, iBGP with route reflectors at the hubs or dynamic neighbours scales best.
  • Spoke-to-spoke traffic: the first packet goes via the hub. Latency-sensitive applications can see a short delay or a first-packet drop while the direct tunnel forms.
graph TB
  H1["Hub 1<br/>MPLS cloud"]
  H2["Hub 2<br/>Internet cloud"]
  S1["Spoke 1"]
  S2["Spoke 2"]
  S3["Spoke 3"]
  S1 --- H1
  S1 --- H2
  S2 --- H1
  S2 --- H2
  S3 --- H1
  S3 --- H2
  S1 -. "phase 3 shortcut" .- S2

GET VPN

Group Encrypted Transport VPN solves a different problem: encrypting a private WAN that is already any-to-any, such as an MPLS L3VPN, without turning it into a tunnel mesh.

Element Role
Key server (KS) Authenticates group members, creates and distributes the group keys and the policy (which traffic to encrypt)
Group member (GM) The CE or router that encrypts and decrypts using the keys from the KS
GDOI The group key management protocol (RFC 6407), UDP 848
KEK / TEK Key encryption key protects rekey messages. Traffic encryption key protects data
COOP Cooperative key servers: a primary and secondary for redundancy

Key properties:

  • No tunnels and no peer-to-peer IKE. All members share a group SA, so any-to-any is native and there are no per-pair negotiations.
  • IP header preservation. The packet keeps its original source and destination in the outer header. The provider's routing and QoS see the real addresses and DSCP, so the L3VPN network still routes and prioritises as normal. This is also why GET VPN does not work across the public Internet: the original (usually private) addresses must be routable in the underlay.
  • Multicast works natively because the original multicast group is in the header.
  • Time-based anti-replay is used, so members need accurate time (NTP).
  • The key server is a control-plane dependency. If members cannot reach a KS when keys expire, they stop encrypting and can fail to forward. Deploy at least two KS (COOP) in different locations.
! Group member sketch
crypto gdoi group GETVPN-GRP
 identity number 1234
 server address ipv4 10.0.0.1
 server address ipv4 10.0.0.2
!
crypto map GETVPN-MAP 10 gdoi
 set group GETVPN-GRP
!
interface GigabitEthernet0/0/0
 crypto map GETVPN-MAP

R1# show crypto gdoi
GROUP INFORMATION
    Group Name               : GETVPN-GRP
    Group Identity           : 1234
    Registered with          : 10.0.0.1
    Rekeys received          : 3

Choosing between them

graph TD
  Q1{"Is the WAN private<br/>and any-to-any already?"}
  Q1 -- "Yes, need encryption" --> G["GET VPN"]
  Q1 -- "No, Internet or mixed" --> Q2{"Many sites<br/>with spoke-to-spoke?"}
  Q2 -- "Yes" --> D["DMVPN phase 3"]
  Q2 -- "No, few sites" --> I["GRE over IPsec or IPsec VTI"]
  Q1 -- "Need Layer 2 adjacency" --> L["Layer 2 VPN<br/>or EVPN"]
  Q1 -- "Provider-managed routing" --> M["MPLS L3VPN"]
Requirement Best fit
Encrypt an existing MPLS L3VPN with minimum change and keep provider QoS GET VPN
200 branches over the Internet, dynamic spoke IPs, occasional spoke-to-spoke voice DMVPN phase 3 with IPsec
Two data centres and one DR site, routing protocols needed, simple GRE over IPsec or IPsec VTI
Layer 2 adjacency between two data centres Layer 2 VPN or EVPN
Provider manages routing, any-to-any, QoS classes MPLS L3VPN
Application-aware path selection across mixed transports SD-WAN (see 3.4)

Failure modes to design for

  • Recursive routing: the tunnel destination learned through the tunnel brings the tunnel down. Keep the underlay in a separate VRF (front-door VRF) or filter the routes. See ENCOR GRE and IPsec.
  • MTU black holes: large packets with DF set vanish when ICMP is filtered. Set tunnel MTU and TCP MSS.
  • Headend overload: a single hub with thousands of IPsec sessions can fail at rekey time. Use multiple hubs and spread the load with server load balancing or a hub-per-region design.
  • Key server unreachable (GET VPN): see above. Use COOP and keep a KS reachable from every member.

Exam trap

GET VPN preserves the original IP header and uses no tunnels. It is the wrong answer for "encrypt traffic over the Internet" because the private source and destination addresses must be routable in the underlay. It is the right answer for "encrypt an MPLS WAN without breaking provider QoS or multicast".

Exam trap

DMVPN phase 1, 2 and 3 differ in where the spoke-to-spoke decision is made. Phase 3 is the only phase where the hub can send a summary or default route and spokes still build direct tunnels, because NHRP redirect and shortcut install the specific route. A scenario asking for good scale with spoke-to-spoke traffic points to phase 3.

Exam trap

IPsec by itself with a crypto map cannot carry a routing protocol that uses multicast, such as OSPF or EIGRP hellos. Add GRE, or use a VTI. That is the usual reason a design uses GRE over IPsec.

Design exercise

Scenario. A manufacturer has 150 plants connected to an MPLS L3VPN from one provider. Audit now requires encryption of all inter-plant traffic. The plants run voice between each other, and the provider's QoS classes map to DSCP markings today. Multicast is used for a plant-floor application. The team wants minimal change to routing and does not want a tunnel mesh. Ten plants also have a backup Internet circuit.

Requirements and constraints.

  • Encrypt MPLS traffic.
  • Keep provider QoS and multicast working.
  • No per-site peer configuration.
  • Internet backup sites must keep working if MPLS fails.
Model answer
  • Over MPLS: deploy GET VPN with two key servers in COOP at different data centres. GET VPN encrypts any-to-any with one group policy, keeps the original header so the provider still sees the DSCP markings, and supports multicast natively. No tunnels are needed.
  • Over the Internet backup at ten plants: GET VPN is not suitable on the Internet because it needs the original addresses to be routable. Use a DMVPN (or IPsec VTI to the data centre) on the Internet circuits only. Routing prefers the MPLS path and falls back to the tunnel.
  • Rejected: a full DMVPN over the MPLS network would replace a working any-to-any network with a hub-controlled overlay and require tunnel configuration and MTU work at all 150 sites. Per-pair IPsec would not scale. An L2 VPN does not address encryption.
  • Operational note: keep NTP accurate for GET VPN anti-replay and monitor KS reachability.

Quick check

Why does GET VPN work well over MPLS L3VPN but not over the Internet?

GET VPN keeps the original source and destination IP addresses in the outer header. A private MPLS network can route those addresses. The Internet cannot route a customer's private addresses, so the traffic would be dropped. Over the Internet you need a tunnelling technology that adds a new outer header, such as DMVPN or IPsec VTI.

A DMVPN uses OSPF and has 400 spokes. What is the design concern?

OSPF needs a network type that suits the multipoint cloud. Broadcast type requires the hub to be the DR and spokes to have priority 0. Point-to-multipoint scales less well and limits per-spoke policy. EIGRP or BGP are better at this scale because they handle many neighbours and summarisation more simply.

What must you add to plain IPsec so that EIGRP can run between two sites?

A crypto map carries only unicast IP traffic that matches the ACL. EIGRP hellos use multicast, so either run it over GRE protected by IPsec or use an IPsec virtual tunnel interface.

References