Why OpenVPN, and the lab
Install and run an OpenVPN server on Debian with your own certificate authority: one certificate per user, fixed addresses, routing to an office and a branch LAN, split and full tunnels, tls-crypt, revoking users, and the mistakes that lock everyone out.
By the end you will be able to:
- Build a certificate authority with easy-rsa and issue a certificate per user
- Configure and run an OpenVPN server as a systemd service on Debian, with forwarding and an nftables firewall
- Route VPN users to an office LAN and a branch LAN, including return routes and iroute
- Choose between split and full tunnels per user, and between client-to-client and firewall rules
- Revoke a user safely, and recognise the log messages for the common failures
Prerequisites: Linux Network Connectivity
OpenVPN is the classic way to give remote users, and whole branch offices, secure access to a private network from anywhere on the internet, and a Debian server is all it needs. This lesson builds one properly: its own certificate authority (CA), one certificate per user, routing to an office LAN and a branch LAN, and the jobs that come later, like revoking a user who leaves.
OpenVPN carries your traffic inside a Transport Layer Security (TLS) protected connection, usually over UDP port 1194. Each side proves who it is with a certificate. On the server, each connected user appears as an address on a virtual TUN interface (tun0), and from there it's ordinary Linux routing.
OpenVPN or WireGuard?
The WireGuard lesson builds a site-to-site tunnel with far less configuration, and for that job WireGuard is usually the better choice: it's simpler, and faster. OpenVPN earns its extra moving parts when you're managing people:
- A certificate per user, from a CA you control. Adding a user means signing a certificate; removing one means revoking it, and every server checks the revocation list.
- Per-user configuration on the server. A fixed address, a full tunnel for one user and a split tunnel for another, a LAN behind a particular user: one small file per user.
- It fits awkward networks. It can run over TCP port 443 when UDP is blocked, and clients exist for every desktop and phone platform.
The lab
Everything here runs on Debian 13 in Docker, and every output is copied from that run. The VPN server sits between the internet (203.0.113.10) and an office LAN (10.10.0.0/24), where the office's own router, lanrtr, is everyone's default gateway, as in most real offices. Three users connect from the internet: alice and bob are laptops, and branch is a branch-office router with its own LAN (10.20.0.0/24) behind it. A web server on the internet logs the address of everyone who visits, which is how the split- and full-tunnel tests are measured.
- Users connect over the internet. alice, bob and the branch router reach the VPN server's public address, 203.0.113.10, on UDP port 1194.
- Into the office. Inside the tunnel, alice (10.8.0.10) reaches the office host through the VPN server's office interface.
- …and the way back. The office host replies to its default gateway, lanrtr, not the VPN server. lanrtr needs a return route for 10.8.0.0/24, or the reply dies there.
- A LAN behind a user. The branch router is a VPN user with a whole network behind it. route (server's kernel) and iroute (inside OpenVPN) send 10.20.0.0/24 to it.
- Full tunnel for one user. alice's internet traffic goes through the tunnel and leaves from the VPN server, NATed to 203.0.113.10. bob's still goes direct.