IPsec IKEv2 Site-to-Site VPN: Complete Implementation Guide

IPsec IKEv2 Site-to-Site VPN: Complete Implementation Guide

RouterOS Version: 7.x+ Difficulty: Advanced Estimated Time: 60 minutes

TL;DR (Quick Start)

For the impatient: here’s the 30-second version.

# Site A (initiator): 203.0.1.1, LAN 10.1.0.0/24
/ip ipsec peer add address=203.0.2.1/32 exchange-mode=ike2 name=site-b
/ip ipsec identity add peer=site-b secret=YourSecretKey123 auth-method=pre-shared-key
/ip ipsec policy add src-address=10.1.0.0/24 dst-address=10.2.0.0/24 tunnel=yes peer=site-b

# Site B (responder): 203.0.2.1, LAN 10.2.0.0/24
/ip ipsec peer add address=203.0.1.1/32 exchange-mode=ike2 name=site-a passive=yes
/ip ipsec identity add peer=site-a secret=YourSecretKey123 auth-method=pre-shared-key
/ip ipsec policy add src-address=10.2.0.0/24 dst-address=10.1.0.0/24 tunnel=yes peer=site-a

Overview

IPsec IKEv2 site-to-site VPNs create secure, encrypted tunnels between geographically separated networks over the public internet. Unlike legacy protocols, IKEv2 provides superior reliability, faster reconnection after network interruptions, and stronger cryptographic algorithms that meet modern security requirements.

This guide explains the fundamental concepts, implementation strategies, and critical configuration decisions that determine whether your VPN performs reliably or becomes a source of constant troubleshooting.

Understanding IPsec IKEv2 Architecture

The Two-Phase Protocol

IKEv2 operates in two distinct phases, each serving a specific purpose:

Phase 1 (IKE_SA): Establishes the secure control channel

• Authenticates both peers (PSK, certificates, or EAP)
• Negotiates encryption algorithms and Diffie-Hellman groups
• Creates the foundation for all subsequent communication
• Lives for hours/days (long-lived)

Phase 2 (CHILD_SA): Creates the actual data tunnels

• Negotiates ESP encryption parameters
• Establishes traffic selectors (which networks to encrypt)
• Can create multiple tunnels per IKE_SA
• Automatically rekeyed every 30 minutes (short-lived)

Tunnel vs Transport Mode

IPsec can operate in two modes, but site-to-site VPNs always use tunnel mode:

Why tunnel mode: Allows routing between different networks by encapsulating the entire original packet within a new IP header using the public gateway addresses.

Network Address Translation (NAT) Considerations

NAT fundamentally conflicts with IPsec because:

1. ESP packets can’t be NATed - they’re encrypted end-to-end
2. IKE packets contain IP addresses - NAT breaks the cryptographic integrity
3. Multiple clients behind NAT - can’t distinguish between connections

NAT Traversal (NAT-T) solves this by:

• Detecting NAT devices during negotiation
• Encapsulating ESP packets in UDP port 4500
• Using special keepalive packets to maintain NAT mappings

Authentication Methods Comparison

Pre-Shared Keys (PSK)

Pros: Simple to configure, no certificate infrastructure needed Cons: Vulnerable to offline attacks, doesn’t scale, shared secret management

/ip ipsec identity
add peer=site-b secret=VeryLongRandomStringThatIsHardToGuess123!

Security note: PSK is vulnerable to offline dictionary attacks in all exchange modes. Use certificates for production deployments.

Digital Certificates (Recommended)

Pros: Strong authentication, scalable, supports certificate revocation Cons: Requires PKI setup, more complex initial configuration

/ip ipsec identity
add auth-method=digital-signature certificate=site-a-cert peer=site-b

Best practice: Use certificates with proper CN/SAN fields and maintain a certificate authority for revocation capabilities.

Site-to-Site Topology Patterns

Hub-and-Spoke

One central site connects to multiple branch offices:

Configuration strategy: Hub uses passive mode, branches initiate connections

Mesh (Full Connectivity)

Every site connects directly to every other site:

Configuration strategy: Each site needs peers for all other sites

Redundant Paths

Multiple connections between critical sites:

Configuration strategy: Use routing protocols (OSPF/BGP) over IPsec tunnels

Configuration Steps

This section provides a minimal testable configuration for establishing an IKEv2 site-to-site tunnel between two MikroTik routers.

