Computer NetworksVirtual Private Networks

Virtual Private Networks (VPN)

LevelIntermediate

Duration60 mins

TopicVirtual Private Networks

2 / 5

Site-to-Site VPN

Connecting Distributed Networks as One

Consider a retail corporation with 500 stores across the country, each with point-of-sale systems, inventory management computers, and employee workstations. Every transaction must reach the central data center for processing. Every inventory update must synchronize with corporate systems. Every employee in every store needs access to corporate email, HR systems, and training portals.

Now imagine deploying 500 individual remote access VPN connections—managing thousands of client configurations, handling user credentials for tens of thousands of employees, and troubleshooting connectivity issues when individual laptops misconfigure their VPN settings. The operational burden would be crushing.

Site-to-site VPN solves this problem by shifting the VPN termination point from individual user devices to network infrastructure. Instead of 500 stores each having employees with VPN clients, 500 stores each have a single VPN gateway that secures all traffic from that location. The network itself becomes the VPN participant, transparently protecting every device without requiring per-device configuration.

This architectural pattern—connecting networks rather than users—is fundamental to enterprise infrastructure. It enables unified corporate networks spanning continents, disaster recovery sites that mirror primary data centers, and cloud environments that extend on-premises networks into AWS, Azure, or GCP regions.

What You Will Learn

By the end of this page, you will understand site-to-site VPN architecture in depth: the topologies that connect multiple sites, routing protocols that work over VPN tunnels, high availability designs that prevent single points of failure, MTU considerations that affect performance, and practical implementation details that distinguish reliable deployments from fragile ones.

Site-to-Site VPN Architecture

Site-to-site VPN connects two or more networks through encrypted tunnels, making geographically distributed locations appear as a single logical network. Unlike remote access VPN where individual users initiate connections, site-to-site VPN tunnels are typically established between VPN gateways—dedicated devices or software services that handle encryption, decapsulation, and routing for all traffic between sites.

Core Architectural Components

VPN Gateway/Concentrator: At each site, a VPN gateway device terminates the VPN tunnel. This could be:

A dedicated VPN appliance (Cisco ASA, Palo Alto, Fortinet FortiGate)
A router with VPN capabilities (Cisco IOS router with crypto maps)
A firewall with integrated VPN (pfSense, OPNsense)
Cloud provider virtual network gateways (AWS VPN Gateway, Azure VPN Gateway)

Tunnel Configuration: Each tunnel requires matching configuration on both endpoints:

Encryption algorithms (AES-256-GCM, ChaCha20-Poly1305)
Authentication methods (pre-shared keys, RSA certificates)
Key exchange parameters (IKEv2 with specific Diffie-Hellman groups)
Traffic selectors (which subnets/networks the tunnel protects)

Routing: Site-to-site VPN requires routing configuration so that traffic destined for remote networks is directed into the VPN tunnel:

Static routes pointing remote subnets to the tunnel interface
Dynamic routing protocols (OSPF, BGP) running over the tunnel
Policy-based routing for more complex scenarios

Converting Mermaid diagram...

Traffic Flow in Site-to-Site VPN

Let's trace a packet from a workstation in Branch Office 1 (IP: 10.2.1.50) to a server at Headquarters (IP: 10.1.1.100):

Original Packet Creation: The workstation creates a packet with source 10.2.1.50, destination 10.1.1.100
Routing Decision: The branch router examines the destination. Route table shows 10.1.0.0/16 via VPN tunnel interface.
VPN Gateway Processing: The packet reaches the branch VPN gateway (198.51.100.1)
Encryption & Encapsulation: The gateway:
- Encrypts the entire original IP packet
- Adds ESP header and trailer
- Creates new outer IP header: Source 198.51.100.1, Destination 203.0.113.1
Internet Transit: The outer packet routes through the Internet normally—no device can read the encrypted payload
Termination at Headquarters: HQ gateway (203.0.113.1) receives the packet
Decryption & Decapsulation: HQ gateway verifies integrity, decrypts payload, strips outer headers
Local Delivery: Original packet (10.2.1.50 → 10.1.1.100) is routed to the destination server

Return traffic follows the same process in reverse, with HQ encrypting replies and Branch decrypting them.

Transparent to End Devices

A key advantage of site-to-site VPN: end devices (workstations, servers, printers) require no special configuration. They're unaware that traffic crosses an encrypted tunnel. This drastically simplifies deployment compared to installing VPN clients on every device.

Site-to-Site VPN Topologies

When connecting multiple sites, the topology—how tunnels interconnect sites—has profound implications for performance, resilience, management complexity, and cost. Understanding topology options is essential for designing effective VPN architectures.

Hub-and-Spoke Topology

In hub-and-spoke (also called star topology), all branch sites connect only to a central hub site. Inter-branch traffic routes through the hub:

          [Branch A]----\
                         \____[Hub]____/----[Branch B]
          [Branch C]----/

Characteristics:

Central hub handles all encryption/decryption for inter-branch traffic
Branch-to-branch communication requires two hops (Branch A → Hub → Branch B)
Simplest configuration: N sites require N-1 tunnels
Central management and policy enforcement

Advantages:

Minimum tunnel count: N-1 tunnels for N sites
Simplified management: all configuration centers on hub
Easy policy enforcement: all traffic flows through central point
Lower cost: branches need only support single tunnel

Disadvantages:

Hub becomes critical single point of failure
Hub capacity limits total throughput
Suboptimal routing: geographically close branches route through distant hub
Latency doubles for inter-branch traffic

Converting Mermaid diagram...

Full Mesh Topology

In full mesh topology, every site has a direct tunnel to every other site:

          [Branch A]----[Branch B]
            |    \    /    |
            |     \  /     |
            |      \/      |
            |      /\      |
            |     /  \     |
          [Branch C]----[Hub D]

Characteristics:

N sites require N×(N-1)/2 tunnels
Any-to-any communication in single hop
No central bottleneck
Complex configuration

Advantages:

Optimal routing: direct paths between all sites
No single point of failure (for connectivity, though other issues may apply)
Best latency for site-to-site traffic
No central bottleneck limiting throughput

Disadvantages:

Tunnel count explodes: 10 sites = 45 tunnels; 50 sites = 1,225 tunnels; 100 sites = 4,950 tunnels
Configuration complexity grows geometrically
Every gateway must maintain many tunnels simultaneously
Changes (adding/removing sites) require touching multiple devices

Partial Mesh Topology

Partial mesh is a pragmatic compromise—some sites connect directly while others route through hubs:

Regional hubs connect to central hub (hub-and-spoke at the macro level)
Sites within a region connect in mesh (full mesh at micro level)
Critical site pairs get direct tunnels regardless of hierarchy

