VPN for Developers: CLI-First Setups for SSH, Git, Docker & Cloud
Developers are sceptical by default — and for good reason. This guide is built around what actually breaks in real workflows: SSH sessions that stall, Git pushes that hang, Docker pulls that get weird, and corporate networks that block UDP. You’ll get a workflow-based configurator, CLI commands, MTU optimisation, and latency-focused protocol comparisons.
- Best default: WireGuard (kernel-level) + kill switch + DNS leak protection.
- When networks block VPNs: use OpenVPN over TCP 443 (TLS/HTTPS camouflage).
- When “Git push hangs at 90%”: test and tune MTU before blaming the VPN.
The DevStack VPN Configurator (choose your workflow)
Pick your workflow and I’ll suggest a practical VPN stack (protocol + features) with copy/paste commands. This is opinionated on purpose: it prioritises stable SSH, predictable routing, and low-latency developer tooling.
Android app vs extension vs manual? Developers have a different “triple threat”
For developers, the real comparison is protocol + routing control + automation. The table below is the practical view: what protects your whole device, what gives the lowest latency, and what is easiest to script.
| Method | Full-device protection | Latency & handshake | Automation | Where it shines |
|---|---|---|---|---|
| WireGuard | Yes | Lowest latency; very fast handshake | Excellent (wg-quick, systemd, scripts) | SSH, Git, Docker pulls, Kubernetes access |
| OpenVPN (UDP) | Yes | Higher latency; slower handshake | Good (cli + config) | Compatibility, mature tooling, corporate networks |
| OpenVPN (TCP 443) | Yes | More overhead; can feel “sticky” | Good | Bypassing strict firewalls (TLS/HTTPS disguise) |
| IKEv2 | Yes | Fast reconnects; decent latency | Medium | Mobile-ish usage and quick roaming |
| L2TP/IPsec | Yes | Older; variable performance | Medium | Legacy environments (only if you must) |
CLI-first: no-GUI VPN management
If you live in terminals, you’ll want your VPN to behave like any other service: start, stop, status, logs. Below is a minimal cheat sheet that works across common setups.
| Task | Linux | macOS | Windows |
|---|---|---|---|
| Bring WireGuard up | sudo wg-quick up wg0 |
sudo wg-quick up wg0 (or use WireGuard app CLI) |
WireGuard app (or service), plus scripted routes |
| Bring WireGuard down | sudo wg-quick down wg0 |
sudo wg-quick down wg0 |
Disconnect in app / scheduled task |
| Check status | sudo wg or ip a |
ifconfig / netstat -rn |
Get-NetIPConfiguration (PowerShell) |
| Verify public IP | curl ifconfig.me (or curl https://api.ipify.org) |
||
| DNS sanity check | resolvectl status / dig whoami.cloudflare |
scutil --dns / dig +short whoami.cloudflare |
ipconfig /all / nslookup |
Prefer YouTube directly? Open the video.
The MTU & latency optimisation guide (fix SSH stalls and “Git push 90%”)
MTU (Maximum Transmission Unit) problems often look like “random” timeouts: SSH sessions that freeze, HTTP requests that hang, or Git pushes that stall near the end. It’s usually fragmentation in the path — and VPN adds overhead.
| Symptom | Likely cause | What to do |
|---|---|---|
| SSH freezes after connect | Path MTU too small through VPN | Lower interface MTU; test with pings (don’t guess) |
| Git push stalls near the end | Large packets dropped / retransmits | Find safe MTU; prefer WireGuard; keep TCP 443 only for bypassing blocks |
| Docker pulls are slow or inconsistent | DNS latency or TCP over TCP issues | Use UDP protocols; verify DNS resolver and cache behaviour |
| Only some sites work | Split DNS / MTU / routing conflicts | Check routes + DNS; confirm your VPN uses one resolver path |
How to find a safe MTU (step-by-step)
You can discover a working MTU by sending “do not fragment” pings and lowering the payload until it succeeds. The exact flags differ by OS, but the concept is the same: find the largest packet that survives the path.
ping -M do -s 1472 1.1.1.1. If it fails, lower -s until it passes, then add overhead margin.
A common WireGuard MTU is around 1420, but measure for your path.
Git & SSH security (and how not to lose local access)
A VPN reduces the chance of interception on hostile Wi‑Fi and makes your traffic harder to profile. The practical win for developers: fewer opportunities for man‑in‑the‑middle attempts against SSH, Git credentials, and package managers. But you still need sane routing: keep access to your local subnets and internal endpoints.
| Use case | Exclude | Why |
|---|---|---|
| Home/office LAN | 192.168.0.0/16, 10.0.0.0/8 |
Keep access to NAS, routers, printers, internal test servers |
| Kubernetes / private VPC ranges | Specific subnets used by your cloud/VPC | Avoid accidental routing of private traffic through VPN exit |
| Local Docker networks | Docker bridge ranges (varies) | Prevent weird DNS/routing conflicts while building images |
Protocol latency benchmarks (what devs actually feel)
Download speed is not your main metric. Developers feel latency: SSH responsiveness, API round trips, and Git fetch/push time. WireGuard usually wins because it is lightweight, runs efficiently, and avoids a heavy TLS handshake.
| Protocol | Typical latency impact | Handshake speed | Why it behaves that way |
|---|---|---|---|
| WireGuard (UDP) | Low | Very fast | Lean crypto, minimal overhead, efficient keepalives |
| OpenVPN (UDP) | Medium | Slower | TLS + user-space overhead, heavier control channel |
| OpenVPN (TCP 443) | Medium–High | Slower | TCP-over-TCP can amplify congestion and retries |
| IKEv2 | Low–Medium | Fast reconnect | Good roaming; solid in many stacks |
The developer’s toolkit (verify the environment)
Treat your VPN like infrastructure. Verify DNS, routes, and jitter before you assume “the VPN is slow”. These tools are lightweight and work everywhere.
- mtr — combined ping + traceroute to spot jitter and packet loss.
- dig — inspect resolvers and test DNS behaviour.
- tcpdump — confirm which interface actually carries traffic.
- curl — verify IP, headers, and routing quickly from scripts.
When corporate networks block VPNs (TLS stealth on TCP 443)
Some office Wi‑Fi setups block UDP or known VPN signatures. In those cases, OpenVPN over TCP 443 can blend into standard HTTPS traffic. It’s not the fastest option, but it’s often the most reliable way to get a tunnel when you’re behind strict filters.