Featured image

Table of Contents Link to heading

VPN Overlay Architecture Link to heading

A VPN creates a private logical network over an untrusted transport — typically the internet. The two technologies involved serve distinct roles:

  • GRE provides the tunnel overlay: it encapsulates any routed protocol (including multicast and routing protocol hellos) as unicast packets that can traverse the internet
  • IPsec provides the encryption: it protects the GRE packets in transit, ensuring confidentiality, integrity, and peer authentication

GRE alone provides no security. IPsec alone cannot carry multicast or non-IP traffic. Combined, GRE over IPsec provides an encrypted, routing-protocol-capable site-to-site tunnel.

GRE Tunnels Link to heading

Info
A GRE tunnel creates a virtual point-to-point link between two routers across an IP network, allowing routing protocols, multicast, and private IP addresses to traverse the public internet as if they were on a directly connected link.

When a router encapsulates a packet for a GRE tunnel, it adds:

  • An outer IP header with the tunnel endpoint’s public IP as the destination
  • A GRE header (protocol 47) identifying the encapsulated payload type

The original packet is preserved intact. When the packet reaches the remote tunnel endpoint, the outer IP and GRE headers are stripped and the original packet is forwarded normally.

GRE Configuration Link to heading

Example

Topology:

R1 =====( Internet )===== R2

R1 WAN: 100.1.1.1       R2 WAN: 200.1.1.1
R1 Tunnel: 10.10.10.1/30  R2 Tunnel: 10.10.10.2/30

Router R1:

interface Tunnel0
 ip address 10.10.10.1 255.255.255.252
 tunnel source 100.1.1.1
 tunnel destination 200.1.1.1
 tunnel mode gre ip

Router R2:

interface Tunnel0
 ip address 10.10.10.2 255.255.255.252
 tunnel source 200.1.1.1
 tunnel destination 100.1.1.1
 tunnel mode gre ip

Run OSPF across the tunnel:

router ospf 1
 network 10.10.10.0 0.0.0.3 area 0

Verify:

show ip interface brief | include Tunnel
show interfaces tunnel0
show ip route

Recursive Routing: The Most Common GRE Failure Link to heading

Warning

Recursive routing occurs when the tunnel destination (the underlay IP) is learned via the tunnel itself — causing the router to route the tunnel destination through the tunnel, which collapses the tunnel.

Symptoms: tunnel interface flaps between up/up and up/down, or the tunnel never comes up. Fix: ensure the route to the tunnel destination comes from the underlay routing table (static route or IGP), never from a protocol running over the tunnel.

The safest approach is to use a static route for the tunnel destination pointing to the WAN interface, which takes precedence over any dynamically learned route.

IPsec Security Framework Link to heading

Info
IPsec is an IETF framework of open standards for building cryptographically secure VPNs. It operates at Layer 3, encrypting and authenticating IP packets before transmission.

IPsec Security Services Link to heading

Service Description Algorithms
Peer authentication Verifies the identity of the remote VPN endpoint PSK, Digital certificates (PKI)
Confidentiality Encrypts payload — plaintext becomes ciphertext AES-128, AES-256, 3DES
Integrity Detects in-transit tampering SHA-1, SHA-256, SHA-384
Anti-replay Assigns sequence numbers to prevent replay attacks Sequence number window

AH vs ESP Link to heading

Header Protocol Services
AH IP 51 Authentication + integrity only, no encryption
ESP IP 50 All four services — authentication, encryption, integrity, anti-replay

ESP is used in virtually all production deployments. AH is rarely used because it does not provide encryption and is incompatible with NAT (it authenticates the outer IP header, which NAT modifies).

Tunnel Mode vs Transport Mode Link to heading

Mode What is encrypted Overhead Use case
Tunnel Entire original IP packet Higher Standalone IPsec (no GRE)
Transport Payload only, GRE header used for routing Lower GRE over IPsec (preferred)

When using GRE over IPsec, transport mode is preferred — the GRE header is used for routing and only the GRE payload needs to be encrypted, reducing overhead compared to tunnel mode which would add a second IP header.

IKE: Key Exchange and Security Association Negotiation Link to heading

Info
IKE (Internet Key Exchange) authenticates VPN peers and establishes Security Associations (SAs) — the negotiated parameters that define how the IPsec session will operate. IKE uses UDP port 500 (and UDP 4500 for NAT traversal).