This approach balances tunnel count, performance, and management complexity.

Topology Comparison for Site-to-Site VPN
Topology	Tunnels for N Sites	10 Sites	50 Sites	100 Sites	Complexity	Resilience
Hub-and-Spoke	N - 1	9	49	99	Low	Single hub failure = total outage
Full Mesh	N×(N-1)/2	45	1,225	4,950	Very High	Highly resilient
Partial Mesh	Varies	~15-25	~100-300	~200-500	Medium	Regional failures possible
Dual Hub	~2×(N-1)	18	98	198	Medium	Good with hub redundancy

DMVPN: Dynamic Multipoint VPN

Cisco's Dynamic Multipoint VPN (DMVPN) technology addresses the mesh scalability problem through dynamic tunnel creation:

All spokes register with a hub using NHRP (Next Hop Resolution Protocol)
Initial traffic between spokes routes through hub
When spoke-to-spoke traffic demand detected, NHRP resolves the direct path
Spokes dynamically create direct IPSec tunnels as needed
Direct tunnels tear down after inactivity timeout

DMVPN provides full mesh connectivity benefits with hub-and-spoke configuration simplicity:

Configure spoke once (to register with hub)
No spoke-to-spoke preconfiguration needed
Tunnels created on-demand
Scales to thousands of sites

Similar solutions exist from other vendors (ADVPN from various vendors, SD-WAN solutions), all solving the same fundamental problem of mesh scalability.

Topology Selection Criteria

Choose hub-and-spoke for small deployments or when central policy enforcement is critical. Use full mesh only for a handful of sites that genuinely need optimal direct paths. For most enterprise deployments, partial mesh or dynamic mesh solutions (DMVPN, SD-WAN) provide the best balance of performance, manageability, and resilience.

Routing Over VPN Tunnels

Site-to-site VPN requires routing configuration that directs traffic destined for remote networks into VPN tunnels. The choice between static and dynamic routing has significant operational implications.

Static Routing

With static routing, administrators manually configure routes pointing remote subnets to the VPN tunnel interface:

! Example Cisco IOS static route
ip route 10.2.0.0 255.255.0.0 Tunnel0
ip route 10.3.0.0 255.255.0.0 Tunnel0

Advantages:

Simple to understand and implement
No routing protocol overhead
Predictable behavior
Works with any VPN technology

Disadvantages:

Doesn't adapt to network changes
Manual updates required when subnets added
No automatic failover if tunnel goes down (unless combined with object tracking)
Doesn't scale well for many subnets or sites

Dynamic Routing Over VPN

Dynamic routing protocols can run over VPN tunnels, treating the tunnel as just another network link:

OSPF over VPN:

Tunnel interfaces participate in OSPF areas
Remote routes learned automatically
Convergence when topology changes
Link-state database synchronized over tunnel

BGP over VPN:

eBGP or iBGP sessions over tunnel interfaces
Rich policy capabilities
Supports complex multi-homed scenarios
Preferred for large-scale deployments and DMVPN

EIGRP over VPN (Cisco proprietary):

Hybrid distance-vector routing
Efficient updates
Fast convergence

Dynamic Routing Benefits for VPN

•Automatic Route Discovery — When new subnets are added at remote sites, they're automatically advertised and learned. No manual route configuration needed.
•Failover and Redundancy — If a tunnel fails, routing protocols detect the failure and converge to alternate paths. Critical for high-availability designs.
•Load Balancing — Multiple tunnels between sites can share traffic load based on routing metric manipulation.
•Reduced Configuration Burden — Routing protocol configuration is typically simpler than maintaining hundreds of static routes.
•Consistent Behavior — Same routing protocols used inside the network extend over VPN, providing uniform operations.

Routing Protocol Selection

Different protocols suit different scenarios:

OSPF:

Best for: Single-organization networks, moderate scale (hundreds of routes)
Pros: Fast convergence, well-understood, multi-vendor support
Cons: Area design complexity, link-state database can grow large
Over VPN: Works well; consider tunnel as point-to-point link (OSPF network type)

BGP:

Best for: Large scale, multi-vendor, complex policies, DMVPN
Pros: Scalability, policy control, path attributes, vendor neutral
Cons: Complex configuration, slower convergence than OSPF
Over VPN: Excellent for DMVPN (where spoke-to-spoke paths need route learning)

Static with Object Tracking:

Best for: Simple deployments, few sites, stable environments
Pros: Simplicity, no protocol overhead, predictable
Cons: Manual management, limited adaptability
Object tracking adds failover capability to static routes

Route Summarization

With dynamic routing, careful summarization reduces routing table size and control plane overhead:

Each site should advertise summary routes, not individual subnets
Corporate IP addressing should enable summarization (contiguous blocks per site)
Hub sites should summarize branch routes to each other

Example: Instead of advertising 10.2.1.0/24, 10.2.2.0/24, ... 10.2.50.0/24 from Branch 1, advertise a single 10.2.0.0/16 summary.

Routing Protocol Over VPN Considerations

When running routing protocols over VPN, ensure tunnels are stable before protocol adjacencies form. Flapping tunnels cause routing instability. Also consider routing protocol timers—fast hello intervals on unstable Internet connections can cause unnecessary reconvergence. Tune timers appropriately for the underlying transport reliability.

High Availability and Redundancy

Site-to-site VPN often carries business-critical traffic. Design for high availability requires redundancy at multiple levels.

VPN Gateway Redundancy

Single VPN gateways create single points of failure. Redundancy approaches include:

Active/Passive Clustering:

Two gateways share a virtual IP address
Primary handles all traffic; standby monitors and takes over on failure
Stateful failover preserves tunnel state (on some platforms)
Simple but wastes standby capacity

Active/Active Clustering:

Both gateways handle traffic simultaneously
Traffic can be load-balanced across gateways
More efficient resource utilization
More complex configuration and state synchronization

Independent Gateways with Routing Failover:

Two separate gateways with independent tunnel sets
Routing protocols or static route metrics determine active path
No cluster configuration needed; gateways are completely independent
Failover time depends on routing convergence

Tunnel Redundancy

Even with redundant gateways, a single ISP failure can disable connectivity. Tunnel-level redundancy options:

Multiple ISPs:

Each site has connections to two or more ISPs
Tunnels established over each ISP connection
Routing selects best path; fails over on link failure

Multiple Tunnels per ISP:

Parallel tunnels with different parameters
Can provide load balancing
Limited additional resilience (ISP failure affects all)

Converting Mermaid diagram...

Dead Peer Detection (DPD)

VPN gateways need to detect when remote peers become unreachable. Dead Peer Detection is an IKE mechanism that:

