Separate tunneling from encryption

Tunneling wraps one packet inside another, so it can cross a network that would not route the original directly.

Encryption turns readable data into protected data that only the right keys can open.

These are two different operations, and they solve two different problems. Tunneling solves reachability: a packet addressed to 10.14.0.1 cannot cross the public Internet on its own, but a packet carrying it as payload can. Encryption solves confidentiality: whoever sees the bytes in transit learns nothing from them.

Here is what a wrapped and protected packet looks like on the wire:

outer IP header        public addresses, routable everywhere
  UDP header           port 51820
    encrypted payload  opaque to observers
      inner IP header  10.14.0.2 → 10.14.0.1
      inner data       your actual traffic

Read it from the outside in. The outer header is what Internet routers look at. The UDP header is what firewalls look at. Everything below is noise to anyone without the keys.

A tunnel can exist without encryption. GRE is an old and still common tunneling protocol. It wraps packets and moves them in the clear, so anyone on the path can read the inner packet. That can be fine inside infrastructure you already trust. It is reckless across the Internet.

Encryption can also exist without a tunnel. HTTPS encrypts your connection to one website. No new interface appears and no routes change. Exactly one TCP connection is protected, and nothing else.

A secure VPN combines both. It creates a routable outer packet and protects the inner one. You can watch the combination happen on your real interface while a WireGuard tunnel carries traffic:

sudo tcpdump -n -i eth0 udp port 51820 -c 2
# IP 192.168.1.34.51423 > 203.0.113.10.51820: UDP, length 148
# IP 203.0.113.10.51820 > 192.168.1.34.51423: UDP, length 92

What you see is ordinary UDP between two addresses. The payload is noise. That is tunneling and encryption working together, and it is all the local network will ever see.

Keeping the two ideas separate pays off when things break. Tunnel problems look like routing problems: unreachable destinations, packets taking the wrong path. Encryption problems look like identity problems: handshakes that never complete, peers that stay silent.

So when a VPN fails, I ask one question first: is this a reachability problem or a key problem? Knowing which half failed cuts the search in half before you type a single command.