When building a secure overlay network across untrusted infrastructure, two dominant protocols emerge: OpenVPN (SSL/TLS-based) and IPsec (IETF standard). The ideal solution must handle:
- Static server-to-server connections (persistent tunnels)
- Road warrior clients (dynamic IP endpoints)
- Full network transparency (broadcast/multicast support)
- Minimal administrative overhead
OpenVPN's SSL/TLS Advantage
Operates at layer 2/3 with tun/tap drivers. Sample server config:
proto udp dev tun topology subnet server 10.8.0.0 255.255.255.0 push "route 192.168.1.0 255.255.255.0" tls-server ca /etc/openvpn/ca.crt cert /etc/openvpn/server.crt
IPsec's Kernel-Level Performance
Uses IKEv1/v2 for key exchange with strongSwan example:
conn %default
ikelifetime=60m
keylife=20m
rekeymargin=3m
conn site-to-site
left=1.2.3.4
leftsubnet=192.168.1.0/24
right=5.6.7.8
rightsubnet=192.168.2.0/24
auto=start
| Criteria | OpenVPN | IPsec |
|---|---|---|
| NAT Traversal | Excellent (UDP mode) | Requires NAT-T |
| Firewall Friendliness | Single UDP port | Multiple protocols |
| Client OS Support | Cross-platform | Kernel-dependent |
| Throughput | ~200 Mbps | ~800 Mbps |
| Debugging | Verbose logs | Complex diagnostics |
For hybrid environments with both static servers and mobile clients:
OpenVPN for Road Warriors
Client configuration example:
client remote vpn.example.com 1194 dev tun resolv-retry infinite remote-cert-tls server <cert> -----BEGIN CERTIFICATE----- [client cert data] -----END CERTIFICATE----- </cert>
IPsec for Server Links
Consider VTI interfaces for routing:
ip tunnel add vti0 local 1.2.3.4 remote 5.6.7.8 mode vti ip addr add 10.0.0.1/30 dev vti0 ip link set vti0 up
- OpenVPN: Use
verb 4for connection debugging - IPsec:
charon-loggingconfig for IKE details - Packet capture filters:
udp port 500 or 4500(IPsec) vsudp port 1194(OpenVPN)
When establishing a secure private LAN over untrusted networks, two primary VPN protocols emerge as viable solutions: OpenVPN and IPsec. The key technical requirements include:
- Support for both static server connections and dynamic "road warrior" clients
- Full network transparency (broadcast/multicast support)
- Secure tunneling over public infrastructure
OpenVPN Implementation
OpenVPN operates at layer 2/3 using TLS for key exchange. Sample server configuration:
# openvpn-server.conf proto udp port 1194 dev tun topology subnet server 10.8.0.0 255.255.255.0 push "route 192.168.1.0 255.255.255.0" tls-server ca ca.crt cert server.crt key server.key dh dh.pem keepalive 10 120
IPsec Implementation
IPsec operates at layer 3 with IKEv2 for key management. StrongSwan configuration example:
# /etc/ipsec.conf
config setup
charondebug="ike 2, knl 2, cfg 2"
conn %default
ikelifetime=60m
keylife=20m
rekeymargin=3m
keyingtries=1
keyexchange=ikev2
authby=secret
conn lan-to-lan
left=203.0.113.1
leftsubnet=192.168.1.0/24
right=198.51.100.1
rightsubnet=192.168.2.0/24
auto=start
| Metric | OpenVPN | IPsec |
|---|---|---|
| Encryption Overhead | Higher (user-space) | Lower (kernel-space) |
| NAT Traversal | Built-in | Requires NAT-T |
| Multicast Support | Limited | Native |
| Client OS Support | Cross-platform | Varies by implementation |
For dynamic clients, OpenVPN's client configuration flexibility shines:
# client.ovpn client dev tun proto udp remote vpn.example.com 1194 resolv-retry infinite nobind persist-key persist-tun remote-cert-tls server ca ca.crt cert client.crt key client.key
Common diagnostic commands for both protocols:
# OpenVPN openvpn --verb 4 --config server.conf # IPsec ipsec statusall ipsec up lan-to-lan journalctl -u strongswan -f
For mixed environments with both static servers and dynamic clients, OpenVPN provides better out-of-the-box usability. However, for pure site-to-site connections with multicast requirements, IPsec implementations like StrongSwan may be preferable.