Sends periodic "R-U-THERE" messages
Expects "R-U-THERE-ACK" responses
Declares peer dead after configurable failures
Triggers tunnel teardown and failover

DPD settings balance responsiveness against false positives:

Aggressive settings (5s interval, 3 retries = 15s detection)
- Fast failover but may flap on temporary congestion
Conservative settings (30s interval, 5 retries = 150s detection)
- Stable but slow failover response

Path MTU and Fragmentation

VPN encapsulation adds overhead (typically 50-80+ bytes for IPSec ESP), reducing the maximum transmission unit (MTU) for payload data:

Standard Ethernet MTU: 1500 bytes
After ESP encapsulation: ~1400-1420 bytes usable for original packet
If original packet is 1500 bytes, it won't fit after encapsulation

Solution approaches:

Pre-fragmentation:

Fragment original packet before encryption
Each fragment fits after encapsulation
TCP MSS clamping helps prevent large TCP segments

Post-fragmentation:

Encapsulate full packet, then fragment the encrypted packet
Reassembly required at receiver before decryption
Problematic with some firewalls/NATs that block fragments

Path MTU Discovery:

ICMP "Fragmentation Needed" messages inform sender
Sender reduces packet size
May be blocked by firewalls (common configuration error)

Best practice: Configure TCP MSS clamping at VPN gateways to 1360-1380 bytes, ensuring TCP-based traffic fits without fragmentation.

Testing Failover

Failover mechanisms should be tested regularly, not just during initial deployment. Schedule maintenance windows to deliberately fail primary components and verify that redundancy works as expected. Document failover times and compare against SLA requirements.

IPSec for Site-to-Site VPN

IPSec is the dominant protocol for site-to-site VPN due to its standardization, security strength, and wide vendor support. Understanding IPSec configuration for site-to-site scenarios requires grasping several interconnected concepts.

IKE (Internet Key Exchange) Phases

IPSec tunnel establishment occurs in two phases:

Phase 1 (IKE SA Establishment):

Authenticates peers to each other
Negotiates encryption parameters for Phase 2 protection
Establishes a secure channel (IKE Security Association)
Key exchange using Diffie-Hellman
Result: Encrypted, authenticated channel for Phase 2 negotiation

Phase 2 (IPSec SA Establishment):

Protected by Phase 1 IKE SA
Negotiates encryption parameters for actual data traffic
Defines traffic selectors (which traffic is protected)
Establishes IPSec Security Associations (one for each direction)
Result: Encryption keys for user traffic

IKEv1 vs. IKEv2

IKEv2 is the modern standard, offering improvements over IKEv1:

Feature	IKEv1	IKEv2
Message exchanges	6-9	4
NAT traversal	Add-on	Built-in
Dead peer detection	Add-on	Built-in
Reliability	None	Retransmission, sequence numbers
Authentication methods	Limited	Extensible (EAP support)
Rekeying	Disruptive	Seamless
MOBIKE	No	Yes (mobility support)

New deployments should always use IKEv2 unless compatibility with legacy equipment mandates IKEv1.

IPSec Site-to-Site Configuration Elements

•Peer Addresses — Public IP addresses of both VPN gateways. These are the outer IP addresses of encapsulated packets.
•Authentication — Pre-shared key (PSK) or certificates. PSK is simpler; certificates are more scalable and secure for many tunnels.
•Phase 1 Proposals — Encryption (AES-256), integrity (SHA-256/384/512), Diffie-Hellman group (14, 19, 20, 21), lifetime (typically 24 hours).
•Phase 2 Proposals — ESP encryption (AES-256-GCM), integrity (if not using authenticated encryption), PFS group, lifetime (typically 1-8 hours).
•Traffic Selectors — Source and destination network ranges that the tunnel protects. Also called "proxy IDs" or "interesting traffic".
•Dead Peer Detection — Interval and retry settings for detecting peer failure.
•NAT Traversal — UDP encapsulation settings if gateways are behind NAT (port 4500).

Policy-Based vs. Route-Based VPN

IPSec implementations fall into two architectural approaches:

Policy-Based VPN:

Traffic selectors (crypto ACLs) define what traffic is encrypted
Each traffic flow matches against policies
Multiple policies can exist for different traffic types
Implementation: Cisco crypto maps, some firewall implementations

Route-Based VPN:

Creates virtual tunnel interfaces (VTI)
Routing determines what traffic goes through tunnel
Any traffic routed to tunnel interface is encrypted
Implementation: Cisco VTI, Juniper st0 interfaces, cloud provider VPNs

Route-based is generally preferred for modern deployments because:

Dynamic routing protocols work naturally over tunnel interfaces
Simpler configuration, especially for many subnets
Better integration with DMVPN and SD-WAN solutions
Easier troubleshooting (standard routing tools work)

Example Route-Based Configuration (Cisco IOS):

! Phase 1 (IKEv2)
crypto ikev2 proposal PROP-IKEV2
  encryption aes-cbc-256
  integrity sha384
  group 19

crypto ikev2 policy POL-IKEV2
  proposal PROP-IKEV2

crypto ikev2 keyring KEYRING
  peer HQ
    address 203.0.113.1
    pre-shared-key SECURE_KEY_HERE

crypto ikev2 profile IKEV2-PROFILE
  match identity remote address 203.0.113.1
  authentication local pre-share
  authentication remote pre-share
  keyring local KEYRING

! Phase 2 (IPSec)
crypto ipsec transform-set TS esp-aes 256 esp-sha384-hmac
  mode tunnel

crypto ipsec profile IPSEC-PROFILE
  set transform-set TS
  set ikev2-profile IKEV2-PROFILE

! Tunnel Interface
interface Tunnel0
  ip address 10.255.0.2 255.255.255.252
  tunnel source GigabitEthernet0/0
  tunnel destination 203.0.113.1
  tunnel mode ipsec ipv4
  tunnel protection ipsec profile IPSEC-PROFILE

! Routing
ip route 10.1.0.0 255.255.0.0 Tunnel0

Strong Cryptographic Recommendations

For new deployments: Use AES-256-GCM (authenticated encryption), SHA-384 or SHA-512 for integrity where needed, and Diffie-Hellman Group 19 (256-bit ECC), 20 (384-bit ECC), or 21 (521-bit ECC). Avoid SHA-1, DES, 3DES, and DH Groups 1, 2, and 5 which are all considered weak or deprecated.

Cloud VPN Connectivity

Extending corporate networks to cloud environments is a critical use case for site-to-site VPN. All major cloud providers offer VPN gateway services that integrate with on-premises VPN infrastructure.

AWS VPN Solutions

AWS Site-to-Site VPN:

