VPN (Virtual Private Network) technology creates encrypted tunnels over untrusted networks — allowing branch offices, remote workers, and cloud environments to communicate as if they were on the same private network. Choosing the right VPN technology and configuring it correctly is critical — a poorly configured VPN can be as dangerous as no VPN at all.
This guide covers every major VPN scenario an IT team encounters — from branch office site-to-site tunnels between FortiGate firewalls to remote worker SSL VPN, WireGuard deployments, and Always-On VPN configurations — with production-ready configuration examples for the most common platforms.
1 VPN Technology Selection
Selecting the right VPN technology before configuring anything saves significant time — the wrong choice leads to performance problems, compatibility issues, or excessive complexity.
VPN Technology Comparison
| Technology | Use Case | Performance | Complexity | Best For |
|---|
| IPSec IKEv2 |
Site-to-Site, Remote Access |
High |
Medium |
Branch office tunnels, cloud connectivity |
| SSL VPN (TLS) |
Remote Access |
Medium |
Low |
Remote workers, BYOD, firewall-traversal environments |
| WireGuard |
Site-to-Site, Remote Access |
Very High |
Low |
Modern deployments, Linux servers, high-throughput needs |
| OpenVPN |
Remote Access |
Medium |
Medium |
Cross-platform compatibility, certificate-based auth |
| GRE over IPSec |
Site-to-Site + Routing |
High |
High |
Dynamic routing (BGP/OSPF) across VPN tunnels |
| MPLS |
Site-to-Site (ISP-managed) |
Highest |
Low (for customer) |
Enterprise WANs where ISP manages the connectivity |
Decision Framework
- Connecting two fixed offices: IPSec IKEv2 Site-to-Site — static endpoints, high throughput, hardware accelerated on most firewalls
- Remote workers on laptops: SSL VPN (FortiClient, Cisco AnyConnect) or WireGuard — works through NAT and hotel firewalls reliably
- Linux servers communicating securely: WireGuard — minimal overhead, kernel-level performance, extremely simple configuration
- Connecting to Azure / AWS: IPSec IKEv2 — native support on all cloud VPN gateways, predictable behavior
- Need dynamic routing across tunnel: GRE over IPSec or VXLAN over IPSec — required for OSPF/BGP across the tunnel
2 IPSec IKEv2 — Concepts & Phase Design
IPSec operates in two phases — IKE Phase 1 establishes the secure management channel (ISAKMP SA), and IKE Phase 2 establishes the actual data tunnels (IPSec SA). Getting the phase parameters to match exactly on both sides is the most common source of VPN failures.
Recommended Production IPSec Parameters
| Parameter | Phase 1 (IKE) | Phase 2 (IPSec) | Notes |
|---|
| Encryption | AES-256 | AES-256 | AES-256-GCM preferred where supported |
| Integrity / Hash | SHA-256 | SHA-256 | Avoid SHA-1 and MD5 — deprecated |
| DH Group | Group 14 (2048-bit) | Group 14 | Group 19 (256-bit ECDH) for higher security |
| IKE Version | IKEv2 | N/A | Always use IKEv2 — IKEv1 is deprecated |
| Key Lifetime | 28800s (8hr) | 3600s (1hr) | Phase 2 lifetime shorter than Phase 1 |
| Authentication | Pre-Shared Key | N/A | Certificates preferred for production |
| PFS | N/A | Enabled — Group 14 | Perfect Forward Secrecy — always enable |
⚠️ Warning: Never use IKEv1, DES, 3DES, MD5, or SHA-1 in new VPN deployments — these are cryptographically broken or deprecated. Many older firewall configurations still use these weak parameters inherited from legacy setups. Audit all existing VPN tunnels and upgrade to AES-256 + SHA-256 + IKEv2 — the performance difference on modern hardware is negligible and the security improvement is significant.
3 FortiGate Site-to-Site VPN
FortiGate provides native IPSec VPN with hardware acceleration on all models. The configuration via CLI offers the most granular control and is reproducible across deployments.
FortiGate Site A Configuration (HQ)
# =============================================
# FortiGate Site-to-Site VPN — HQ (Site A)
# HQ Public IP: 203.0.113.1
# HQ LAN: 10.10.0.0/24
# Branch Public IP: 198.51.100.1
# Branch LAN: 10.20.0.0/24
# =============================================
# Phase 1 — IKEv2
config vpn ipsec phase1-interface
edit "VPN-to-Branch"
set interface "wan1"
set ike-version 2
set keylife 28800
set peertype any
set net-device disable
set proposal aes256-sha256
set dhgrp 14
set remote-gw 198.51.100.1
set psksecret "Use-A-Strong-32+Char-Key-Here!"
set dpd on-idle
set dpd-retrycount 3
set dpd-retryinterval 20
next
end
# Phase 2 — Traffic Selectors
config vpn ipsec phase2-interface
edit "VPN-to-Branch-P2"
set phase1name "VPN-to-Branch"
set proposal aes256-sha256
set dhgrp 14
set pfs enable
set keylifeseconds 3600
set src-subnet 10.10.0.0 255.255.255.0
set dst-subnet 10.20.0.0 255.255.255.0
set auto-negotiate enable
next
end
# Static Route via VPN tunnel
config router static
edit 10
set dst 10.20.0.0 255.255.255.0
set device "VPN-to-Branch"
set comment "Route-to-Branch-LAN"
next
end
# Firewall Policy — HQ to Branch
config firewall policy
edit 50
set name "HQ-to-Branch"
set srcintf "lan"
set dstintf "VPN-to-Branch"
set srcaddr "HQ-LAN-10.10.0.0/24"
set dstaddr "Branch-LAN-10.20.0.0/24"
set action accept
set schedule "always"
set service "ALL"
set logtraffic all
next
edit 51
set name "Branch-to-HQ"
set srcintf "VPN-to-Branch"
set dstintf "lan"
set srcaddr "Branch-LAN-10.20.0.0/24"
set dstaddr "HQ-LAN-10.10.0.0/24"
set action accept
set schedule "always"
set service "ALL"
set logtraffic all
next
end
✅ Pro Tip: Enable Dead Peer Detection (DPD) with set dpd on-idle on all FortiGate IPSec tunnels. DPD sends keepalive probes when no traffic has flowed for a set interval — it detects a dead peer (e.g., remote firewall rebooted) and triggers IKE renegotiation automatically. Without DPD, a tunnel can appear "up" in the dashboard while actually being broken — passing no traffic — until the next key lifetime expiry.
4 MikroTik Site-to-Site VPN
MikroTik RouterOS implements IPSec natively — the configuration is more granular than most firewalls, requiring separate Peer, Profile, Proposal, Identity, and Policy entries. The RouterOS v7 IPSec engine is significantly improved over v6.
MikroTik IPSec IKEv2 Configuration
# =============================================
# MikroTik Site-to-Site IPSec IKEv2
# Local: 10.10.0.0/24 (behind MikroTik)
# Remote: 10.20.0.0/24 (remote site)
# Remote Gateway: 198.51.100.1
# =============================================
# Step 1: IKEv2 Proposal (Phase 1 + 2 crypto)
/ip ipsec proposal
add name=prop-aes256-sha256 \
enc-algorithms=aes-256-cbc \
auth-algorithms=sha256 \
pfs-group=modp2048 \
lifetime=1h
# Step 2: IKEv2 Profile (IKE parameters)
/ip ipsec profile
add name=profile-ikev2 \
enc-algorithm=aes-256 \
hash-algorithm=sha256 \
dh-group=modp2048 \
lifetime=8h \
dpd-interval=20s \
dpd-maximum-failures=3
# Step 3: Peer (remote gateway)
/ip ipsec peer
add name=peer-branch \
address=198.51.100.1/32 \
profile=profile-ikev2 \
exchange-mode=ike2
# Step 4: Identity (authentication)
/ip ipsec identity
add peer=peer-branch \
auth-method=pre-shared-key \
secret="Use-A-Strong-32+Char-Key-Here!"
# Step 5: Policy (traffic selectors)
/ip ipsec policy
add src-address=10.10.0.0/24 \
dst-address=10.20.0.0/24 \
peer=peer-branch \
proposal=prop-aes256-sha256 \
tunnel=yes \
action=encrypt
# Step 6: Srcnat exclusion (do NOT NAT VPN traffic)
/ip firewall nat
add chain=srcnat \
src-address=10.10.0.0/24 \
dst-address=10.20.0.0/24 \
action=accept \
place-before=0 \
comment="Exclude-VPN-traffic-from-NAT"
⚠️ Warning: The NAT exclusion rule (Step 6) is critical and frequently missed — it must be placed BEFORE the masquerade rule in the NAT chain. Without it, VPN-destined traffic gets NATed to the WAN IP before being encrypted, which breaks the tunnel because the traffic selector no longer matches the expected source subnet. This is the most common MikroTik VPN misconfiguration causing "tunnel up but no traffic passing" symptoms.
5 SSL VPN — Remote Access
SSL VPN allows remote workers to connect to the corporate network over HTTPS (port 443) — making it highly firewall-friendly since port 443 is almost never blocked, even in hotels, airports, or restrictive corporate guest networks.
FortiGate SSL VPN Configuration
# SSL VPN Settings
config vpn ssl settings
set status enable
set port 443
set source-interface "wan1"
set source-address "all"
set default-portal "web-access"
set idle-timeout 300
set auth-timeout 28800
set login-attempt-limit 3
set login-block-time 60
set dtls-tunnel enable
set certificate "SSLVPN-CERT"
end
# SSL VPN IP Pool for remote clients
config firewall address
edit "SSLVPN-IP-Pool"
set type iprange
set start-ip 10.200.0.1
set end-ip 10.200.0.100
next
end
# SSL VPN Portal
config vpn ssl web portal
edit "remote-access-portal"
set tunnel-mode enable
set ip-pools "SSLVPN-IP-Pool"
set split-tunneling enable
set split-tunneling-routing-address "Corporate-Internal-Subnets"
set dns-server1 10.10.0.53
set wins-server1 10.10.0.53
next
end
# Firewall policy — SSL VPN users to internal
config firewall policy
edit 100
set name "SSLVPN-to-Internal"
set srcintf "ssl.root"
set dstintf "lan"
set srcaddr "SSLVPN-IP-Pool"
set dstaddr "Corporate-Internal-Subnets"
set action accept
set schedule "always"
set service "ALL"
set logtraffic all
set utm-status enable
set av-profile "default"
set ips-sensor "default"
next
end
SSL VPN User Authentication
- Local users: Suitable for small teams — create user accounts in FortiGate directly with strong passwords
- LDAP / Active Directory: Recommended for organizations with AD — users authenticate with their domain credentials
- RADIUS: Integrates with any RADIUS server — enables MFA via RSA SecurID, Duo Security, or similar
- Certificate-based: Client certificates deployed via MDM — strongest authentication, eliminates password risks
- Two-factor (FortiToken): FortiGate supports FortiToken Mobile for TOTP — enable for all SSL VPN users in production
✅ Pro Tip: Always enable Two-Factor Authentication (2FA) for SSL VPN — compromised VPN credentials are among the top initial access vectors used by ransomware groups. FortiToken Mobile is free for up to 10 tokens — use it for small teams. For larger deployments, integrate with Duo Security or Microsoft Entra MFA via RADIUS — any TOTP solution is vastly better than username/password alone.
6 WireGuard — Modern VPN
WireGuard is a modern VPN protocol built into the Linux kernel since version 5.6 — it is dramatically simpler than IPSec, significantly faster, and uses state-of-the-art cryptography (Curve25519, ChaCha20, Poly1305). It is ideal for server-to-server connectivity and technically proficient remote users.
WireGuard Server Setup (Ubuntu Linux)
# Install WireGuard
sudo apt update && sudo apt install wireguard -y
# Generate server key pair
wg genkey | sudo tee /etc/wireguard/server_private.key | \
wg pubkey | sudo tee /etc/wireguard/server_public.key
# Create WireGuard interface config
sudo nano /etc/wireguard/wg0.conf
# /etc/wireguard/wg0.conf — Server
[Interface]
Address = 10.200.0.1/24
ListenPort = 51820
PrivateKey =
# Enable IP forwarding
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; \
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; \
iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
# Peer 1 — Remote Worker Laptop
[Peer]
PublicKey =
AllowedIPs = 10.200.0.2/32
# Peer 2 — Branch Office Server
[Peer]
PublicKey =
AllowedIPs = 10.200.0.3/32, 10.20.0.0/24WireGuard Client Setup (Windows / Linux)
# Generate client key pair (run on client)
wg genkey | tee client_private.key | wg pubkey > client_public.key
# /etc/wireguard/wg0.conf — Client
[Interface]
Address = 10.200.0.2/24
PrivateKey =
DNS = 10.10.0.53
# Server peer
[Peer]
PublicKey =
Endpoint = 203.0.113.1:51820
AllowedIPs = 10.10.0.0/24, 10.20.0.0/24 # Split tunnel — only internal traffic via VPN
PersistentKeepalive = 25
# Enable and start
sudo systemctl enable wg-quick@wg0
sudo systemctl start wg-quick@wg0
✅ Pro Tip: WireGuard's PersistentKeepalive = 25 sends a keepalive packet every 25 seconds — essential for clients behind NAT (laptops, mobile devices) where the NAT table entry would otherwise expire during periods of inactivity, causing the tunnel to drop. Set this on all client configurations — it adds minimal bandwidth overhead (1 packet per 25 seconds) while ensuring the tunnel stays up reliably.
7 Always-On VPN & Split Tunneling
Always-On VPN automatically connects the VPN tunnel when the device starts — before the user logs in — and keeps it connected at all times. Split tunneling controls which traffic goes through the VPN and which goes directly to the internet.
Split Tunneling Modes
| Mode | How It Works | Security | Performance | Best For |
|---|
| Full Tunnel |
ALL traffic routed through VPN — internet included |
Highest |
Lowest — HQ bandwidth bottleneck |
High-security environments, compliance requirements |
| Split Tunnel |
Only internal subnets via VPN — internet direct |
Medium |
High — internet not bottlenecked |
Most enterprise remote access deployments |
| Inverse Split |
All traffic via VPN except specific cloud apps direct |
High |
Medium |
Microsoft 365, Zoom optimization with VPN security |
FortiClient Always-On VPN (EMS Managed)
- Deploy FortiClient EMS (Endpoint Management Server) — manages FortiClient policies centrally
- Create VPN profile in EMS: Endpoint Profiles → VPN → Add VPN
- Enable Auto Connect — tunnel connects automatically on system start
- Enable Always On VPN — prevents users from disabling the VPN connection
- Configure split tunnel routes — add only internal subnets (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) to the VPN routing table
- Deploy profile via EMS to all domain-joined endpoints — applied automatically via FortiClient agent
⚠️ Warning: Always-On VPN requires careful planning of the pre-logon authentication mechanism — the tunnel must connect before the user logs in for domain authentication to work correctly (Group Policy, drive mappings, certificate enrollment all depend on domain connectivity at logon). Test the complete logon flow including password changes and new device enrollment before deploying Always-On to all users.
8 VPN Monitoring & Troubleshooting
VPN issues fall into three categories — tunnel not establishing (Phase 1 failure), tunnel establishes but no traffic passes (Phase 2 or routing failure), and tunnel is intermittently dropping (DPD, NAT, or ISP issues). Knowing which category you are in immediately cuts troubleshooting time in half.
FortiGate VPN Diagnostics
# Check tunnel status
diagnose vpn tunnel list
# Check IKE negotiations in real time
diagnose debug application ike -1
diagnose debug enable
# (reproduce the issue, then:)
diagnose debug disable
diagnose debug reset
# Check Phase 1 SA
diagnose vpn ike gateway list
# Check Phase 2 SA
diagnose vpn tunnel list name VPN-to-Branch
# Check routing
get router info routing-table all | grep 10.20.0.0
# Test traffic flow through tunnel
execute ping-options source 10.10.0.1
execute ping 10.20.0.1
MikroTik IPSec Diagnostics
# Check active IPSec SAs
/ip ipsec active-peers print
/ip ipsec installed-sa print
# Check IPSec policy matching
/ip ipsec policy print
# Enable IPSec debug logging (RouterOS v7)
/system logging add topics=ipsec,ipsec-esp action=memory
# View real-time logs
/log print follow where topics~"ipsec"
# Check if NAT exclusion is working
/ip firewall connection print where dst-address~"10.20.0"
Common VPN Issues & Fixes
- "No proposal chosen" error: Phase 1 or 2 crypto parameters do not match on both sides — compare encryption, hash, and DH group on both firewalls character by character
- Tunnel up but no traffic: Missing NAT exclusion rule OR missing firewall policy OR route pointing to wrong interface — check all three in order
- Tunnel drops every hour: Phase 2 keylife mismatch — one side has 1 hour, other has 8 hours. When shorter side expires and re-keys, the mismatch causes a brief outage
- Tunnel up from one side only: Asymmetric routing — traffic goes via VPN but returns via the internet. Check routing tables on both sides — return route must also point via tunnel
- Random drops during the day: ISP blocking UDP port 500/4500 (IKE/NAT-T) or ESP protocol — try enabling NAT Traversal and forcing UDP encapsulation
- SSL VPN connects but cannot reach internal resources: Split tunnel routes not pushed to client, or firewall policy missing between ssl.root interface and LAN — check both
✅ Pro Tip: Set up automated VPN monitoring with PRTG, Zabbix, or LibreNMS — configure SNMP traps or syslog alerts for tunnel state changes. Many VPN outages go unreported for hours because users assume the issue is on their end. A monitoring alert that fires within 60 seconds of a tunnel going down — with the tunnel name, time, and last known state — transforms VPN troubleshooting from reactive to proactive.
Need Help Configuring Your VPN?
EnterWeb IT Firm configures site-to-site and remote access VPN solutions across FortiGate, MikroTik, Cisco, pfSense, and cloud gateways. We design, deploy, and troubleshoot VPN infrastructure for organizations across India — with 24/7 support options available.