Securing Branch Connectivity Without the ‘Vendor Tax’
Connecting multiple office locations often drives infrastructure teams toward expensive, proprietary hardware. While Cisco or Fortinet appliances are rock-solid, the licensing fees for high-throughput features can easily exceed $2,000 per year per node.
Last year, I migrated our core infrastructure to a StrongSwan-based Site-to-Site VPN. Running on standard Ubuntu nodes, this setup now handles 850 Mbps of sustained database replication and VoIP traffic between our primary data center and three regional branches. We haven’t seen a single minute of unplanned downtime since the migration.
StrongSwan is the industry standard for IPsec on Linux. By utilizing the IKEv2 (Internet Key Exchange version 2) protocol, it provides a level of resilience that older IKEv1 setups simply can’t match. It recovers from temporary ISP drops in milliseconds and handles NAT traversal without complex workarounds. If you are managing Linux servers and need to bridge subnets over the public internet, this approach provides a professional-grade tunnel without the vendor lock-in.
Prerequisites and Network Topology
To follow this guide, you will need two Linux instances—ideally Ubuntu 22.04 or Debian 12. For a production tunnel handling over 500 Mbps, I recommend at least 2 vCPUs and 4GB of RAM. Our example uses this layout:
- Site A (HQ):
- Public IP:
1.2.3.4 - Private Subnet:
192.168.10.0/24
- Public IP:
- Site B (Branch):
- Public IP:
5.6.7.8 - Private Subnet:
192.168.20.0/24
- Public IP:
First, verify that IP forwarding is active. Without this, your servers will receive the encrypted packets but won’t know how to pass them to the internal network. Check your current status with sysctl net.ipv4.ip_forward. If the output is 0, enable it permanently.
# Enable IPv4 forwarding immediately
echo "net.ipv4.ip_forward = 1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -pStep 1: Installing the StrongSwan Suite
Getting the software on your system takes less than two minutes. We are installing the core StrongSwan package along with the charon-systemd backend. This allows us to use swanctl, a modern configuration tool that is much more readable and modular than the legacy ipsec.conf files used in older tutorials.
sudo apt update
sudo apt install strongswan libcharon-extra-plugins libcharon-extauth-plugins strongswan-swanctlThe service starts automatically upon installation. However, I usually keep the tunnels down until the configuration is fully validated to avoid flooding the logs with failed handshake attempts.
Step 2: Building the Tunnel Configuration
We will start with Site A. The configuration for Site B will be a logical mirror. Create a new file in the swanctl directory to define your IKEv2 session and traffic selectors.
# Create configuration on Site A
sudo nano /etc/swanctl/conf.d/hq-to-branch.confPaste the following block into the file. We are using a Pre-Shared Key (PSK) here for simplicity, though RSA certificates are better for large-scale deployments with many endpoints.
connections {
hq-to-branch {
remote_addrs = 5.6.7.8
local_addrs = 1.2.3.4
local {
auth = psk
id = 1.2.3.4
}
remote {
auth = psk
id = 5.6.7.8
}
children {
net-to-net {
local_ts = 192.168.10.0/24
remote_ts = 192.168.20.0/24
esp_proposals = aes256-sha256-modp2048
start_action = trap
}
}
version = 2
proposals = aes256-sha256-modp2048
}
}Pay attention to the proposals: The string aes256-sha256-modp2048 is your cryptographic handshake. Both sides must agree on this exactly. The start_action = trap setting is vital for production; it tells the Linux kernel to automatically trigger the VPN the moment an internal server tries to ping the remote subnet.
Securing the Shared Secret
Store your PSK in a dedicated secrets file. Avoid using simple passwords; a 64-character random string is the minimum for production environments.
sudo nano /etc/swanctl/conf.d/secrets.confsecrets {
ike-hq-branch {
id-1 = 1.2.3.4
id-2 = 5.6.7.8
secret = "V3ry_Str0ng_R4ndom_K3y_Th4t_Is_Unique"
}
}Now, repeat this on Site B. Simply swap the local and remote IP addresses and subnets. The secret must remain identical on both servers.
Step 3: Firewall Rules and the MSS ‘Silent Killer’
Many admins get stuck here. You must open UDP ports 500 and 4500 on your public interface. Furthermore, you need to tell your internal firewall to trust the traffic coming from the remote subnet.
# Open IKE and NAT-T ports
sudo ufw allow 500/udp
sudo ufw allow 4500/udp
# Allow the remote branch subnet to talk to local services
sudo ufw allow from 192.168.20.0/24 to anyThere is one hidden trap: MTU fragmentation. IPsec adds headers to every packet, which can push them over the standard 1500-byte MTU limit. This often results in SSH sessions hanging or web pages failing to load. Fix this by clamping the Maximum Segment Size (MSS) via iptables.
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
-j TCPMSS --clamp-mss-to-pmtuStep 4: Monitoring and Validation
Once your files are saved, reload the configuration. swanctl provides much better feedback than a standard service restart.
sudo swanctl --load-allTo see if the tunnel is active, run the --list-sas command. It shows you the security associations, encryption algorithms, and—most importantly—the byte counters for transmitted data.
sudo swanctl --list-sasA healthy tunnel output looks like this:
hq-to-branch: #1, ESTABLISHED, IKEv2
local '1.2.3.4' @ 1.2.3.4[500]
remote '5.6.7.8' @ 5.6.7.8[500]
AES_CBC-256/HMAC_SHA2_256_128/MODP_2048
net-to-net: #1, INSTALLED, TUNNEL, ESP:AES_CBC-256/HMAC_SHA2_256_128
local 192.168.10.0/24
remote 192.168.20.0/24If you don’t see “ESTABLISHED,” check your logs in real-time using journalctl -f -u strongswan. This will pinpoint exactly where the negotiation is failing, whether it’s a mismatched key or a blocked port. In my experience, 90% of failures are due to simple firewall oversights or typos in the remote IP addresses.
Final Thoughts on Stability
After six months of heavy use, the self-healing capability of IKEv2 has been the standout feature. When our ISP performs maintenance at 3:00 AM, StrongSwan’s Dead Peer Detection (DPD) detects the outage and re-establishes the tunnel the second the path is clear. You get full visibility into your encryption layer, no hidden licensing fees, and the ability to scale your bandwidth simply by resizing your VM instance. It’s a massive win for any lean IT operation.