Customer Gateway: Your on-premises VPN device
Virtual Private Gateway (VGW) or Transit Gateway: AWS-side termination
Two tunnels per connection for redundancy (different Availability Zones)
Supports BGP for dynamic routing (recommended)
Static routing option for simpler scenarios
Up to 1.25 Gbps per tunnel (aggregate with multiple tunnels)

AWS Transit Gateway with VPN:

Centralizes connectivity for multiple VPCs
VPN attaches to Transit Gateway, not individual VPCs
Scales to thousands of VPCs and VPN connections
Supports Equal-Cost Multi-Path (ECMP) for high throughput

Azure VPN Gateway

VpnGw SKUs:

VpnGw1/2/3/4/5: Increasing throughput (650 Mbps to 10 Gbps)
Zone-redundant versions: VpnGw1AZ through VpnGw5AZ
Supports IKEv2 and OpenVPN (for point-to-site)
BGP routing with Azure Route Server for complex scenarios

Azure Virtual WAN:

Hub-and-spoke at cloud scale
Automated VPN connectivity to Azure regions
Integrates VPN, ExpressRoute, and SD-WAN

Cloud VPN Gateway Comparison
Provider	Service	Max Throughput	BGP Support	HA Mechanism
AWS	Site-to-Site VPN	1.25 Gbps/tunnel (ECMP for more)	Yes	Dual tunnels to different AZs
Azure	VPN Gateway	10 Gbps (VpnGw5)	Yes	Active-Active, Zone-redundant
GCP	Cloud VPN	3 Gbps/tunnel (8 tunnels = 24 Gbps)	Yes	HA VPN with 99.99% SLA
Oracle Cloud	IPSec VPN	250 Mbps - 10 Gbps	Yes	Dual tunnel redundancy

Google Cloud Platform (GCP) VPN

Classic VPN:

Legacy single-tunnel option
Static routing only
No SLA (being deprecated)

HA VPN:

High-availability architecture with 99.99% SLA
Two interfaces with automatic failover
BGP required for HA VPN
Supports up to 3 Gbps per tunnel, 8 tunnels per gateway

Multi-Cloud VPN Connectivity

Organizations using multiple cloud providers need to interconnect them:

Option 1: On-premises hub:

All cloud VPNs terminate on-premises
Traffic between clouds routes through on-premises
Suboptimal latency, simpler management

Option 2: Direct cloud-to-cloud:

VPN tunnels between cloud provider VPCs
AWS VPC peers with Azure VNet via IPSec
Optimal latency, more complex management
Egress charges from both clouds

Option 3: Cloud interconnect services:

Third-party providers offering multi-cloud fabric
Megaport, Equinix Fabric, PacketFabric
Private connectivity without Internet transit
Higher bandwidth than VPN

Design Considerations for Cloud VPN

IP address planning: Ensure on-premises and cloud networks use non-overlapping address ranges
NAT implications: NAT between on-premises and cloud adds complexity; plan carefully
Throughput requirements: VPN has bandwidth limits; consider dedicated connections (Direct Connect, ExpressRoute) for high-volume workloads
Latency sensitivity: VPN adds encryption overhead; very latency-sensitive applications may need dedicated connections
Cost: VPN is typically cheaper than dedicated connections, but data transfer charges apply

Cloud VPN Bandwidth Limitations

Cloud VPN gateways have throughput limits that may surprise architects accustomed to high-capacity on-premises equipment. An AWS VPN connection's 1.25 Gbps per tunnel may be insufficient for data-intensive workloads. For bulk data transfer or high-throughput requirements, consider AWS Direct Connect, Azure ExpressRoute, or GCP Dedicated Interconnect.

Operational Considerations

Deploying site-to-site VPN is only the beginning. Ongoing operations require attention to monitoring, troubleshooting, and lifecycle management.

Monitoring and Alerting

Critical metrics to monitor:

Tunnel State:

IKE Phase 1 status: Is the IKE SA established?
IKE Phase 2 status: Are IPSec SAs established?
Dead Peer Detection events: Are peers reachable?

Performance Metrics:

Throughput: Bytes/packets encrypted and decrypted
Latency: Round-trip time through tunnel
Packet loss: Encapsulation/decapsulation failures
CPU utilization: Encryption overhead on gateways

Security Events:

Authentication failures: Failed IKE authentication attempts
Replay attacks detected: Anti-replay window violations
SA expiration: Rekeying events and failures

Troubleshooting Methodology

When tunnels fail, systematic troubleshooting is essential:

Verify basic connectivity: Can gateways ping each other on public IPs?
Check IKE Phase 1: Are proposals matching? Authentication failing?
Check IKE Phase 2: Are traffic selectors matching? Transform sets compatible?
Verify routing: Are routes pointing to tunnel? Are remote subnets reachable?
Check firewall rules: Are ESP (protocol 50) and UDP 500/4500 permitted?
Review logs: What specific error messages appear during negotiation?

Common Site-to-Site VPN Problems

•Mismatched Proposals — Phase 1 or Phase 2 proposals don't match between peers. Common with multi-vendor deployments. Solution: Ensure identical encryption, integrity, DH group, and lifetime values.
•Incorrect Pre-Shared Key — Keys must match exactly, including case and whitespace. Solution: Copy-paste the same key to both devices; verify no trailing spaces.
•Traffic Selector Mismatch — Endpoints disagree on which subnets are protected. Policy-based VPNs are particularly prone to this. Solution: Ensure proxy IDs or crypto ACLs match exactly on both ends.
•NAT Traversal Issues — One gateway behind NAT, but NAT-T not enabled. Solution: Enable NAT traversal (UDP 4500) on both endpoints.
•Firewall Blocking ESP — Stateful firewalls dropping ESP packets after timeout. Solution: Ensure ESP (protocol 50) and IKE (UDP 500, 4500) are permitted.
•MTU/Fragmentation — Large packets failing after encapsulation. Solution: Implement TCP MSS clamping at 1360 bytes; ensure PMTUD works.
•Asymmetric Routing — Return traffic takes different path than outbound, bypassing VPN. Solution: Ensure routing is symmetric or VPN gateways have state sync.

Lifecycle Management

Certificate Rotation:

Certificate-based authentication requires renewal before expiration
Plan rotation well before certificates expire
Automate certificate deployment where possible
Test rotation in non-production environments first

Algorithm Upgrades:

Cryptographic algorithms become deprecated over time
SHA-1, 3DES, DH Group 2 are already weak
Plan migration to stronger algorithms
Both ends must support new algorithms before migration

Firmware/Software Updates:

VPN gateway firmware should be kept current
Security vulnerabilities are discovered periodically
Test updates in non-production before rollout
Plan maintenance windows for updates

Change Management

VPN changes require careful coordination:

Network changes at one site may require VPN updates at others
Adding subnets may require updating traffic selectors or routing
Changes should be tested in non-production if possible
Rollback procedures should be documented before changes
After-hours changes minimize business impact

Documentation Is Critical

Site-to-site VPN configurations should be meticulously documented: IP addresses, subnet ranges, authentication details (without storing actual secrets in documentation), routing configuration, and contact information for remote site administrators. During outages, good documentation reduces troubleshooting time dramatically.

Summary: Site-to-Site VPN Mastery

Site-to-site VPN is the backbone of enterprise network connectivity, securely linking geographically distributed locations into unified infrastructure. Let's consolidate the key knowledge from this page:

Key Takeaways

•Site-to-site VPN connects networks, not users — VPN gateways at each site handle encryption, making VPN transparent to end devices. This simplifies deployment at scale compared to per-user VPN clients.
•Topology selection balances performance, complexity, and resilience — Hub-and-spoke is simple but creates bottlenecks; full mesh is optimal but unmanageable at scale; DMVPN and SD-WAN provide dynamic mesh capabilities.
•Routing over VPN can be static or dynamic — Static is simple for small deployments; dynamic protocols (OSPF, BGP) enable automatic route learning, failover, and scale to large networks.
•High availability requires redundancy at multiple layers — Gateway clustering, multiple ISPs, multiple tunnels, and DPD for failure detection. Test failover regularly.
•IPSec with IKEv2 is the standard — Route-based VPN with virtual tunnel interfaces is preferred over policy-based crypto maps for flexibility and dynamic routing integration.
•Cloud VPN extends networks to AWS/Azure/GCP — Each provider offers VPN gateway services; understand throughput limits and consider dedicated connections for high-volume workloads.
•Operations require monitoring, troubleshooting skills, and lifecycle management — Know the common failure modes; maintain current firmware and strong cryptographic algorithms.

What's Next:

The next page explores Remote Access VPN—the counterpart to site-to-site VPN that connects individual users rather than networks. You'll learn about the unique challenges of remote access scenarios: user authentication, client provisioning, split tunneling policies, and the security considerations that arise when endpoints are outside corporate control.

Page Complete

You now have a deep understanding of site-to-site VPN: the architectures that connect enterprise networks, the topologies that scale to hundreds of sites, the routing that enables seamless inter-site communication, and the operational practices that keep VPN infrastructure reliable. This knowledge is essential for designing and maintaining enterprise network connectivity.

2 / 5

Loading learning content...

Computer NetworksVirtual Private Networks

Virtual Private Networks (VPN)

LevelIntermediate

Duration60 mins

TopicVirtual Private Networks

2 / 5

Site-to-Site VPN

Connecting Distributed Networks as One

What You Will Learn

Site-to-Site VPN Architecture

Core Architectural Components

VPN Gateway/Concentrator: At each site, a VPN gateway device terminates the VPN tunnel. This could be:

A dedicated VPN appliance (Cisco ASA, Palo Alto, Fortinet FortiGate)
A router with VPN capabilities (Cisco IOS router with crypto maps)
A firewall with integrated VPN (pfSense, OPNsense)
Cloud provider virtual network gateways (AWS VPN Gateway, Azure VPN Gateway)

Tunnel Configuration: Each tunnel requires matching configuration on both endpoints:

Encryption algorithms (AES-256-GCM, ChaCha20-Poly1305)
Authentication methods (pre-shared keys, RSA certificates)
Key exchange parameters (IKEv2 with specific Diffie-Hellman groups)
Traffic selectors (which subnets/networks the tunnel protects)

Routing: Site-to-site VPN requires routing configuration so that traffic destined for remote networks is directed into the VPN tunnel:

Static routes pointing remote subnets to the tunnel interface
Dynamic routing protocols (OSPF, BGP) running over the tunnel
Policy-based routing for more complex scenarios

Converting Mermaid diagram...

Traffic Flow in Site-to-Site VPN

Let's trace a packet from a workstation in Branch Office 1 (IP: 10.2.1.50) to a server at Headquarters (IP: 10.1.1.100):

Original Packet Creation: The workstation creates a packet with source 10.2.1.50, destination 10.1.1.100
Routing Decision: The branch router examines the destination. Route table shows 10.1.0.0/16 via VPN tunnel interface.
VPN Gateway Processing: The packet reaches the branch VPN gateway (198.51.100.1)
Encryption & Encapsulation: The gateway:
- Encrypts the entire original IP packet
- Adds ESP header and trailer
- Creates new outer IP header: Source 198.51.100.1, Destination 203.0.113.1
Internet Transit: The outer packet routes through the Internet normally—no device can read the encrypted payload
Termination at Headquarters: HQ gateway (203.0.113.1) receives the packet
Decryption & Decapsulation: HQ gateway verifies integrity, decrypts payload, strips outer headers
Local Delivery: Original packet (10.2.1.50 → 10.1.1.100) is routed to the destination server

Return traffic follows the same process in reverse, with HQ encrypting replies and Branch decrypting them.

Transparent to End Devices

Site-to-Site VPN Topologies

Hub-and-Spoke Topology

In hub-and-spoke (also called star topology), all branch sites connect only to a central hub site. Inter-branch traffic routes through the hub:

          [Branch A]----\
                         \____[Hub]____/----[Branch B]
          [Branch C]----/

Characteristics:

Central hub handles all encryption/decryption for inter-branch traffic
Branch-to-branch communication requires two hops (Branch A → Hub → Branch B)
Simplest configuration: N sites require N-1 tunnels
Central management and policy enforcement

Advantages:

Minimum tunnel count: N-1 tunnels for N sites
Simplified management: all configuration centers on hub
Easy policy enforcement: all traffic flows through central point
Lower cost: branches need only support single tunnel

Disadvantages:

Hub becomes critical single point of failure
Hub capacity limits total throughput
Suboptimal routing: geographically close branches route through distant hub
Latency doubles for inter-branch traffic

Converting Mermaid diagram...

Full Mesh Topology

In full mesh topology, every site has a direct tunnel to every other site:

          [Branch A]----[Branch B]
            |    \    /    |
            |     \  /     |
            |      \/      |
            |      /\      |
            |     /  \     |
          [Branch C]----[Hub D]

Characteristics:

N sites require N×(N-1)/2 tunnels
Any-to-any communication in single hop
No central bottleneck
Complex configuration

Advantages:

Optimal routing: direct paths between all sites
No single point of failure (for connectivity, though other issues may apply)
Best latency for site-to-site traffic
No central bottleneck limiting throughput

Disadvantages:

Tunnel count explodes: 10 sites = 45 tunnels; 50 sites = 1,225 tunnels; 100 sites = 4,950 tunnels
Configuration complexity grows geometrically
Every gateway must maintain many tunnels simultaneously
Changes (adding/removing sites) require touching multiple devices

Partial Mesh Topology

Partial mesh is a pragmatic compromise—some sites connect directly while others route through hubs:

Regional hubs connect to central hub (hub-and-spoke at the macro level)
Sites within a region connect in mesh (full mesh at micro level)
Critical site pairs get direct tunnels regardless of hierarchy

This approach balances tunnel count, performance, and management complexity.

Topology Comparison for Site-to-Site VPN
Topology	Tunnels for N Sites	10 Sites	50 Sites	100 Sites	Complexity	Resilience
Hub-and-Spoke	N - 1	9	49	99	Low	Single hub failure = total outage
Full Mesh	N×(N-1)/2	45	1,225	4,950	Very High	Highly resilient
Partial Mesh	Varies	~15-25	~100-300	~200-500	Medium	Regional failures possible
Dual Hub	~2×(N-1)	18	98	198	Medium	Good with hub redundancy

DMVPN: Dynamic Multipoint VPN

Cisco's Dynamic Multipoint VPN (DMVPN) technology addresses the mesh scalability problem through dynamic tunnel creation:

All spokes register with a hub using NHRP (Next Hop Resolution Protocol)
Initial traffic between spokes routes through hub
When spoke-to-spoke traffic demand detected, NHRP resolves the direct path
Spokes dynamically create direct IPSec tunnels as needed
Direct tunnels tear down after inactivity timeout

DMVPN provides full mesh connectivity benefits with hub-and-spoke configuration simplicity:

Configure spoke once (to register with hub)
No spoke-to-spoke preconfiguration needed
Tunnels created on-demand
Scales to thousands of sites

Similar solutions exist from other vendors (ADVPN from various vendors, SD-WAN solutions), all solving the same fundamental problem of mesh scalability.

Topology Selection Criteria

Routing Over VPN Tunnels

Static Routing

With static routing, administrators manually configure routes pointing remote subnets to the VPN tunnel interface:

! Example Cisco IOS static route
ip route 10.2.0.0 255.255.0.0 Tunnel0
ip route 10.3.0.0 255.255.0.0 Tunnel0

Advantages:

Simple to understand and implement
No routing protocol overhead
Predictable behavior
Works with any VPN technology

Disadvantages:

Doesn't adapt to network changes
Manual updates required when subnets added
No automatic failover if tunnel goes down (unless combined with object tracking)
Doesn't scale well for many subnets or sites

Dynamic Routing Over VPN

Dynamic routing protocols can run over VPN tunnels, treating the tunnel as just another network link:

OSPF over VPN:

Tunnel interfaces participate in OSPF areas
Remote routes learned automatically
Convergence when topology changes
Link-state database synchronized over tunnel

BGP over VPN:

eBGP or iBGP sessions over tunnel interfaces
Rich policy capabilities
Supports complex multi-homed scenarios
Preferred for large-scale deployments and DMVPN

EIGRP over VPN (Cisco proprietary):

Hybrid distance-vector routing
Efficient updates
Fast convergence

Dynamic Routing Benefits for VPN

•Automatic Route Discovery — When new subnets are added at remote sites, they're automatically advertised and learned. No manual route configuration needed.
•Failover and Redundancy — If a tunnel fails, routing protocols detect the failure and converge to alternate paths. Critical for high-availability designs.
•Load Balancing — Multiple tunnels between sites can share traffic load based on routing metric manipulation.
•Reduced Configuration Burden — Routing protocol configuration is typically simpler than maintaining hundreds of static routes.
•Consistent Behavior — Same routing protocols used inside the network extend over VPN, providing uniform operations.

Routing Protocol Selection

Different protocols suit different scenarios:

OSPF:

Best for: Single-organization networks, moderate scale (hundreds of routes)
Pros: Fast convergence, well-understood, multi-vendor support
Cons: Area design complexity, link-state database can grow large
Over VPN: Works well; consider tunnel as point-to-point link (OSPF network type)

BGP:

Best for: Large scale, multi-vendor, complex policies, DMVPN
Pros: Scalability, policy control, path attributes, vendor neutral
Cons: Complex configuration, slower convergence than OSPF
Over VPN: Excellent for DMVPN (where spoke-to-spoke paths need route learning)

Static with Object Tracking:

Best for: Simple deployments, few sites, stable environments
Pros: Simplicity, no protocol overhead, predictable
Cons: Manual management, limited adaptability
Object tracking adds failover capability to static routes

Route Summarization

With dynamic routing, careful summarization reduces routing table size and control plane overhead:

Each site should advertise summary routes, not individual subnets
Corporate IP addressing should enable summarization (contiguous blocks per site)
Hub sites should summarize branch routes to each other

Example: Instead of advertising 10.2.1.0/24, 10.2.2.0/24, ... 10.2.50.0/24 from Branch 1, advertise a single 10.2.0.0/16 summary.

Routing Protocol Over VPN Considerations

High Availability and Redundancy

Site-to-site VPN often carries business-critical traffic. Design for high availability requires redundancy at multiple levels.

VPN Gateway Redundancy

Single VPN gateways create single points of failure. Redundancy approaches include:

Active/Passive Clustering:

Two gateways share a virtual IP address
Primary handles all traffic; standby monitors and takes over on failure
Stateful failover preserves tunnel state (on some platforms)
Simple but wastes standby capacity

Active/Active Clustering:

Both gateways handle traffic simultaneously
Traffic can be load-balanced across gateways
More efficient resource utilization
More complex configuration and state synchronization

Independent Gateways with Routing Failover:

Two separate gateways with independent tunnel sets
Routing protocols or static route metrics determine active path
No cluster configuration needed; gateways are completely independent
Failover time depends on routing convergence

Tunnel Redundancy

Even with redundant gateways, a single ISP failure can disable connectivity. Tunnel-level redundancy options:

Multiple ISPs:

Each site has connections to two or more ISPs
Tunnels established over each ISP connection
Routing selects best path; fails over on link failure

Multiple Tunnels per ISP:

Parallel tunnels with different parameters
Can provide load balancing
Limited additional resilience (ISP failure affects all)

Converting Mermaid diagram...

Dead Peer Detection (DPD)

VPN gateways need to detect when remote peers become unreachable. Dead Peer Detection is an IKE mechanism that:

Sends periodic "R-U-THERE" messages
Expects "R-U-THERE-ACK" responses
Declares peer dead after configurable failures
Triggers tunnel teardown and failover

DPD settings balance responsiveness against false positives:

