Site-to-Site VPN for Branch Offices: IPSec vs WireGuard vs IKEv2 in the Russian Context
A comprehensive hands-on guide to choosing and implementing Site-to-Site VPN for branch offices in Russia: comparing IPSec, WireGuard, and IKEv2, architectures, security, performance, checklists, step-by-step setup, common pitfalls, and real-world cases. From proof of concept to production.
Content of the article
- Introduction: why this topic matters and what you'll learn
- Basics: core concepts (for beginners)
- Deep dive: advanced topics
- Practice 1: site-to-site architectures for different needs
- Practice 2: ipsec/ikev2 — theory, step-by-step setup, optimization
- Practice 3: wireguard — getting started, operation, security
- Practice 4: ikev2 in enterprise — certificates, mdm, hybrid scenarios
- Practice 5: nat, mtu, dpi — how not to lose packets
- Practice 6: routing and ha — bgp over vpn
- Practice 7: observability, operations, slo
- Common mistakes: what not to do
- Tools and resources: what to use
- Cases and results: real-world examples
- Faq: 7–10 in-depth questions
- Conclusion: summary and next steps
Introduction: Why This Topic Matters and What You'll Learn
By 2026, Site-to-Site VPN for branch offices has become the backbone of corporate networks. Offices, data centers, clouds, and remote sites demand secure channels over the unpredictable internet and operator L3 networks. Why is this especially critical in Russia now? Because of routing fluctuations, occasional filtering and DPI, diverse providers, import substitution demands, and rising requirements for personal data and trade secret protection. This guide compares three practical approaches to corporate S2S VPN: IPSec, WireGuard, and IKEv2 (as the IKEv2+IPSec suite), focusing on real-world use: architectures, crypto profiles, failover, performance, operations, common mistakes, and actual case studies.
What you’ll get: clear criteria for picking the right protocol based on your topology and regulation, step-by-step deployment instructions, readiness audit checklists, MTU, NAT-T, and BGP over VPN recommendations, plus a total cost of ownership framework and risk assessments. We deliberately skip academic theory and concentrate on what works in Russian environments today.
Basics: Core Concepts (For Beginners)
What is Site-to-Site VPN?
Site-to-Site VPN links two or more IP networks, letting hosts in Branch A access resources in Branch B as if they were on the same local network or routed core. The tunnel encapsulates and encrypts packets over the public internet or an L3 channel.
Key Components
- Transport: UDP or TCP over IP. IPSec uses ESP and often UDP ports 500/4500 (NAT-T). WireGuard defaults to UDP port 51820 but is configurable.
- Cryptography: cipher suites, authentication, PFS, KDF. Focus on AEAD (AES-GCM, ChaCha20-Poly1305) for performance and simplicity.
- Key Management: IKEv2 for IPSec; WireGuard uses static keys or controllers with scheduled rotation built into the protocol.
- Routing: static routes or dynamic protocols (BGP, OSPF) inside the tunnel.
- Reliability: DPD, keepalive, SLA monitoring, backup links, HA clusters.
What are IPSec, WireGuard, and IKEv2?
- IPSec: a network layer protocol suite (ESP/AH) providing encryption and authentication. Mature, flexible, supported by most routers and firewalls, typically managed via IKEv2.
- WireGuard: a modern VPN protocol based on the Noise framework (NoiseIK), UDP-only, minimalistic, fast, and easy to configure.
- IKEv2: key exchange and security parameter negotiation protocol for IPSec. In corporate settings, "IKEv2" usually means IPSec with IKEv2.
Russian Realities
- DPI and Unstable Routes: UDP traffic may degrade sporadically; it's critical to have fallback and flexible NAT-T settings plus backup channels.
- Regulation: protecting personal data and critical infrastructure requires both organizational and technical measures; sometimes certified solutions or GOST cryptography are mandatory.
- Import Substitution: open-source stacks (StrongSwan, VyOS, FRR) and Russian vendors are increasingly preferred, maintaining compatibility via standard protocols.
Deep Dive: Advanced Topics
Security: Crypto Profiles and Key Rotation
- IPSec/IKEv2: recommended ciphers in 2026 are AES-GCM-128/256 with PFS (DH Group 14 or 19+), certificate authentication (RSA-3072 or ECDSA P-256/P-384). Lifetimes: IKE SA 8-24 hours, Child SA 1-4 hours; rekey proactively.
- WireGuard: ChaCha20-Poly1305, Curve25519, HKDF; key rotation triggered by protocol timers and operational policies; store private keys in HSMs or with secure access.
Performance and Latency
- Latency: IPSec ESP on hardware with AES-NI shows stable latency; WireGuard often outperforms on small packets and high concurrency due to its compact and simpler stack.
- Overhead: IPSec ESP adds 50–80 bytes per packet depending on config; WireGuard adds around 32–60 bytes. This impacts MTU and necessitates MSS clamp.
- Throughput: on x86 with AES-NI, a single core can handle 1–3 Gbps IPSec AES-GCM when optimized; WireGuard often achieves 2–4 Gbps on the same CPU. Results depend on NIC offload, IRQ pinning, and NUMA configuration.
Reliability and High Availability
- DPD/Keepalive: IPSec: DPD 10–15 seconds, 3–5 retries; WireGuard: persistent keepalive every 15–25 seconds behind NAT.
- Redundancy: use two independent providers per site, multiple tunnels (active-active with ECMP or active-standby), VRRP/Keepalived on border nodes, and BGP inside tunnels.
- DPI/Blocks: UDP is preferred, but when there’s blocking risk, keep parallel SSTP or TCP obfuscation profiles for emergency critical access.
Network Design
- Full-tunnel vs split-tunnel: branch offices usually use split-tunnel—only corporate prefixes go through VPN; internet traffic stays local to save bandwidth.
- Address Space: avoid overlapping RFC1918 ranges between branches; assign /24 or /23 blocks per site; reserve IPs for management services.
- Dynamic Routing: BGP with MED/LocalPref to choose best paths; OSPF on closed perimeters; avoid complex redistribute between VRFs.
Practice 1: Site-to-Site Architectures for Different Needs
Architecture A: Hub-and-Spoke
A central hub (data center or cloud) connects dozens of branches. Pros: simplified control, a single security point, end-to-end analytics. Cons: SPOF risks, core load, complex scaling without ECMP and clusters.
- IPSec/IKEv2: mature setup using StrongSwan/VyOS or hardware gateways. Recommend BGP on each spoke, announcing branch prefixes to hub via two independent tunnels.
- WireGuard: easier to automate configs for many spokes due to simplicity and templating. Key control and CMDB inventory are a must.
Architecture B: Partial Mesh
Critical branches connect directly to each other in addition to the hub. Pros: shorter paths, lower latency. Cons: tunnel count grows quadratically, requiring auto-orchestration.
Architecture C: Dual-hub Active-Active
Two hubs in different locations, ECMP or BGP multipath, session load balancing. Nuance: symmetric routing or session stickiness. IPSec needs separate SAs per path; WireGuard uses multiple peers with different priorities.
Protocol Choice by Context
- Maximum equipment compatibility: IPSec/IKEv2.
- Simplicity and speed: WireGuard.
- Certification needs: IPSec with proven stacks or specialized GOST-VPN solutions.
Architecture Checklist
- Two independent providers at hub and critical branches.
- MTU plan: 1400–1420 for VPN interface, MSS clamp 1360–1380.
- BGP inside VPN, prefix filtering, block "0/0" announcements from branches.
- Management redundancy: OOB or LTE modem with emergency tunnel.
Practice 2: IPSec/IKEv2 — Theory, Step-by-Step Setup, Optimization
Crypto Profile
- Phase 1 (IKEv2): AES-GCM-256, PRF SHA-256, DH Group 19 (ECDH P-256), lifetime 8h, reauth enabled.
- Phase 2 (Child SA): AES-GCM-256, PFS Group 19, lifetime 1–2h, replay-window 64–128.
- Authentication: X.509 certificates with CRL/OCSP or short-lived certs (90–180 days) with automated rotation.
Step-by-Step Guide (Universal Logic)
- Addressing Prep: fix local and remote subnets, avoid overlaps. Define NAT exemption plan.
- PKI: set up internal CA, issue certs for gateways with Key Usage and SAN policies using FQDN/IP.
- IKE Settings: select ciphers, lifetimes, DPD 10s. Enable NAT-T if branch provider uses CG-NAT.
- IPSec Settings: ESP in tunnel mode (typical), PFS enabled, rekey proactively (e.g., 10% before expiry).
- Routing: start with static routes, then move to BGP neighbors via tunnel IPs.
- MTU/MSS: set MTU 1400, enable MSS clamp 1360 for TCP at LAN interfaces.
- Monitoring: export metrics to Prometheus/InfluxDB, alert on SA drops and retransmit spikes.
Fine-tuning for Russian Networks
- Aggressive NAT-T: for floating NAT and lost keepalives, increase DPD frequency, shorten rekey intervals.
- Port Duplication: alternate UDP ports if DPI signatures present; some devices allow custom ports.
- Failover: two parallel tunnels to different hub IPs with ECMP or SLA-based priority.
IPSec Implementation Framework
- Pilot 1–3 branches, load up to 200 Mbps, metrics collection.
- Audit MTU/MSS and fragmentation; apply corrections.
- Switch to BGP, drop static routes where possible.
- Enable security event logging; test incidents (link failure, key compromise, CA rotation).
Practice 3: WireGuard — Getting Started, Operation, Security
Why WireGuard
Stable UDP operation, minimal code, high speed, simple configs. Perfect for mass branch deployment on Linux/RouterOS/VyOS and x86 gateways.
Step-by-Step Instructions
- Keys: generate key pairs for each node. Store private keys centrally with access control.
- Interface: create wg0 with tunnel subnet addresses (e.g., 10.10.0.0/24).
- Peers: add all branch peers on the hub; add hub peer on branches. Narrow AllowedIPs to required subnets.
- Keepalive: enable persistent keepalive every 20–25 seconds, especially behind NAT.
- Routes: configure static routes or BGP over FRR on the wg interface.
- MTU/MSS: start with MTU 1420 and MSS clamp 1380.
WireGuard Security
- Key Control: CMDB inventory, rotation policies every 90–180 days, immediate revocation after incidents.
- Least Privilege Access: limit AllowedIPs to actual subnets; avoid 0.0.0.0/0 unless full tunnel is required.
- Filtering: firewall UDP ingress on WG port, whitelist sources when possible.
Performance Optimization
- CPU IRQ pinning for NIC and wg process on NUMA-local cores.
- Enable GRO/LRO and RPS/RFS on Linux; monitor drops with ethtool -S.
- Parallel tunnels for high throughput; ECMP at routing level.
WireGuard Checklist
- UDP accessible on chosen port both ends.
- Persistent keepalive set for nodes behind NAT.
- MTU 1420 and MSS clamp 1380 verified via traceroute and tests.
- Logs and metrics collected (wg show, exported to Prometheus).
Practice 4: IKEv2 in Enterprise — Certificates, MDM, Hybrid Scenarios
Why IKEv2
Standardized, widely supported by hardware and software gateways, suitable for mixed environments (Windows, iOS, Android, Linux). Usually used as IPSec key management in S2S, but hybrid companies can use the same PKI for S2S and remote access VPNs.
Step-by-Step Approach
- PKI and Policies: create cert templates for gateways, include Extended Key Usage for IPsec IKE.
- IKE Profiles: specify cipher suites and DH groups; enable MOBIKE for mobile scenarios.
- Role Separation: S2S certs separate from user VPN certs; strict rotation and auditing.
- MDM Integration: publish IKEv2 profiles for clients if hybrid remote access is needed.
Practical Tips
- CRL/OCSP: fallback to short-lived certs if OCSP is unreachable; store CRLs locally.
- Scaling: avoid single CA for all perimeters; segment with Intermediate CAs per perimeter.
Practice 5: NAT, MTU, DPI — How Not to Lose Packets
MTU Diagnostics
- Perform PMTUD with DF flag and incremental packet sizes to ensure stable passage.
- Set tunnel MTU 20–80 bytes below max possible size.
- Configure MSS clamp on TCP at border interfaces.
CG-NAT and UDP Instability
- Increase keepalive frequency; duplicate tunnels on different ports.
- If degradation is persistent — keep a backup TCP profile (SSTP or OpenVPN TCP) for critical services, but not as main S2S.
DPI
- Maintain legitimate traffic profiles, use standard ports when possible.
- Separate control and data channels to preserve management integrity.
Practice 6: Routing and HA — BGP Over VPN
Why BGP?
Static routing scales poorly. BGP provides path control, fast recovery, and predictable multi-hub behavior. It naturally fits the S2S transport layer.
Step-by-Step
- Loopback Addresses: assign loopbacks on each gateway for BGP neighbors over tunnels.
- Filters: announce only your prefixes; filter foreign prefixes on hub.
- Policies: use MED/LocalPref to prioritize hubs; prepend for failover paths.
- Failover: use fast timers (hello 3s, hold 9s) on stable networks or BFD if supported.
HA on Gateways
- VRRP/Keepalived pairs at branches.
- Config sync and backup CA access.
- Account for asymmetric routing and stateful firewall peculiarities.
Practice 7: Observability, Operations, SLO
Metrics
- Tunnel Availability: uptime of SA or wg peer, RTO, jitter.
- Throughput: p95/p99 bandwidth, interface errors and drops.
- Security: failed authentications, rekey frequency, suspicious route changes.
Alerting
- SLO: 99.9% availability for inter-branch traffic; alert when rolling window drops below threshold.
- Recovery Times: MTTR up to 5 minutes per branch with backup channel.
Operational Procedures
- Quarterly key/cert rotation.
- DR test plans: provider outage, key compromise, gateway failure.
- Inventory: up-to-date register of branches, prefixes, keys, provider contacts.
Common Mistakes: What NOT to Do
- Same RFC1918 on different branches: causes asymmetry and hairpinning. Plan addressing ahead.
- No MSS clamp: fragmentation and unpredictable TCP timeouts.
- Weak crypto profiles: outdated ciphers (3DES, CBC without AEAD), no PFS.
- Single CA for all perimeters: risks domino effect on compromise.
- Post-factum monitoring: implement metrics and alerts before scaling.
- Unchecked failover: backup tunnels exist but timers, BGP, and NAT exemptions untested.
- Single uplink: one provider on critical node leads to downtime risks.
Tools and Resources: What to Use
Software Stacks
- IPSec/IKEv2: StrongSwan, Libreswan, VyOS, pfSense; network OS with AES-NI hardware acceleration.
- WireGuard: built into Linux kernel; supported on Windows, BSD, RouterOS 7, VyOS.
- Dynamic Routing: FRR (BGP/OSPF), BFD if supported, keepalived/VRRP for HA.
Monitoring and Testing
- Prometheus, VictoriaMetrics, Grafana for dashboards.
- iperf3 for throughput and jitter; hping for MTU/DF checks.
- Packet capture at edges (tcpdump) filtering ESP/UDP ports.
Configuration Management
- GitOps: store tunnel and BGP policy templates in repos.
- Ansible for mass deployment; secrets in Vault.
Quick Start for Pilots
For pilots and POCs where fast launch and payment flexibility in Russia matter, vpn.how is a proven way to quickly get a personal VPN server with a dedicated (non-shared) IP, supporting WireGuard, OpenVPN, IKEv2, L2TP, and SSTP—letting you pick the best protocol for your network. Server locations include Moscow, St Petersburg, Amsterdam, Frankfurt, London, New York, San Jose, Chicago, Singapore, Sydney, Madrid, Helsinki, Stockholm, Warsaw, Copenhagen, Stavanger. Payment options include Russian cards (Tinkoff, Ozon), SBP, and USDT/BTC. Prices start from 490 ₽ per day and 2490 ₽ monthly with discounts for longer terms; automatic activation within 5 minutes after payment and no logs let you test ideas quickly without lengthy procurement. For production in large environments, build your own infra or use certified GOST-compliant solutions.
Cases and Results: Real-World Examples
Case 1: Retail Network, 120 Branches
Context: two data warehouses, ERP and POS systems. Solution: Hub-and-Spoke with IPSec/IKEv2, two hubs (Moscow, St Petersburg), BGP over tunnels. Parameters: AES-GCM-256, DH19, Child SA 90 minutes, DPD 10s. Result: 99.94% availability over a quarter, p95 throughput 250 Mbps per branch, MTTR 4 minutes on channel failure thanks to BFD+BGP failover. Insight: MSS clamp 1360 fixed 80% of fragmentation incidents in the first two weeks.
Case 2: Logistics, Backbone Flows up to 3 Gbps
Context: telemetry and video exchange between hub and 8 sites. Solution: WireGuard with ECMP, dual providers, FRR BGP. Result: aggregate up to 6 Gbps on two parallel tunnels, latency 10–15% lower than IPSec pilot, simplified operations. Insight: IRQ pinning and disabling unnecessary NIC offload added +20% throughput.
Case 3: Fintech, Strict Policies
Context: segmentation and audit requirements, multi-cloud. Solution: IPSec/IKEv2 with strong PKI, short certs, separate PROD/NON-PROD CAs, escrow procedures. Result: successful audit, automatic rotation every 90 days, zero compromise incidents in a year. Insight: centralized tunnel and key registry with mandatory change review reduced operational errors by 60%.
Case 4: Manufacturing, Unstable Regional Providers
Context: some sites behind CG-NAT, occasional UDP degradation. Solution: WireGuard primary, backup via IKEv2/ISAKMP on alternative provider; for the most problematic sites—emergency SSTP profile for management only. Result: downtime reduced to 0.3% monthly, RTO 2–3 minutes. Insight: aggressive keepalives and separation of control/data stopped false monitoring alerts.
FAQ: 7–10 In-depth Questions
1. What to choose for a 10–20 branch network with a small IT team?
WireGuard offers simplicity and quick deployment, especially with x86/VyOS/RouterOS gear. For compatibility with mixed firewalls and strict policies, go with IPSec/IKEv2.
2. What MTU should I use by default?
Starting values: IPSec 1400, WireGuard 1420, MSS clamp 1360–1380. Then fine-tune empirically via PMTUD and fragmentation analysis.
3. Can I mix WireGuard and IPSec/IKEv2?
Yes. Common to use WireGuard for bulk traffic and IPSec/IKEv2 for compatibility or backup. The key is coordinated routing and BGP priority settings.
4. How secure is WireGuard without IKE?
WireGuard is secure by modern standards using strong primitives. Risks lie more in operational discipline: key management, minimal AllowedIPs, and timely rotation.
5. What about DPI and UDP blocking in Russia?
Isolated cases occur. Keep backups: alternate ports, parallel tunnels via other providers, and an emergency TCP profile for management.
6. When is BGP needed versus static?
For up to 5–7 branches without complex failover, static routes suffice. Beyond that, BGP reduces operational risk and speeds recovery.
7. How to plan performance?
Estimate peak and p95 traffic, budget 30–50% spare for CPU and uplink, consider offload and NUMA. For IPSec, check AES-NI; for WireGuard, plan parallel tunnels for gigabit loads.
8. What are the requirements for personal and critical data?
VPN is just part of it. Organizational measures, segmentation, logging, access control are essential. For certification, consider certified solutions or GOST cryptography.
9. How often should keys and certificates be rotated?
Best practice: every 90–180 days, automated. Replace immediately on incident.
10. Can multicast or VoIP run over VPN?
Yes, but pay attention to MTU, jitter, QoS. Often SRTP on separate profiles and WAN prioritization are preferred.
Conclusion: Summary and Next Steps
In the Russian context, two main Site-to-Site technologies remain viable: IPSec/IKEv2 as a universal standard and WireGuard as a light, high-performance tool. The choice isn’t binary—in mature networks, a hybrid approach suits each site and traffic profile best. The key to success is network discipline: thoughtful addressing, BGP over tunnels, correct MTU/MSS, channel and gateway high availability, observability, and rigorous security management. Start with a pilot: 2–3 sites, metrics, load, failover tests. Refine profiles, then scale using GitOps and CMDB. For quick POCs and experiments, a personal VPN server from a provider like the one described works well. For production, consider your own clusters or certified solutions. Crucially, don’t delay observability and DR testing; keep crypto profiles and keys under strict discipline. Then VPN stops being a "black box" and becomes a predictable backbone for your business.