Step 1: Configure Site A (Initiator)

Create the peer configuration pointing to Site B’s public IP:

/ip ipsec peer add address=203.0.2.1/32 exchange-mode=ike2 name=site-b

Step 2: Configure Site A Identity

Set up authentication using a pre-shared key:

/ip ipsec identity add peer=site-b secret=TestSecret123 auth-method=pre-shared-key

Step 3: Configure Site A Policy

Define which networks should be encrypted (10.1.0.0/24 to 10.2.0.0/24):

/ip ipsec policy add src-address=10.1.0.0/24 dst-address=10.2.0.0/24 tunnel=yes peer=site-b

Step 4: Configure Site B (Responder)

Configure Site B to accept connections from Site A:

/ip ipsec peer add address=203.0.1.1/32 exchange-mode=ike2 name=site-a passive=yes
/ip ipsec identity add peer=site-a secret=TestSecret123 auth-method=pre-shared-key
/ip ipsec policy add src-address=10.2.0.0/24 dst-address=10.1.0.0/24 tunnel=yes peer=site-a

Verification

Check that the IKE_SA (Phase 1) is established:

/ip ipsec active-peers print

Expected Output:

# REMOTE-ADDRESS STATE UPTIME PH2-TOTAL
0 203.0.2.1       established 00:01:23 1

Verify the CHILD_SA (Phase 2) and traffic policies:

/ip ipsec policy print detail

Expected Output:

0 src-address=10.1.0.0/24 dst-address=10.2.0.0/24 protocol=all
  action=encrypt level=require ipsec-protocols=esp tunnel=yes
  sa-src-address=203.0.1.1 sa-dst-address=203.0.2.1
  proposal=default ph2-count=1 ph2-state=established

Advanced Configuration Concepts

Profiles and Proposals: Controlling Cryptography

Profiles control Phase 1 (IKE_SA) parameters:

/ip ipsec profile
add name=strong-ike2
    dh-group=ecp256,modp2048
    enc-algorithm=aes-256,aes-128
    hash-algorithm=sha256
    lifetime=8h

Proposals control Phase 2 (CHILD_SA) parameters:

/ip ipsec proposal
add name=strong-esp
    enc-algorithms=aes-256-gcm,aes-256-cbc
    auth-algorithms=sha256
    pfs-group=ecp256
    lifetime=1h

Why separate them: Different security requirements and rekey intervals optimize both security and performance.

Dead Peer Detection (DPD)

DPD detects when the remote peer becomes unreachable:

/ip ipsec profile
set [find name=strong-ike2] dpd-interval=30s dpd-maximum-failures=3

How it works:

1. Send DPD probe every 30 seconds during idle periods
2. After 3 consecutive failures (90 seconds), declare peer dead
3. Tear down SAs and attempt reconnection

Tuning considerations:

• Shorter intervals = faster failover, more overhead
• Longer intervals = less overhead, slower failover
• Consider link characteristics (satellite, cellular, etc.)

Mode Configuration for Dynamic Networks

Mode config allows dynamic IP assignment and network advertisement:

# Responder (assigns addresses)
/ip ipsec mode-config
add name=branch-config
    address-pool=branch-pool
    split-include=10.0.0.0/8,192.168.0.0/16
    system-dns=yes

# Initiator (requests configuration)
/ip ipsec mode-config
add name=request-config responder=no

/ip ipsec identity
add peer=hub mode-config=request-config generate-policy=port-strict

Use cases:

• Branch offices with dynamic public IPs
• Road warrior scenarios
• Automatic route distribution

Traffic Selectors and Policy Granularity

Traffic selectors define exactly which traffic gets encrypted:

# Encrypt all traffic between sites
/ip ipsec policy
add src-address=10.1.0.0/24 dst-address=10.2.0.0/24 tunnel=yes

# Encrypt only specific services
/ip ipsec policy
add src-address=10.1.0.0/24 src-port=any
    dst-address=10.2.100.5/32 dst-port=443
    protocol=tcp tunnel=yes

# Multiple policies for different traffic types
/ip ipsec policy
add src-address=10.1.100.0/24 dst-address=10.2.100.0/24 tunnel=yes proposal=high-security
add src-address=10.1.200.0/24 dst-address=10.2.200.0/24 tunnel=yes proposal=standard-security

Design principle: Start broad, narrow down based on security requirements and performance needs.

Firewall Integration and NAT Bypass

