The VPN Landscape: More Than Just Encryption
When someone says "VPN," most people picture a browser plugin their IT team installed to let them work from home. Engineers know better. VPN is an umbrella term covering several fundamentally different technologies, each with distinct packet-handling mechanics, performance tradeoffs, and failure modes. Picking the wrong one doesn't just cause headaches — it can mean encrypted tunnels with no multicast support, hub-and-spoke topology that kills your WAN performance, or a remote-access solution that falls apart under load.
This article breaks down the four technologies you'll encounter in enterprise and service-provider environments: IPSec, GRE, DMVPN, and SSL/TLS VPN. I'll cover how each one actually works at the packet level, where each fits, and where each will let you down.
IPSec: The Industry Standard for Encrypted Tunnels
What It Is
IPSec (Internet Protocol Security) is a suite of protocols defined across a family of RFCs that provide authentication, integrity, and encryption at the IP layer. It's not a single protocol — it's a framework. When you configure an IPSec tunnel, you're actually orchestrating several components working together: IKE (Internet Key Exchange) for negotiating the security association, AH (Authentication Header) or ESP (Encapsulating Security Payload) for the actual data protection, and the SA (Security Association) database that tracks negotiated parameters on both ends.
How It Works
IPSec operates in two modes. Tunnel mode wraps the entire original IP packet inside a new IP header — this is what you use for site-to-site VPNs. Transport mode only encrypts the payload and is mainly used for host-to-host scenarios. In practice, site-to-site means tunnel mode almost always.
The negotiation happens in two phases. IKE Phase 1 establishes a secure channel between the peers using Diffie-Hellman key exchange, authenticating with pre-shared keys or certificates. IKE Phase 2 uses that secure channel to negotiate the actual IPSec SAs — the specific encryption and hashing algorithms applied to your traffic. You end up with bidirectional SAs: one for each direction of traffic.
ESP is the workhorse you'll use 99% of the time. It encrypts the payload and optionally provides authentication. AH only provides authentication with no encryption, which means your payload is still readable — I've rarely seen AH used in production outside of specific compliance scenarios where integrity verification matters more than confidentiality.
A basic IKEv2 configuration on a Cisco IOS router looks like this:
crypto ikev2 proposal INFRARUNBOOK-PROP
encryption aes-cbc-256
integrity sha256
group 14
!
crypto ikev2 policy INFRARUNBOOK-POL
proposal INFRARUNBOOK-PROP
!
crypto ikev2 keyring INFRARUNBOOK-KEYS
peer HQ-PEER
address 203.0.113.10
pre-shared-key local Str0ngP@ssphrase!
pre-shared-key remote Str0ngP@ssphrase!
!
crypto ikev2 profile INFRARUNBOOK-PROF
match identity remote address 203.0.113.10 255.255.255.255
authentication remote pre-share
authentication local pre-share
keyring local INFRARUNBOOK-KEYS
!
crypto ipsec transform-set INFRARUNBOOK-TS esp-aes 256 esp-sha256-hmac
mode tunnel
!
crypto map INFRARUNBOOK-MAP 10 ipsec-isakmp
set peer 203.0.113.10
set transform-set INFRARUNBOOK-TS
set ikev2-profile INFRARUNBOOK-PROF
match address ACL-CRYPTOWhy It Matters
IPSec is the backbone of site-to-site enterprise connectivity. It's standards-based, meaning a Cisco router will negotiate an SA with a Juniper SRX or a Palo Alto firewall with proper configuration. It supports strong encryption (AES-256-GCM being the current go-to), and IKEv2 brought significant improvements over IKEv1: reduced round-trip negotiation, built-in NAT traversal support, and a more resilient rekeying mechanism.
The limitation that trips people up most often is that raw IPSec doesn't carry multicast traffic. It's a point-to-point encrypted channel for unicast IP. If you need routing protocols that rely on multicast — OSPF, EIGRP, PIM — running over an IPSec tunnel, you'll need GRE underneath or a different approach entirely. That's not a bug; it's just what the protocol was designed to do.
GRE: The Protocol That Carries Everything Else
What It Is
Generic Routing Encapsulation (GRE), defined in RFC 2784, is a tunneling protocol that wraps packets from one protocol inside packets of another protocol. In networking this typically means wrapping IP packets — or multicast, broadcast, and even non-IP protocols — inside standard IP packets so they can traverse a network that wouldn't otherwise support them. GRE itself provides zero encryption and zero authentication. It's a transport mechanism, not a security mechanism. Full stop.
How It Works
GRE adds a 4-byte header between the outer IP header and the original packet. The outer IP header carries the tunnel endpoint addresses. The GRE header contains a protocol type field that tells the receiving endpoint what protocol is encapsulated inside. This is what makes GRE flexible — it can carry IPv4, IPv6, MPLS, IPX, and multicast traffic through a standard IP network that would otherwise drop or ignore them.
A GRE tunnel interface configuration on a Linux host running a routing daemon:
# Create a GRE tunnel interface on sw-infrarunbook-01
ip tunnel add gre0 mode gre \
local 10.10.0.1 \
remote 10.20.0.1 \
ttl 255
ip link set gre0 up
ip addr add 172.16.100.1/30 dev gre0
# Add a route through the tunnel
ip route add 192.168.20.0/24 via 172.16.100.2 dev gre0From that point, OSPF hellos, EIGRP updates, PIM multicast join messages — anything that needs to traverse the tunnel — flows through that interface just like it would over a physical link. The remote end decapsulates, sees the inner protocol, and handles it normally.
Why It Matters
GRE's real-world value is almost always as the inner transport for something else. You run GRE over IPSec to get encrypted, multicast-capable tunnels. You use GRE in DMVPN as the spoke-to-spoke dynamic tunnel mechanism. On its own, GRE tunnels are useful for connecting islands of incompatible address space, carrying routing protocol traffic across provider networks, or building manual overlay networks in environments where you control both endpoints.
In my experience, bare GRE tunnels in production are a reliability hazard if you don't plan for MTU carefully from the start. The GRE header eats 24 bytes. If your underlying path MTU is 1500 (standard Ethernet), your effective MTU inside the tunnel drops to 1476. Add IPSec overhead on top and you're looking at 1400–1420 bytes before fragmentation becomes a problem. Set your tunnel interface MTU and TCP MSS clamping early — don't wait for large HTTP responses or file transfers to expose it in production.
# Set MTU and clamp TCP MSS for GRE over IPSec on sw-infrarunbook-01
ip link set gre0 mtu 1400
# Clamp TCP MSS with iptables to avoid fragmentation
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
-o gre0 -j TCPMSS --set-mss 1360DMVPN: Hub-and-Spoke That Actually Scales
What It Is
Dynamic Multipoint VPN (DMVPN) is a technology that combines GRE, IPSec, and NHRP (Next Hop Resolution Protocol) to create a scalable hub-and-spoke VPN architecture where spoke-to-spoke traffic can bypass the hub dynamically. It was designed to solve the configuration explosion problem of traditional static IPSec mesh networks — where adding a 50th site means updating IPSec configuration on all 49 existing sites simultaneously. That doesn't scale, and DMVPN fixes it.
How It Works
DMVPN introduces three components working in concert. The hub router runs a multipoint GRE (mGRE) interface — a single tunnel interface that accepts connections from multiple spokes without requiring a separate tunnel interface per spoke. All spokes register their current public IP address with the hub using NHRP. When a spoke needs to communicate directly with another spoke, it queries the hub's NHRP server to resolve the target spoke's current public IP, then builds a direct spoke-to-spoke IPSec+GRE tunnel on the fly. That direct tunnel stays up as long as there's traffic and tears down when idle.
DMVPN is deployed in phases that represent increasing sophistication. Phase 1 is traditional hub-and-spoke — all spoke-to-spoke traffic hairpins through the hub, no exceptions. Phase 2 enables direct spoke-to-spoke tunnels but requires the hub to advertise spoke-specific prefixes, because summarization at the hub breaks the NHRP resolution. Phase 3 is the mature deployment model: it uses NHRP redirect messages so the hub signals spokes to build a direct path, and route summarization works correctly at the hub because the routing decision happens at the spoke level after NHRP resolution.
Hub configuration skeleton for DMVPN Phase 3:
interface Tunnel0
ip address 172.16.200.1 255.255.255.0
no ip redirects
ip nhrp map multicast dynamic
ip nhrp network-id 100
ip nhrp server-only
ip nhrp redirect
tunnel source GigabitEthernet0/0
tunnel mode gre multipoint
tunnel key 100
tunnel protection ipsec profile DMVPN-PROFILE
!
ip nhrp authentication solvenet01Spoke configuration skeleton:
interface Tunnel0
ip address 172.16.200.10 255.255.255.0
ip nhrp map 172.16.200.1 203.0.113.1
ip nhrp map multicast 203.0.113.1
ip nhrp network-id 100
ip nhrp nhs 172.16.200.1
ip nhrp shortcut
tunnel source GigabitEthernet0/0
tunnel mode gre multipoint
tunnel key 100
tunnel protection ipsec profile DMVPN-PROFILEWhy It Matters
DMVPN is a serious WAN technology. I've seen it deployed at enterprises with hundreds of remote sites, all connecting through two hub routers for redundancy, with EIGRP or OSPF running over the tunnels for dynamic routing. Adding a new site means configuring only the new spoke — the hub handles the rest dynamically through NHRP. That operational simplicity at scale is the core value proposition, and it's real.
Phase 3 with NHRP shortcut gives you the best of both worlds: hub-based routing control combined with direct data-plane paths when two spokes need to talk at volume. Your application performance doesn't degrade because traffic is making two hops through a hub router at headquarters — the shortcut kicks in and builds a direct tunnel.
The failure mode to know about: NHRP registration failures. If a spoke's public IP changes and NHRP doesn't re-register cleanly, the hub's NHRP cache goes stale and spoke-to-spoke shortcuts stop working. I've seen this happen with asymmetric NAT on ISP links where the translated IP differed from what the spoke thought it was. Always configure NHRP hold timers conservatively, enable NHRP registration retries, and monitor the NHRP table entries on your hub routers.
SSL/TLS VPN: Remote Access Done Right
What It Is
SSL VPN — more accurately TLS VPN in modern deployments, since SSL itself is deprecated and broken — is a remote-access technology that runs the VPN tunnel over TLS, the same protocol that secures HTTPS. Unlike IPSec, which operates at the network layer, SSL VPNs typically run at the application or session layer. That architectural difference means they traverse firewalls, NAT, and restrictive hotel or coffee shop networks far more reliably, because the traffic looks like normal HTTPS to intermediate devices that might otherwise block or interfere with IPSec.
How It Works
SSL VPN comes in two main flavors. Clientless SSL VPN runs entirely in a browser — the VPN gateway acts as a reverse proxy, rewriting URLs and injecting JavaScript to give users access to internal web applications without installing any software. This works reasonably well for web-based apps but fails with anything that isn't HTTP-based. You won't be running a thick client application or an RDP session through a purely clientless SSL VPN without significant additional complexity.
Full-tunnel SSL VPN requires a lightweight client such as Cisco AnyConnect or OpenVPN. The client establishes a TLS connection to the VPN gateway, authenticates (often with MFA and certificate validation), and receives a virtual IP address from a configured pool. From that point, traffic is tunneled through the TLS connection and the gateway injects it into the internal network on the user's behalf. Split tunneling is configurable — you can route only specific subnets through the VPN while letting internet traffic exit locally, or force all traffic through the tunnel for inspection and policy enforcement.
OpenVPN server configuration for solvethenetwork.com remote access:
# /etc/openvpn/server/solvethenetwork-vpn.conf
port 1194
proto udp
dev tun
ca /etc/openvpn/pki/ca.crt
cert /etc/openvpn/pki/issued/sw-infrarunbook-01.crt
key /etc/openvpn/pki/private/sw-infrarunbook-01.key
dh /etc/openvpn/pki/dh.pem
tls-auth /etc/openvpn/ta.key 0
server 172.16.50.0 255.255.255.0
push "route 10.10.0.0 255.255.0.0"
push "route 10.20.0.0 255.255.0.0"
push "dhcp-option DNS 10.10.0.53"
cipher AES-256-GCM
auth SHA256
tls-version-min 1.2
tls-cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384
keepalive 10 120
user nobody
group nogroup
persist-key
persist-tun
verb 3Why It Matters
SSL VPN won the remote-access wars, and the reason is simple: it works everywhere. IPSec has long had NAT traversal challenges — UDP port 4500 for NAT-T helps, but not every network passes it cleanly, and some corporate guest networks actively block it. SSL VPN on TCP/443 or UDP/443 gets through hotel WiFi, corporate guest networks, and carrier-grade NAT without ceremony. For a distributed workforce connecting from arbitrary locations on networks you don't control, that reliability is worth the slightly higher overhead compared to raw IPSec.
Modern implementations like WireGuard blur some of these category lines. WireGuard uses UDP and its own cryptographic framework (the Noise protocol), sits at the kernel level for performance, and has a radically simpler codebase than OpenVPN or IPSec. It's not technically SSL VPN, but it's absorbed much of the same use case in environments where you control client software and can open the necessary UDP port. If you're building a new remote-access solution from scratch and don't have legacy client constraints, WireGuard deserves serious evaluation.
Side-by-Side: Choosing the Right Tool
IPSec is your site-to-site workhorse when you need standards-based interoperability and strong encryption. It's the right answer when connecting to a partner network, a cloud provider's VPN gateway (AWS, Azure, GCP all support it natively), or when your two endpoints are from different vendors. It doesn't carry multicast natively, and IKE negotiation adds debugging complexity, but those are manageable tradeoffs for the interoperability you get.
GRE is a transport primitive, not a standalone solution. You use it to carry multicast and routing protocol traffic through a network that wouldn't otherwise support it, almost always layered with IPSec for encryption. On its own, GRE is plaintext and unauthenticated. Never deploy bare GRE across untrusted network segments — this is one of those rules with no exceptions.
DMVPN is the right tool for large-scale WAN with many remote sites where you need routing protocol support, spoke-to-spoke communication, and operational simplicity. It's Cisco-heavy in practice, though the underlying protocols are standards-based. It's a poor fit for small deployments where the NHRP complexity and three-phase model outweigh the scaling benefits. If you have five sites, just build a static GRE over IPSec mesh.
SSL VPN is your remote-access solution. It's not the right choice for permanent site-to-site connectivity at scale — TLS overhead and the application-layer nature of the tunnel make it unsuitable for high-throughput site links. But for end users connecting from laptops on arbitrary networks, it's the pragmatic choice that will cause you the fewest support calls at 2am.
Real-World Deployment Patterns
In my experience, most enterprise environments use at least two of these technologies simultaneously and often three. A typical pattern: DMVPN Phase 3 for WAN connectivity between a main data center and 30-plus branch offices, with OSPF running over the tunnels for dynamic routing. Then a separate SSL VPN cluster for remote workers. Cloud connectivity to AWS or Azure uses IPSec site-to-site VPN to the cloud provider's virtual private gateway, because that's what the cloud side speaks natively and the configuration is well-documented.
Where things get interesting is when these technologies interact with redundancy requirements. DMVPN spokes often have a secondary ISP link for failover. Dual-hub DMVPN with EIGRP and proper metric manipulation lets you do active-active or active-passive WAN with automatic failover — but you need to understand how NHRP registration behaves when the primary hub goes down and all spokes simultaneously attempt to re-register to the secondary. Test this in a lab before deploying it to 80 branch offices. The secondary hub's NHRP table getting hammered during a failover event is a real scenario.
I've also seen bare GRE tunnels used for inter-data-center IPv6-over-IPv4 transport in environments where the SP transit was IPv4-only but internal services needed end-to-end IPv6 reachability. Not glamorous, but it works and it's operationally simple to troubleshoot.
Common Misconceptions
"IPSec is always the most secure option." IPSec with AES-256-GCM and IKEv2 is excellent, but security comes from configuration, not the protocol name. A misconfigured IPSec tunnel using 3DES with MD5 HMAC and a weak pre-shared key is significantly less secure than a properly configured SSL VPN with certificate authentication, MFA, and TLS 1.3. The protocol framework matters less than how you implement it.
"GRE tunnels are encrypted." They are not. This one causes real incidents. Engineers see a tunnel interface in the configuration and assume encryption is happening somewhere. GRE is a transport encapsulation with no cryptographic properties whatsoever — the payload is plaintext, the endpoints are unverified, and any observer on the path can read everything inside the tunnel. If your GRE tunnel traverses any untrusted network segment, wrap it in IPSec. Without exception.
"DMVPN replaces MPLS." Not really. DMVPN runs over the public internet, which means you inherit the internet's jitter, packet loss variability, and lack of SLA guarantees. MPLS gives you SLA-backed QoS and deterministic latency. Enterprises migrating from MPLS to DMVPN-over-internet should plan for SD-WAN-style traffic management and accept that the internet's best-effort nature changes application behavior under load. Voice and real-time video are the first casualties without proper QoS policies and jitter buffering configured end-to-end.
"SSL VPN is slow because TLS is slow." This was true in 2010 with SSL 3.0 on software-only implementations. Modern TLS 1.3 with AES-256-GCM and hardware acceleration on any recent CPU is fast. The overhead for typical enterprise workloads is negligible. The performance bottleneck in SSL VPN deployments is almost always the gateway's aggregate throughput capacity or the user's internet uplink — not TLS processing itself.
"DMVPN Phase 2 is good enough." It's not, for anything beyond a small deployment. Phase 2 breaks summarization at the hub, requiring the hub to advertise specific host or subnet routes for each spoke. At 100-plus spokes, that's a routing table that can't be summarized cleanly and creates scaling and convergence problems. Phase 3 with NHRP redirect and shortcut is the correct design. Build it right from the start — retrofitting a Phase 2 deployment to Phase 3 across a live production WAN is not a fun weekend project.