Computer Networks (CCNA): Building a WireGuard Server on a VPS — A Practical Guide to VPN and Network Security

Imagine: you're in a café with public Wi-Fi, opening your server's admin panel, and suddenly realize that the traffic between your laptop and the website could be seen by anyone. Or another situation: you need to connect to your home network from another city to check cameras or grab a file. Both scenarios are solved by a VPN — but not just any VPN, a properly configured one. WireGuard today is the fastest and simplest-to-configure protocol, yet it requires an understanding of the network model. In this guide, we'll deploy our own WireGuard server on a VPS, configure clients, verify encryption with Wireshark, and examine where VPN schemes most often break.

The article is written as a practical guide: with commands, configs, and numbers. It draws on material from the course Computer Networks (CCNA), but does not retell the curriculum — here you'll find a hands-on breakdown of a task that will help you understand how a VPN works internally.

Why WireGuard, not OpenVPN or IPSec

WireGuard is a network-layer (L3) protocol running over UDP. It uses modern cryptographic primitives (ChaCha20 for encryption, Poly1305 for authentication, Curve25519 for key exchange) and is distinguished by its minimalist code. Unlike OpenVPN, which drags along OpenSSL and easily runs over TCP, WireGuard was designed from the start to be fast and secure. It cannot work over TCP, but that's more of a plus: a TCP tunnel over TCP creates the "TCP meltdown" problem, where packet loss causes avalanche-like retransmissions.

Let's compare three popular solutions by key parameters:

WireGuard wins in simplicity and speed, but you pay for it with a lack of flexibility: for example, there is no built-in support for username/password authentication (only keys), and no dynamic IP allocation (each client gets a static address in the config). For many tasks, this is sufficient.

Deploying the server on a VPS

As an example, let's take a VPS with Ubuntu 22.04, 1 GB RAM, and public IP 203.0.113.10 (here and throughout, we use addresses reserved for documentation from RFC 5737). Installing WireGuard takes minutes.

Step 1. Install packages.

sudo apt update && sudo apt install wireguard resolvconf -y

Step 2. Generate server keys.

wg genkey | tee privatekey | wg pubkey > publickey

Save the private key in a file with permissions 600. The public key will be needed for client configs.

Step 3. Create the interface.

Create the file /etc/wireguard/wg0.conf:

