Concepts first, commands second: written 2026-08-29 because the commands made no sense without the model behind them. Firewall mechanics live in ufw-firewall; SSH (ssh-keys-and-github) is also an encrypted tunnel, same principles.
The big picture
- Without a VPN, the internet is postcards: every hop (ISP, café router) can read the message and the address.
- A VPN is a sealed envelope to a trusted friend, who posts the postcard onward with their return address and sends the reply back sealed.
- Only the server needs an open port. Your PC always dials out; replies get in because the firewall remembers you asked.
1. The core idea: a sealed envelope
| What an observer learns | Without VPN | With VPN |
|---|---|---|
| That you’re sending something | yes | yes |
| What you sent | readable | encrypted |
| Who you ultimately sent it to | visible | hidden |
| Who you appear to be at the far end | you | the VPN server |
2. Encapsulation: what’s in the envelope
Your real packet encrypted entirely, then wrapped
To: github.com:443 To: vpn-server.example:51820 <- all your ISP
From: 192.168.1.42 ──▶ From: 203.0.113.99 ever sees
Data: "GET /Cygnus0923/notes" Data: ▓▓▓ encrypted blob ▓▓▓ (your whole packet)- The VPN doesn’t replace your packet → it encrypts the whole thing and carries it as the cargo of a new packet.
- Hence tunnel: the real packet travels through the outer one, unreadable, and comes out the other end intact.
3. TCP vs UDP
| TCP | UDP | |
|---|---|---|
| Analogy | registered mail: call ahead, signed for, lost items re-sent | postcards in a mailbox: no call, no signature, no re-sending |
| Connection | established first (the “handshake”) | none, packets fly independently |
| Reliability | guaranteed, in order | no guarantee, no ordering |
| Speed | slower: acknowledgements and retries | faster: minimal overhead |
| Used by | web, email, SSH, git | VPNs, video calls, DNS, gaming |
Why VPNs choose UDP: "TCP meltdown"
Inside the tunnel is mostly TCP. A TCP tunnel stacks two independent retransmission systems: on a lost packet both re-send and back off on their own timers, fighting each other, and throughput collapses instead of degrading gracefully.
- So the tunnel uses UDP (deliberately dumb and fast) and lets the inner TCP do the reliability work. One retransmission system, not two.
- WireGuard → UDP-only, no TCP mode, by design.
- OpenVPN → both, defaults to and recommends UDP. TCP mode only escapes restrictive firewalls that allow nothing but TCP/443.
4. Client vs server: why only one needs an open port
A server is a shop, a client is a customer. A shop needs a public address and an unlocked door, because customers arrive unannounced. A customer walks to the shop and back; nobody knocks on their door.
| VPN server | VPN client | |
|---|---|---|
| Inbound port open? | yes, fixed, e.g. 51820/udp | no, none needed |
| Port it uses | fixed and published | random high port per session (ephemeral) |
| Who starts the conversation | waits | always initiates |
- Your PC is the client → a
51820/udp ALLOWrule on it is an unlocked door nobody needs. Closing it removes attack surface for zero loss of function: see ufw-firewall.
5. “If my door is closed, how do replies get back in?”
The doorman with a memory: a stateful firewall.
PC :54321 ──▶ server:51820 firewall notes: "expect a reply from server:51820 to :54321"
server ──▶ PC :54321 matches the note -> let in, delivered
(~30s–2min of silence) note expires
stranger ──▶ PC no matching note -> DROPPED- Replies to conversations you started are allowed; conversations others start are blocked. That’s why
deny incoming / allow outgoingis safe and doesn’t break the internet.
[Peer]
PersistentKeepalive = 25- Why
PersistentKeepaliveexists: once the note expires (typically 30 seconds to 2 minutes), the server can’t reach you until you speak first. Fine for browsing, but breaks a VPN where the server pushes data unprompted. - This WireGuard client line sends a tiny packet every 25 seconds, just enough to keep the note fresh.
6. What a VPN does NOT do
It’s widely oversold:
- Not anonymity → you’ve moved trust, not removed it. Your VPN provider now sees exactly what your ISP used to. Choose accordingly.
- No extra encryption for HTTPS sites → already encrypted. A VPN hides which site from your ISP, not the contents from the site.
- Doesn’t hide you from a site you log into → signing in identifies you regardless of address.
- A company VPN is usually about access, not privacy → reaching internal servers, machines or robots not exposed to the public internet. Privacy is a side effect.
| Full tunnel | Split tunnel | |
|---|---|---|
| Through the VPN | all traffic | only traffic for specific subnets |
| Everything else | via VPN | direct to the internet |
| Typical use | privacy, untrusted wifi | company VPN, internal ranges only |
- Split tunnel is why a work VPN can be connected without slowing down YouTube.
7. This machine (checked 2026-08-29)
command -v wg wg-quick # WireGuard: NOT installed
dpkg -l | grep -i openvpn # openvpn 2.5.11 + network-manager-openvpn: INSTALLED
ip -brief link | grep -E 'wg|tun' # no tunnel interfaces up
ss -lun | grep 51820 # nothing listening- Set up for OpenVPN via NetworkManager, not WireGuard, and runs no VPN server of any kind → it’s a client.
Quick reference
command -v wg wg-quick openvpn nmcli # which VPN tooling exists
dpkg -l | grep -iE 'wireguard|openvpn' # ...installed packages
ip -brief link show # tunnel up? look for wg0 / tun0
ip route | grep -E 'wg|tun' # is traffic routed through it?
nmcli connection show # all connections, VPN included
nmcli connection up <vpn-name> # OpenVPN via NetworkManager
nmcli connection down <vpn-name>
sudo wg show # WireGuard: peers, handshake times, transfer counts
sudo wg-quick up wg0
sudo wg-quick down wg0
curl -s https://ifconfig.me # public IP: the VPN server's if the tunnel is upcurl ifconfig.mebefore and after connecting is the fastest proof a full tunnel works: the address should change to the VPN server’s.