WireGuard Setup on a Linux VPS: Networking Primer

WireGuard is a modern VPN that runs in the Linux kernel and delivers excellent performance with a remarkably small configuration surface. Because it is kernel-native and cryptographically minimal, most of the complexity in a WireGuard install is not actually WireGuard. It is the surrounding networking: creating a tunnel interface, assigning addresses, adding routes, and ensuring packets flow in both directions. This guide focuses on those networking fundamentals.

WireGuard Networking Model

WireGuard works by creating a virtual network interface called wg0. You assign an IP address to that interface, and any packet routed into wg0 is encrypted and sent to a specific peer over the real network. The important mental model is that WireGuard is just another way to get packets from one addressed interface to another. The difference is that the path between the two tunnel endpoints is encrypted.

There is no client-server relationship in the data plane. Every node is a peer. The distinction between a server and a client is only about who has which role in routing and port listening. A roaming peer usually acts as the initiator, while the stable VPS keeps a listening port open.

Generating Keys and Interfaces

WireGuard keys are Curve25519 pairs. Generate them with wg, then create the tunnel interface. The private key stays on the server, and you share only public keys with peers.

wg genkey | tee privatekey | wg pubkey > publickey
chmod 600 privatekey
ip link add dev wg0 type wireguard
wg set wg0 private-key ./privatekey listen-port 51820
ip link set wg0 up

The ip link add dev wg0 type wireguard command creates the virtual tunnel interface, which is exactly the same mechanism used for other tunnel types. You do not start traffic yet; you still have to configure a peer and an address.

Assigning Addresses and Adding a Peer

Every WireGuard peer needs an address on the tunnel network, typically from a private range like 10.0.0.0/24. Add the address, then specify a peer with its public key and allowed-ips.

ip addr add 10.0.0.1/24 dev wg0
wg set wg0 peer <SERVER_PUBKEY> allowed-ips 10.0.0.2/32 endpoint vps.example.com:51820

The allowed-ips field is the routing table of WireGuard. It tells the interface which source addresses are acceptable from that peer, and which destinations should be sent to that peer. Allowed-ips 10.0.0.2/32 means only traffic destined for that single address goes through this peer. Wanting to route a whole subnet to the peer? Use 0.0.0.0/0 to route everything.

A Complete Config File

The wg-quick wrapper reads a simple INI-style config and handles address assignment, route installation, and interface creation automatically. This is the most common way to manage a WireGuard install.

[Interface]
Address = 10.0.0.1/24
PrivateKey = <SERVER_PRIVATE_KEY>
ListenPort = 51820

[Peer]
PublicKey = <CLIENT_PUBKEY>
AllowedIPs = 10.0.0.2/32

Run sudo wg-quick up wg0 to bring it up, and sudo wg-quick down wg0 to tear it down. The tool runs the exact ip and wg commands behind the scenes. Inspect the result with wg show and the command sudo wg show wg0.

Routing and the Default Route Decision

The most confusing part of WireGuard is routing. By default wg-quick adds a route for the tunnel network itself. If you want the VPN to carry internet traffic for a client, you route 0.0.0.0/0 through the tunnel. If you only want specific subnets to use the VPN, you add those exact prefixes to AllowedIPs and keep the rest of the routing table unchanged.

On the server side, forwarding between the tunnel and the internet requires IP forwarding and sometimes NAT. Enable forwarding and, if the peer must reach the public internet through the server, add a NAT rule.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE

The MASQUERADE rule rewrites source addresses so that replies from the internet find their way back through the server. Without it, packets from the tunnel would reach the internet with 10.0.0.x source addresses, and reply packets would get dropped as martians.

MTU and Fragmentation

WireGuard wraps every packet in an additional UDP header and encryption layer, which adds overhead. If the underlying network has a 1500-byte MTU, the tunnel must use a lower MTU to avoid fragmentation. The standard safe value is 1420 bytes for WireGuard over IPv4 and 1380 for IPv6.

[Interface]
Address = 10.0.0.1/24
PrivateKey = <SERVER_PRIVATE_KEY>
ListenPort = 51820
MTU = 1420

If you see slow connections or dropped large packets through the tunnel, suspect MTU first. Test end-to-end with a large ping through the tunnel, and if it fails while a small ping succeeds, lower the MTU.

Firewalling the Server

The VPS must accept the WireGuard UDP port, and the tunnel interface must be allowed to forward its traffic. Update both your external and internal firewall rules.

iptables -A INPUT -p udp --dport 51820 -j ACCEPT
iptables -A FORWARD -i wg0 -j ACCEPT
iptables -A FORWARD -o wg0 -j ACCEPT
iptables -A FORWARD -i eth0 -o wg0 -m state --state ESTABLISHED,RELATED -j ACCEPT

These four rules open the UDP listener, allow traffic entering and leaving the tunnel, and allow established return traffic from the internet back into the tunnel. Combined with the NAT rule, this is a complete, working WireGuard server.

Verifying the Tunnel

Once peers connect, confirm the tunnel is exchanging data and routes are installed correctly.

wg show wg0
wg show wg0 latest-handshakes
ip route show
ping -c 3 10.0.0.2

The latest-handshakes column shows the timestamp of the last successful key exchange, which proves the peers can reach each other through the tunnel. A recent handshake plus a working ping across the tunnel address means the networking foundation is solid.

WireGuard is an excellent way to learn production network engineering. You can build a permanent WireGuard server on a Netbay VPS with a public IP at netbayhosts.in.