VPNs and Tunneling

Tunnels are how you get traffic through places it otherwise couldn't go: across the Internet between two offices, from a laptop at a coffee shop back to the servers, or from a homelab to a cheap VPS with a public IP. One thing worth keeping straight from the start: some tunnels encrypt, and some just wrap packets in other packets. GRE and VXLAN don't protect anything on their own.

What I use tunnels for

Remote access to private stuff
Connecting offices or data centers to each other
Stretching a routed network across an Internet connection
Linking cloud and on-prem
Running a routing protocol across a network that isn't mine
Encrypted management access

The options

Technology	Encrypted?	Good for	My take
IPsec	Yes	Site-to-site, and talking to other vendors' gear	Powerful and everywhere, but picky. Proposals, identities, NAT, and selectors all have to line up.
WireGuard	Yes	Simple routed site-to-site and remote access	My favorite for things I control. Tiny config. You still have to handle routing and key distribution yourself.
OpenVPN	Yes	Remote access with lots of client options	Mature and runs almost anywhere. Can use TCP when UDP is blocked.
GRE	No	Routed overlays, carrying multicast and routing protocols	Simple and useful. Wrap it in IPsec if you need privacy.
VXLAN	No	Big layer 2 overlays over a layer 3 network	Data-center fabric stuff. Plan your control plane and MTU.

Site-to-site vs. remote access

Site-to-site connects whole networks through gateways. The devices behind them don't run anything or even know the tunnel exists. Remote access connects one user or device, and you usually want policy based on who that person is.

Route-based vs. policy-based

Route-based: you get a tunnel interface, and normal routing decides what goes into it.
Policy-based: anything matching a source/destination list gets encrypted.

I strongly prefer route-based. It plays nicely with dynamic routing and lots of subnets, and you can troubleshoot it with normal routing tools. Policy-based is fine for a quick tunnel to some other vendor's firewall, but the selector lists get ugly fast as networks get added.

A WireGuard example

[Interface]
Address = 10.200.0.1/30
PrivateKey = <local-private-key>
ListenPort = 51820

[Peer]
PublicKey = <remote-public-key>
AllowedIPs = 10.200.0.2/32, 10.20.0.0/16
Endpoint = 198.51.100.20:51820
PersistentKeepalive = 25

The thing to understand about WireGuard is AllowedIPs. It does two jobs at once: it decides which destinations get sent to this peer, and which source addresses are accepted from it. If two peers have overlapping entries, traffic will go to the wrong one. Keep them tight.

When IPsec won't come up

I work through it in this order:

Can the two peers even reach each other?
Do the IKE version, encryption, integrity, auth, and DH group match on both sides?
Do the identities and the pre-shared key or certificates match?
Do the traffic selectors match (exactly, on some vendors)?
Is routing actually sending traffic into the tunnel?
Are NAT exemptions and firewall rules right?
Does the far side have a route back?

The logs on both ends usually tell you which phase is failing. If you only have access to one side, get someone on the phone who has the other one.

MTU: the classic tunnel problem

Every tunnel adds headers, which means less room for the actual data. The tunnel can look completely healthy (ping works, SSH works) while big transfers and certain websites just hang. That's MTU.

Set the tunnel interface MTU to something sensible.
Let ICMP "packet too big" / "fragmentation needed" through your firewalls so Path MTU Discovery works.
Clamp TCP MSS on the tunnel when you need to.
Test with big pings that have don't-fragment set:

ping -M do -s 1372 203.0.113.10
tracepath 203.0.113.10

Routing over tunnels

For one or two simple tunnels, static routes are fine. Once you've got several sites, redundant tunnels, or lots of prefixes, run a routing protocol over them. Authenticate those adjacencies and filter what you accept across the tunnel.

Watch out for NAT

A really common way to break a VPN: a NAT rule that rewrites the traffic before it gets encrypted, so it no longer matches the tunnel. Exempt private-to-private traffic from source NAT unless you're translating on purpose. And if both sites use the same address space (hello, 192.168.1.0/24), you're looking at NAT inside the tunnel or renumbering one side.

Security

Use current crypto and turn off the old stuff.
Rotate keys and certificates.
Only allow the networks and ports that need to cross the tunnel.
Log failed authentications and tunnel up/down events.
Encrypted doesn't mean trusted. The other end can still be compromised.
Patch Internet-facing VPN gateways fast. They're a favorite target.

Housekeeping

Write down the endpoints, tunnel addresses, networks on each side, and who owns them.
Monitor tunnel state, latency, loss, and traffic.
Actually test failover and key rotation.
Back up the gateway configs.
Test IPv4 and IPv6 separately.
Write down what MTU and MSS you expect.

Last Modified: October 12, 2026, 11:41 am