Aggressive settings (5s interval, 3 retries = 15s detection)
- Fast failover but may flap on temporary congestion
Conservative settings (30s interval, 5 retries = 150s detection)
- Stable but slow failover response

Path MTU and Fragmentation

VPN encapsulation adds overhead (typically 50-80+ bytes for IPSec ESP), reducing the maximum transmission unit (MTU) for payload data:

Standard Ethernet MTU: 1500 bytes
After ESP encapsulation: ~1400-1420 bytes usable for original packet
If original packet is 1500 bytes, it won't fit after encapsulation

Solution approaches:

Pre-fragmentation:

Fragment original packet before encryption
Each fragment fits after encapsulation
TCP MSS clamping helps prevent large TCP segments

Post-fragmentation:

Encapsulate full packet, then fragment the encrypted packet
Reassembly required at receiver before decryption
Problematic with some firewalls/NATs that block fragments

Path MTU Discovery:

ICMP "Fragmentation Needed" messages inform sender
Sender reduces packet size
May be blocked by firewalls (common configuration error)

Best practice: Configure TCP MSS clamping at VPN gateways to 1360-1380 bytes, ensuring TCP-based traffic fits without fragmentation.

Testing Failover

IPSec for Site-to-Site VPN

IKE (Internet Key Exchange) Phases

IPSec tunnel establishment occurs in two phases:

Phase 1 (IKE SA Establishment):

Authenticates peers to each other
Negotiates encryption parameters for Phase 2 protection
Establishes a secure channel (IKE Security Association)
Key exchange using Diffie-Hellman
Result: Encrypted, authenticated channel for Phase 2 negotiation

Phase 2 (IPSec SA Establishment):

Protected by Phase 1 IKE SA
Negotiates encryption parameters for actual data traffic
Defines traffic selectors (which traffic is protected)
Establishes IPSec Security Associations (one for each direction)
Result: Encryption keys for user traffic

IKEv1 vs. IKEv2

IKEv2 is the modern standard, offering improvements over IKEv1:

Feature	IKEv1	IKEv2
Message exchanges	6-9	4
NAT traversal	Add-on	Built-in
Dead peer detection	Add-on	Built-in
Reliability	None	Retransmission, sequence numbers
Authentication methods	Limited	Extensible (EAP support)
Rekeying	Disruptive	Seamless
MOBIKE	No	Yes (mobility support)

New deployments should always use IKEv2 unless compatibility with legacy equipment mandates IKEv1.

IPSec Site-to-Site Configuration Elements

•Peer Addresses — Public IP addresses of both VPN gateways. These are the outer IP addresses of encapsulated packets.
•Authentication — Pre-shared key (PSK) or certificates. PSK is simpler; certificates are more scalable and secure for many tunnels.
•Phase 1 Proposals — Encryption (AES-256), integrity (SHA-256/384/512), Diffie-Hellman group (14, 19, 20, 21), lifetime (typically 24 hours).
•Phase 2 Proposals — ESP encryption (AES-256-GCM), integrity (if not using authenticated encryption), PFS group, lifetime (typically 1-8 hours).
•Traffic Selectors — Source and destination network ranges that the tunnel protects. Also called "proxy IDs" or "interesting traffic".
•Dead Peer Detection — Interval and retry settings for detecting peer failure.
•NAT Traversal — UDP encapsulation settings if gateways are behind NAT (port 4500).

Policy-Based vs. Route-Based VPN

IPSec implementations fall into two architectural approaches:

Policy-Based VPN:

Traffic selectors (crypto ACLs) define what traffic is encrypted
Each traffic flow matches against policies
Multiple policies can exist for different traffic types
Implementation: Cisco crypto maps, some firewall implementations

Route-Based VPN:

Creates virtual tunnel interfaces (VTI)
Routing determines what traffic goes through tunnel
Any traffic routed to tunnel interface is encrypted
Implementation: Cisco VTI, Juniper st0 interfaces, cloud provider VPNs

Route-based is generally preferred for modern deployments because:

Dynamic routing protocols work naturally over tunnel interfaces
Simpler configuration, especially for many subnets
Better integration with DMVPN and SD-WAN solutions
Easier troubleshooting (standard routing tools work)

Example Route-Based Configuration (Cisco IOS):

! Phase 1 (IKEv2)
crypto ikev2 proposal PROP-IKEV2
  encryption aes-cbc-256
  integrity sha384
  group 19

crypto ikev2 policy POL-IKEV2
  proposal PROP-IKEV2

crypto ikev2 keyring KEYRING
  peer HQ
    address 203.0.113.1
    pre-shared-key SECURE_KEY_HERE

crypto ikev2 profile IKEV2-PROFILE
  match identity remote address 203.0.113.1
  authentication local pre-share
  authentication remote pre-share
  keyring local KEYRING

! Phase 2 (IPSec)
crypto ipsec transform-set TS esp-aes 256 esp-sha384-hmac
  mode tunnel

crypto ipsec profile IPSEC-PROFILE
  set transform-set TS
  set ikev2-profile IKEV2-PROFILE

! Tunnel Interface
interface Tunnel0
  ip address 10.255.0.2 255.255.255.252
  tunnel source GigabitEthernet0/0
  tunnel destination 203.0.113.1
  tunnel mode ipsec ipv4
  tunnel protection ipsec profile IPSEC-PROFILE

! Routing
ip route 10.1.0.0 255.255.0.0 Tunnel0

Strong Cryptographic Recommendations

Cloud VPN Connectivity

AWS VPN Solutions

AWS Site-to-Site VPN:

Customer Gateway: Your on-premises VPN device
Virtual Private Gateway (VGW) or Transit Gateway: AWS-side termination
Two tunnels per connection for redundancy (different Availability Zones)
Supports BGP for dynamic routing (recommended)
Static routing option for simpler scenarios
Up to 1.25 Gbps per tunnel (aggregate with multiple tunnels)

AWS Transit Gateway with VPN:

Centralizes connectivity for multiple VPCs
VPN attaches to Transit Gateway, not individual VPCs
Scales to thousands of VPCs and VPN connections
Supports Equal-Cost Multi-Path (ECMP) for high throughput

Azure VPN Gateway

VpnGw SKUs:

VpnGw1/2/3/4/5: Increasing throughput (650 Mbps to 10 Gbps)
Zone-redundant versions: VpnGw1AZ through VpnGw5AZ
Supports IKEv2 and OpenVPN (for point-to-site)
BGP routing with Azure Route Server for complex scenarios

Azure Virtual WAN:

Hub-and-spoke at cloud scale
Automated VPN connectivity to Azure regions
Integrates VPN, ExpressRoute, and SD-WAN

