SSH, database panels, Grafana and every other admin interface do not belong on the public internet, even behind a password and 2FA. A WireGuard VPN moves them onto a private network that only people with a key can reach, and to the internet the server looks closed.
Every service exposed to the internet is a service that may have a vulnerability tomorrow: a database admin panel, a Grafana interface, a Docker API. Even key-only SSH stays exposed to a bug in sshd. With WireGuard, the only thing visible from outside is a UDP port that does not answer packets without a valid key. All administrative services listen on the private address inside the tunnel.
WireGuard has no accounts or passwords; identity is the public key. So each person gets their own key pair, generated on their own laptop, and their own address inside the tunnel network. On the server, AllowedIPs for each peer is that one /32 address and nothing else, so a peer cannot claim someone else's address. On the client, AllowedIPs lists only the internal networks, and PersistentKeepalive = 25 keeps the tunnel open through NAT. Keep the server configuration in Git so a revocation is a commit.
GDPR Article 32 requires access control on systems that process personal data, and after an incident ANSPDCP asks who could reach the server and how. For entities under OUG 155/2024, the NIS2 transposition approved by Law 124/2025, Article 13 explicitly calls for access-control policies (point f) and multi-factor authentication (point j), and withdrawing rights when an employee leaves is part of access management. The ordinance does not require a VPN as such, but one key per person is a common way to show both: the server's configuration file is the list of who has access.
| Criterion | WireGuard | OpenVPN |
|---|---|---|
| Protocol and transport | UDP, fixed modern cryptography (Noise, ChaCha20) | UDP or TCP, TLS with configurable cipher suites |
| Size and audit | Small codebase, in the Linux kernel since 5.6 | Large codebase, runs in user space |
| Identity | Static public keys, one peer per person | X.509 certificates, your own PKI |
| Revocation | Delete the peer from the configuration | CRL or certificate reissue |
| Visibility from the internet | Does not answer without a valid key | A port that answers the handshake |
| When to choose it | Administrative access, simple site-to-site links | TCP/443 through restrictive firewalls, an existing PKI |
sudo apt install -y wireguard
umask 077
wg genkey | tee server.key | wg pubkey > server.pub[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = <contents of server.key>
[Peer]
# ana, work laptop
PublicKey = <Ana's public key>
AllowedIPs = 10.8.0.2/32
[Peer]
# monitoring server
PublicKey = <the monitoring machine's public key>
AllowedIPs = 10.8.0.10/32sudo ufw allow 51820/udp
sudo ufw allow in on wg0 to any port 22 proto tcp
sudo ufw delete allow 22/tcp # only after you have tested the tunnel from a second session
sudo systemctl enable --now wg-quick@wg0
# revoke: delete the [Peer] block from wg0.conf, then
sudo wg syncconf wg0 <(sudo wg-quick strip wg0)Six contractors held SSH keys on customer servers and nobody kept the list. The company put WireGuard on a small access VPS, moved SSH on every server to the tunnel network and issued each contractor one peer. Offboarding a contractor now means deleting a four-line block.
The database admin interface was on the internet behind a password. After a scanner found it, it was bound to the WireGuard tunnel address. Staff now reach it over the VPN, and the port is no longer visible from outside.
You use an out-of-band route that does not depend on the network, such as a provider console if your plan has one, and repair the configuration. That is why you first test with SSH still open to the internet, from a second session, and close the public port only afterwards. Keep a copy of the WireGuard configuration off the server.
The WireGuard key on the laptop plus the SSH key are already two things an attacker needs. The remaining risk is a stolen laptop that is unlocked; you reduce it with disk encryption and a passphrase on the SSH key. Larger teams can add a layer on top of WireGuard for central identity and 2FA.
Yes, for one or two servers it is the simplest option. Once you have more machines, put WireGuard on a small access VPS and let every other server accept SSH only from that tunnel's network. That gives you a single place to manage peers.
A production server starts getting attacked within minutes of receiving a public IP address, however small the project is. This guide ranks the controls by impact, from SSH access to incident response, with the Romanian rules that apply along the way. Every topic has its own page with a short answer, examples and ready-to-use configuration.