[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = <server private key>
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

Here 10.8.0.1/24 is the internal VPN subnet, eth0 is the server's public interface (check the name with ip a). The iptables rules enable routing and NAT for clients to access the internet through the server.

Step 4. Enable IP forwarding.

echo 'net.ipv4.ip_forward=1' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Step 5. Start.

sudo systemctl enable --now wg-quick@wg0

Check the status: sudo wg show. If the interface is up, everything is ready to add clients.

Configuring the client and routing

The client can be a laptop, phone, or another server. For each client, we generate a separate key pair — this allows revoking access selectively.

Generating client keys (on the client machine):

wg genkey | tee client_private.key | wg pubkey > client_public.key

Client config (file wg0.conf in the client's WireGuard):

[Interface]
Address = 10.8.0.2/24
PrivateKey = <client private key>
DNS = 1.1.1.1

[Peer]
PublicKey = <server public key>
Endpoint = 203.0.113.10:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

The parameter AllowedIPs = 0.0.0.0/0 means that all client traffic goes through the VPN (full tunnel). If you only need access to the internal network, specify AllowedIPs = 10.8.0.0/24. PersistentKeepalive helps maintain the connection through NAT.

Adding a client on the server: in the wg0.conf file, add to the [Peer] section:

[Peer]
PublicKey = <client public key>
AllowedIPs = 10.8.0.2/32

Then reload the interface: sudo wg syncconf wg0 <(wg-quick strip wg0) or simply sudo systemctl restart wg-quick@wg0.

Checking the connection: on the client, run wg-quick up wg0 (or import the config into the app). After connecting, check the external IP — it should match the server's IP. The command curl ifconfig.me will show the address that the outside world sees.

Routing within the VPN: if you want clients to see each other, add the line PostUp = iptables -A FORWARD -i wg0 -o wg0 -j ACCEPT to the [Interface] section on the server. By default, WireGuard does not allow traffic between peers.

Verifying encryption with Wireshark

You can verify that traffic is actually encrypted using Wireshark. Start a capture on the interface that faces the internet (e.g., eth0 on the server or Wi-Fi on the client) and start transmitting data through the VPN.

In Wireshark, you will see packets with the WireGuard protocol (if the dissector is installed) or simply UDP with port 51820. Inside — only encrypted data. Try opening some HTTP website (not HTTPS) through the VPN — the capture will not show the URL or content. This is confirmation that encryption is working.

For comparison, disable the VPN and repeat the capture — you will see plain HTTP traffic. The difference is obvious.

Where a VPN scheme breaks: three failure scenarios

Even a properly configured VPN can stop working. Let's examine typical situations.

Scenario 1: The server's external IP changed. VPS providers sometimes change the public address upon reboot. Clients that have a hardcoded Endpoint in their config stop connecting. To notice in advance: monitor the server's IP, for example, via monitoring. Solution: use dynamic DNS (DDNS) and specify a domain name instead of an IP in the config. If it's too late — update the client configs manually.

Scenario 2: A firewall rule blocked the port. You updated iptables rules or the cloud firewall and accidentally closed UDP 51820. Symptom: wg show on the server shows no handshake. Check sudo iptables -L -n and the cloud rules. If the port is closed, open it: sudo ufw allow 51820/udp.

Scenario 3: A client key is compromised. A laptop was stolen, and an attacker could connect to the VPN. It's hard to notice in advance, but you can limit the damage if each client has its own key and unique IP. Action: remove the [Peer] section with that key from the server config and reload the interface. The client will lose access.

Scenario 4: MTU and fragmentation. WireGuard adds headers, which reduces the effective MTU. If you use TCP over the VPN and the packet size exceeds the MTU, packets are fragmented or dropped. Symptom: some websites do not open, although ping works. Solution: reduce the MTU on the client (e.g., MTU = 1420 in [Interface]) or enable MSS clamping on the server.

Learning paths: self-study vs structured

You can figure out WireGuard on your own. There are many ready-made scripts and instructions on the internet, but they often do not explain why the parameters are exactly as they are. You will quickly get the VPN running, but at the first non-standard situation (IP change, port blocking, route conflict), you will have to figure it out from scratch.

Self-study path: time — from several days to weeks, costs — only for the VPS (about 200–400 rubles per month). Result: a working VPN, but without a deep understanding of the mechanisms.

Courses provide structure and feedback. For example, in the course Computer Networks (CCNA), they cover the OSI model, IP addressing, routing, and VPN in the context of network security. There are matching and fill-in-the-blank tasks that are checked automatically, and open-ended answers can be discussed in an AI chat. This helps not just repeat commands but understand the logic.

Practice on real equipment or in a simulator (GNS3, Cisco Packet Tracer) is a third path. It is the most effective for reinforcement but requires time and discipline.

Who this path suits and who it doesn't

This guide and course will be useful for those who want to understand how networks work internally: system administrators, developers, security specialists. If you are ready to deal with configs and read logs, you will quickly master WireGuard.

You shouldn't start if you just need a "VPN to bypass blocks" without wanting to understand the technology — ready-made apps will solve the task faster. Also, the course is not suitable for those looking only for a certificate: the asibiont.com platform does not issue certificates; the emphasis is on practical skills.

In conclusion, I want to emphasize: a VPN is not magic, but a combination of encryption, routing, and trust in the server. By building WireGuard with your own hands, you will see how these parts connect. The course Computer Networks (CCNA) helps you go through this path systematically, with error analysis and feedback. You can start at asibiont.com.