The NAT Bypass Problem

IPsec policies are processed after NAT, which can break encryption:

Solution: Bypass NAT for IPsec traffic:

/ip firewall nat
add chain=srcnat action=accept
    src-address=10.1.0.0/24 dst-address=10.2.0.0/24
    place-before=0

Critical: This rule must be first in the NAT chain.

FastTrack Bypass

FastTrack bypasses normal packet processing, including IPsec:

/ip firewall filter
add chain=forward action=accept
    src-address=10.1.0.0/24 dst-address=10.2.0.0/24
    connection-state=established,related
    place-before=[find action=fasttrack-connection]

Alternative (better performance): Use raw rules to bypass connection tracking:

/ip firewall raw
add chain=prerouting action=notrack
    src-address=10.1.0.0/24 dst-address=10.2.0.0/24
add chain=prerouting action=notrack
    src-address=10.2.0.0/24 dst-address=10.1.0.0/24

IPsec Policy Matcher

Verify traffic is actually encrypted:

/ip firewall filter
add chain=forward action=accept
    ipsec-policy=in,ipsec
    src-address=10.2.0.0/24 dst-address=10.1.0.0/24
add chain=forward action=drop
    src-address=10.2.0.0/24 dst-address=10.1.0.0/24
    log=yes log-prefix="UNENCRYPTED"

Use case: Ensure critical traffic is never transmitted unencrypted.

Routing Over IPsec Tunnels

Static Routes

Simple point-to-point connectivity:

# Site A: Route to Site B networks
/ip route add dst-address=10.2.0.0/24 gateway=203.0.2.1

# Site B: Route to Site A networks
/ip route add dst-address=10.1.0.0/24 gateway=203.0.1.1

Dynamic Routing with GRE

For complex topologies, run routing protocols over IPsec:

# Create GRE tunnel over IPsec
/interface gre
add name=gre-to-site-b
    local-address=203.0.1.1
    remote-address=203.0.2.1

# Assign tunnel IPs
/ip address add address=172.16.1.1/30 interface=gre-to-site-b

# Run OSPF over the tunnel
/routing ospf interface-template
add area=backbone interfaces=gre-to-site-b

Benefits:

• Automatic failover
• Load balancing across multiple paths
• Simplified configuration for mesh topologies

Policy-Based vs Route-Based

Policy-Based (MikroTik default):

• Traffic selectors determine what gets encrypted
• Multiple policies per peer possible
• More granular control

Route-Based (with GRE/IPIP):

• All traffic to tunnel interface gets encrypted
• Easier integration with routing protocols
• Simpler troubleshooting

Troubleshooting Common Issues

Phase 1 Failures

Symptom: “no suitable proposal found”

/system logging add topics=ipsec,!debug

Check logs for:

ipsec rejected enctype: DB(prop#1:trns#1):Peer(prop#1:trns#1) = AES-256:AES-128

Solution: Align encryption algorithms between peers:

/ip ipsec profile
set [find name=default] enc-algorithm=aes-256,aes-128,3des

Phase 2 Failures

Symptom: Phase 1 establishes but no traffic flows

Check: Traffic selectors mismatch

/ip ipsec policy print detail

Look for ph2-state=no-phase2 indicating proposal mismatch.

Solution: Ensure both sides have matching src/dst addresses:

# Site A
add src-address=10.1.0.0/24 dst-address=10.2.0.0/24

# Site B
add src-address=10.2.0.0/24 dst-address=10.1.0.0/24

NAT Traversal Issues

Symptom: Works initially, then stops after timeout

Cause: NAT mapping expired

Solution: Enable NAT-T keepalives:

/ip ipsec profile
set [find name=default] nat-traversal=yes

Check: Firewall allows UDP 4500:

/ip firewall filter
add chain=input action=accept protocol=udp dst-port=4500

Identity Mismatch

Symptom: “no matching identity found”

Common causes:

1. Wrong ID format in certificates
2. Mismatched my-id/remote-id settings
3. Certificate CN doesn’t match expected ID

Debug:

/system logging add topics=ipsec,debug

Solution: Verify identity configuration:

/ip ipsec identity
set [find] my-id=fqdn:site-a.company.com remote-id=fqdn:site-b.company.com

Performance Optimization

Hardware Acceleration

Check if your device supports IPsec acceleration:

/ip ipsec installed-sa print detail

Look for hw-aead=yes indicating hardware acceleration is active.

Optimization tips:

• Use AES-GCM for hardware-accelerated devices
• Prefer AES-128 over AES-256 for better performance
• Enable hardware acceleration in proposals:

/ip ipsec proposal
add name=hw-optimized
    enc-algorithms=aes-128-gcm,aes-256-gcm
    auth-algorithms=null

CPU Load Reduction

Disable connection tracking for IPsec traffic:

/ip firewall raw
add chain=prerouting action=notrack src-address=10.1.0.0/24 dst-address=10.2.0.0/24
add chain=prerouting action=notrack src-address=10.2.0.0/24 dst-address=10.1.0.0/24

Use larger DH groups sparingly:

• Group 14 (2048-bit): Good balance of security and performance
• Group 19 (ECP256): Fastest elliptic curve option
• Group 21 (ECP521): Maximum security, significant CPU impact

Bandwidth Optimization

MTU considerations:

• IPsec adds ~60 bytes overhead (ESP + new IP header)
• Set interface MTU to 1436 to avoid fragmentation:

/interface set [find name=ether2] mtu=1436

MSS clamping for TCP traffic:

/ip firewall mangle
add chain=forward action=change-mss new-mss=clamp-to-pmtu protocol=tcp tcp-flags=syn

Security Best Practices

Certificate-Based Authentication

Generate proper certificates with correct extensions:

# CA certificate
/certificate add name=company-ca common-name=company-ca key-usage=key-cert-sign,crl-sign

# Site certificates
/certificate add name=site-a-cert common-name=site-a.company.com
    subject-alt-name=IP:203.0.1.1,DNS:site-a.company.com
    key-usage=digital-signature,key-encipherment

/certificate sign site-a-cert ca=company-ca

Strong Cryptographic Parameters

Recommended Phase 1 profile:

/ip ipsec profile
add name=secure-2024
    dh-group=ecp256,modp2048
    enc-algorithm=aes-256,aes-128
    hash-algorithm=sha256,sha512
    lifetime=8h
    dpd-interval=30s
    dpd-maximum-failures=3

Recommended Phase 2 proposal:

/ip ipsec proposal
add name=secure-2024
    enc-algorithms=aes-256-gcm,aes-128-gcm,aes-256-cbc
    auth-algorithms=sha256,sha512
    pfs-group=ecp256,modp2048
    lifetime=1h

Access Control

Limit IPsec to specific interfaces:

/ip firewall filter
add chain=input action=accept protocol=udp dst-port=500,4500 in-interface=wan
add chain=input action=accept protocol=ipsec-esp in-interface=wan
add chain=input action=drop protocol=udp dst-port=500,4500
add chain=input action=drop protocol=ipsec-esp

Monitor failed authentication attempts:

/system logging add topics=ipsec,error action=remote

Production Deployment Checklist

Pre-Deployment

• Certificate infrastructure planned and implemented
• Network addressing scheme documented
• Firewall rules reviewed and tested
• Backup connectivity method available
• Monitoring and alerting configured

Configuration Validation

• Phase 1 and Phase 2 establish successfully
• Traffic flows bidirectionally
• NAT bypass rules in place
• FastTrack bypass configured
• DPD parameters tuned for link characteristics

Security Verification

• Strong cryptographic algorithms selected
• Certificate validation working
• Access control rules implemented
• Logging and monitoring active
• Regular security updates scheduled

Performance Testing

• Throughput meets requirements
• Latency acceptable for applications
• CPU utilization under load acceptable
• Failover time meets SLA requirements
• Hardware acceleration verified (if available)

Related Topics

Prerequisites

• IP Address Configuration - interface addressing
• Static Routes - routing remote networks over IPsec
• Firewall Basics - allow UDP 500, 4500 and ESP

Alternative VPN Technologies

• WireGuard VPN - modern, simpler VPN protocol
• L2TP Server - L2TP/IPsec for remote access

Related Topics

• Certificates - certificate-based IPsec authentication
• NAT Masquerade - NAT traversal for IPsec
• OSPF - dynamic routing over IPsec tunnels

References

• MikroTik IPsec Documentation
• RFC 7296 - Internet Key Exchange Protocol Version 2 (IKEv2)
• RFC 4303 - IP Encapsulating Security Payload (ESP)
• NIST SP 800-77 Rev. 1 - Guide to IPsec VPNs