Cloud VPN Gateway Comparison
Provider	Service	Max Throughput	BGP Support	HA Mechanism
AWS	Site-to-Site VPN	1.25 Gbps/tunnel (ECMP for more)	Yes	Dual tunnels to different AZs
Azure	VPN Gateway	10 Gbps (VpnGw5)	Yes	Active-Active, Zone-redundant
GCP	Cloud VPN	3 Gbps/tunnel (8 tunnels = 24 Gbps)	Yes	HA VPN with 99.99% SLA
Oracle Cloud	IPSec VPN	250 Mbps - 10 Gbps	Yes	Dual tunnel redundancy

Google Cloud Platform (GCP) VPN

Classic VPN:

Legacy single-tunnel option
Static routing only
No SLA (being deprecated)

HA VPN:

High-availability architecture with 99.99% SLA
Two interfaces with automatic failover
BGP required for HA VPN
Supports up to 3 Gbps per tunnel, 8 tunnels per gateway

Multi-Cloud VPN Connectivity

Organizations using multiple cloud providers need to interconnect them:

Option 1: On-premises hub:

All cloud VPNs terminate on-premises
Traffic between clouds routes through on-premises
Suboptimal latency, simpler management

Option 2: Direct cloud-to-cloud:

VPN tunnels between cloud provider VPCs
AWS VPC peers with Azure VNet via IPSec
Optimal latency, more complex management
Egress charges from both clouds

Option 3: Cloud interconnect services:

Third-party providers offering multi-cloud fabric
Megaport, Equinix Fabric, PacketFabric
Private connectivity without Internet transit
Higher bandwidth than VPN

Design Considerations for Cloud VPN

IP address planning: Ensure on-premises and cloud networks use non-overlapping address ranges
NAT implications: NAT between on-premises and cloud adds complexity; plan carefully
Throughput requirements: VPN has bandwidth limits; consider dedicated connections (Direct Connect, ExpressRoute) for high-volume workloads
Latency sensitivity: VPN adds encryption overhead; very latency-sensitive applications may need dedicated connections
Cost: VPN is typically cheaper than dedicated connections, but data transfer charges apply

Cloud VPN Bandwidth Limitations

Operational Considerations

Deploying site-to-site VPN is only the beginning. Ongoing operations require attention to monitoring, troubleshooting, and lifecycle management.

Monitoring and Alerting

Critical metrics to monitor:

Tunnel State:

IKE Phase 1 status: Is the IKE SA established?
IKE Phase 2 status: Are IPSec SAs established?
Dead Peer Detection events: Are peers reachable?

Performance Metrics:

Throughput: Bytes/packets encrypted and decrypted
Latency: Round-trip time through tunnel
Packet loss: Encapsulation/decapsulation failures
CPU utilization: Encryption overhead on gateways

Security Events:

Authentication failures: Failed IKE authentication attempts
Replay attacks detected: Anti-replay window violations
SA expiration: Rekeying events and failures

Troubleshooting Methodology

When tunnels fail, systematic troubleshooting is essential:

Verify basic connectivity: Can gateways ping each other on public IPs?
Check IKE Phase 1: Are proposals matching? Authentication failing?
Check IKE Phase 2: Are traffic selectors matching? Transform sets compatible?
Verify routing: Are routes pointing to tunnel? Are remote subnets reachable?
Check firewall rules: Are ESP (protocol 50) and UDP 500/4500 permitted?
Review logs: What specific error messages appear during negotiation?

Common Site-to-Site VPN Problems

•Mismatched Proposals — Phase 1 or Phase 2 proposals don't match between peers. Common with multi-vendor deployments. Solution: Ensure identical encryption, integrity, DH group, and lifetime values.
•Incorrect Pre-Shared Key — Keys must match exactly, including case and whitespace. Solution: Copy-paste the same key to both devices; verify no trailing spaces.
•Traffic Selector Mismatch — Endpoints disagree on which subnets are protected. Policy-based VPNs are particularly prone to this. Solution: Ensure proxy IDs or crypto ACLs match exactly on both ends.
•NAT Traversal Issues — One gateway behind NAT, but NAT-T not enabled. Solution: Enable NAT traversal (UDP 4500) on both endpoints.
•Firewall Blocking ESP — Stateful firewalls dropping ESP packets after timeout. Solution: Ensure ESP (protocol 50) and IKE (UDP 500, 4500) are permitted.
•MTU/Fragmentation — Large packets failing after encapsulation. Solution: Implement TCP MSS clamping at 1360 bytes; ensure PMTUD works.
•Asymmetric Routing — Return traffic takes different path than outbound, bypassing VPN. Solution: Ensure routing is symmetric or VPN gateways have state sync.

Lifecycle Management

Certificate Rotation:

Certificate-based authentication requires renewal before expiration
Plan rotation well before certificates expire
Automate certificate deployment where possible
Test rotation in non-production environments first

Algorithm Upgrades:

Cryptographic algorithms become deprecated over time
SHA-1, 3DES, DH Group 2 are already weak
Plan migration to stronger algorithms
Both ends must support new algorithms before migration

Firmware/Software Updates:

VPN gateway firmware should be kept current
Security vulnerabilities are discovered periodically
Test updates in non-production before rollout
Plan maintenance windows for updates

Change Management

VPN changes require careful coordination:

Network changes at one site may require VPN updates at others
Adding subnets may require updating traffic selectors or routing
Changes should be tested in non-production if possible
Rollback procedures should be documented before changes
After-hours changes minimize business impact

Documentation Is Critical

Summary: Site-to-Site VPN Mastery

Key Takeaways

•Site-to-site VPN connects networks, not users — VPN gateways at each site handle encryption, making VPN transparent to end devices. This simplifies deployment at scale compared to per-user VPN clients.
•Topology selection balances performance, complexity, and resilience — Hub-and-spoke is simple but creates bottlenecks; full mesh is optimal but unmanageable at scale; DMVPN and SD-WAN provide dynamic mesh capabilities.
•Routing over VPN can be static or dynamic — Static is simple for small deployments; dynamic protocols (OSPF, BGP) enable automatic route learning, failover, and scale to large networks.
•High availability requires redundancy at multiple layers — Gateway clustering, multiple ISPs, multiple tunnels, and DPD for failure detection. Test failover regularly.
•IPSec with IKEv2 is the standard — Route-based VPN with virtual tunnel interfaces is preferred over policy-based crypto maps for flexibility and dynamic routing integration.
•Cloud VPN extends networks to AWS/Azure/GCP — Each provider offers VPN gateway services; understand throughput limits and consider dedicated connections for high-volume workloads.
•Operations require monitoring, troubleshooting skills, and lifecycle management — Know the common failure modes; maintain current firmware and strong cryptographic algorithms.

What's Next:

Page Complete

2 / 5