IKEv1 Phase 1 — ISAKMP SA Link to heading

Phase 1 authenticates the peers and creates a bidirectional ISAKMP SA (management tunnel) through which Phase 2 negotiation occurs securely.

Negotiated parameters:

  • Encryption algorithm (AES, 3DES)
  • Hash/integrity algorithm (SHA, MD5)
  • Authentication method (pre-shared key, RSA signatures)
  • Diffie-Hellman group (DH group 14+ recommended — group 2 is deprecated)
  • SA lifetime

Exchange modes:

  • Main Mode (MM): 6 messages, peer identities are encrypted — use in production
  • Aggressive Mode (AM): 3 messages, identities exchanged in cleartext — avoid in production

IKEv1 Phase 2 — IPsec SA Link to heading

Phase 2 uses the ISAKMP SA from Phase 1 to negotiate unidirectional IPsec SAs for the actual data encryption.

Negotiated parameters:

  • Encapsulation protocol (ESP or AH)
  • Encryption and hash algorithms (transform set)
  • Tunnel or transport mode
  • SA lifetime (time and/or bytes)

Exchange mode: Quick Mode (QM) — 3 messages, always encrypted within the Phase 1 tunnel.

Note
Each IPsec SA is unidirectional — one for inbound traffic, one for outbound. Phase 2 always creates SAs in pairs.

GRE over IPsec Configuration Link to heading

GRE over IPsec can be configured using crypto maps (legacy, applied to the WAN interface) or IPsec profiles (modern, applied directly to the tunnel interface). IPsec profiles are preferred for new deployments.

Example

Topology:

R1 WAN: 100.1.1.1   R2 WAN: 200.1.1.1
Tunnel: R1=10.10.10.1/30, R2=10.10.10.2/30

Method 1: Crypto Maps (Legacy) Link to heading

Example

Step 1 — IKE Phase 1 (both routers):

crypto isakmp policy 10
 encryption aes 256
 hash sha256
 authentication pre-share
 group 14
 lifetime 86400

crypto isakmp key CiscoKey123 address 200.1.1.1   ! R1 points to R2
! On R2: crypto isakmp key CiscoKey123 address 100.1.1.1

Step 2 — IKE Phase 2 transform set:

crypto ipsec transform-set TS esp-aes 256 esp-sha256-hmac
 mode transport

Step 3 — ACL to match interesting traffic (GRE only):

! On R1:
access-list 100 permit gre host 100.1.1.1 host 200.1.1.1
! On R2:
access-list 100 permit gre host 200.1.1.1 host 100.1.1.1

Step 4 — Crypto map:

! On R1:
crypto map GRE-IPSEC 10 ipsec-isakmp
 set peer 200.1.1.1
 set transform-set TS
 match address 100

Step 5 — Apply to WAN interface:

interface GigabitEthernet0/0
 crypto map GRE-IPSEC

Step 6 — GRE tunnel interface:

interface Tunnel0
 ip address 10.10.10.1 255.255.255.252
 tunnel source 100.1.1.1
 tunnel destination 200.1.1.1
 tunnel mode gre ip

Method 2: IPsec Profiles (Preferred) Link to heading

IPsec profiles bind directly to the tunnel interface, eliminating the need for a separate ACL to define interesting traffic — all GRE traffic on the tunnel is automatically protected.

Example

Step 1 — IKE Phase 1:

crypto isakmp policy 10
 encryption aes 256
 hash sha256
 authentication pre-share
 group 14

crypto isakmp key CiscoKey123 address <peer-wan-ip>

Step 2 — Transform set:

crypto ipsec transform-set TS esp-aes 256 esp-sha256-hmac
 mode transport

Step 3 — IPsec profile:

crypto ipsec profile GRE-PROFILE
 set transform-set TS

Step 4 — GRE tunnel with profile applied:

interface Tunnel0
 ip address 10.10.10.1 255.255.255.252
 tunnel source 100.1.1.1
 tunnel destination 200.1.1.1
 tunnel mode gre ip
 tunnel protection ipsec profile GRE-PROFILE

Verification:

show crypto isakmp sa
show crypto ipsec sa
show interfaces tunnel0
show ip route

show crypto isakmp sa should show QM_IDLE for an established Phase 1 SA. show crypto ipsec sa shows encaps/decaps counters — incrementing values confirm encrypted traffic is flowing through the tunnel.