DEV Community: Fatih Şennik

How to Install WireGuard VPN on Ubuntu and Configure It as a Server — Using Port 443 to Bypass ISP Throttling

Fatih Şennik — Tue, 12 May 2026 12:52:39 +0000

What is WireGuard VPN ?

WireGuard is a secure network tunnel operating at Layer 3, built directly into the Linux kernel as a virtual network interface. Its goal is straightforward: replace both IPsec and TLS-based solutions such as OpenVPN — and do it better. More secure, more performant, and significantly easier to use.

A cleaner mental model

At its core, WireGuard is built around a simple principle: a tunnel is an association between a peer's public key and a tunnel source IP. No certificates, no certificate authorities, no complex configuration hierarchies. If you've used OpenSSH, the model will feel familiar — short, static Curve25519 keys handle mutual authentication, and that's it. No central server required. it's peer-to-peer by design, though you can use a hub-and-spoke topology.

Fast handshakes, strong privacy

Session creation is handled transparently using a single round-trip key exchange based on the NoiseIK protocol — fast and invisible to the end user. The protocol provides strong perfect forward secrecy and a high degree of identity hiding, so even if keys are later compromised, past sessions stay protected.

Performance-first design

Data in transit is encrypted using ChaCha20Poly1305, a modern authenticated-encryption cipher that's fast even on hardware without dedicated AES acceleration. Packets are encapsulated in UDP, and the kernel-level implementation takes full advantage of Linux's queue and parallelism primitives. Crucially, WireGuard is designed to allocate no resources in response to incoming packets — a key factor in its resilience under load. So, it runs over UDP, which is faster than TCP-based VPNs but can be easliy blocked or throttled by some networks.

Better DoS protection

WireGuard improves on the IP-binding cookie mechanisms used in IKEv2 and DTLS by adding encryption and authentication to the cookie itself — making denial-of-service mitigation significantly more robust.

Small enough to audit

Perhaps the most striking aspect of WireGuard is its size: the entire Linux implementation fits in under 4,000 lines of code. Compare that to OpenVPN's ~100,000+ lines and the security implications become obvious. A smaller codebase means a smaller attack surface, and one that's actually feasible to audit and verify.

How to Install WireGuard VPN on Ubuntu and Configure it as a server.

1) Update packages and install WireGuard.

sudo apt update && sudo apt install -y wireguard

2) Generate server private and public key pair.

wg genkey | sudo tee /etc/wireguard/private.key

sudo chmod go= /etc/wireguard/private.key

sudo cat /etc/wireguard/private.key | wg pubkey | sudo tee /etc/wireguard/public.key

3) View the generated private & public keys — you will need them in the WireGuard config.

sudo cat /etc/wireguard/private.key

sudo cat /etc/wireguard/public.key

4) Find your actual network interface name — it will be the one associated with your server's public IP such as ens160 and eth0.

ip a

5) Create your WireGuard server configuration file. You can name the virtual network interface anything you like, such as wg0.conf or custom-name.conf. Let's name it as name0.conf.

sudo nano /etc/wireguard/name0.conf

[Interface]
PrivateKey = Copy /etc/wireguard/private.key to here
ListenPort = 443
Address = 192.168.50.1/24

## Enable IP forwarding (for routing)
## Please check your network interface name such as ens160.
## Please check that -i name0 same as your config file name.

PostUp = iptables -A FORWARD -i name0 -j ACCEPT; iptables -t nat -A POSTROUTING -o ens160 -j MASQUERADE
PostDown = iptables -D FORWARD -i name0 -j ACCEPT; iptables -t nat -D POSTROUTING -o ens160 -j MASQUERADE

## Client 1
[Peer]
PublicKey = Paste your mac client's public key here.
AllowedIPs = 192.168.50.2/32

## Client xN
[Peer]
PublicKey = Paste your widows or any client's public key here.
AllowedIPs = 192.168.50.3/32

6) Enable IP forwarding in the kernel so that server acts as a router, passing traffic between your VPN clients and the outside network.

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

sudo sysctl -p

7) Start WireGuard and enable on boot and verify the interface is up.

sudo systemctl enable wg-quick@name0 

sudo systemctl start wg-quick@name0

sudo wg show

8) If UFW is enabled, open the WireGuard port in the firewall.

ufw allow 443/udp

9) Every time you update the WireGuard configuration file, remember to restart the WireGuard service for the changes to take effect.

sudo systemctl restart wg-quick@name0

How to Install WireGuard VPN on Mac and Configure it as a client.

Install the official WireGuard app from the Mac App Store: Download

Click 'Add Empty Tunnel' in the app and paste the client config below. Make sure the client IP address (e.g. 192.168.50.2/24) matches the AllowedIPs value set for this peer in your server's /etc/wireguard/name0.conf.

[Interface]
PrivateKey = This is auto generated. Do not share it with anyone.
Address = 192.168.50.2/24
DNS = 8.8.8.8, 1.1.1.1

[Peer]
PublicKey = Copy vpn server /etc/wireguard/public.key to here
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = VPN_SERVER_IP:443
PersistentKeepalive = 5

Once the connection is established, the AllowedIPs = 0.0.0.0/0, ::/0 setting will route all IPv4 and IPv6 traffic through your VPN server, changing your Mac's public IP to your server's IP.

If you only want a private network without changing your public IP, set AllowedIPs to your VPN subnet (e.g. 192.168.50.0/24) and restart the WireGuard client.

Make sure you have added your Mac client's public key to your VPN server config at /etc/wireguard/name0.conf:

## Client 1
[Peer]
PublicKey = Paste your mac client's public key here.
AllowedIPs = 192.168.50.2/32

Then restart the VPN server:

sudo systemctl restart wg-quick@name0

That's it — enjoy your self-hosted, free, and open-source VPN!

How to Auto-Unlock LUKS2 Encrypted Disks at Boot with Clevis and Tang

Fatih Şennik — Tue, 12 May 2026 12:21:45 +0000

The Problem

Full disk encryption is great — until you reboot a headless server at 3am and realize you need to type a passphrase with no keyboard attached. Every reboot now requires manual passphrase entry. That's... not great when your server is a headless VM sitting in a datacenter rack in another city.

Enter Clevis and Tang. Together they let your server auto-unlock its LUKS2 volume at boot — but only when it can reach your Tang server on the network. No Tang server reachable? No unlock. It's elegant and your data is safe even if someone walks off with the physical server.

How Clevis talks to Tang (and why it's clever)

During boot, Clevis contacts Tang and initiates a JOSE/JWK key exchange. What makes this secure is what doesn't happen — your LUKS passphrase is never transmitted, Tang gains zero knowledge of the disk key, and the derived secret exists only in RAM long enough to unlock the volume. The wire traffic reveals nothing useful to an attacker and the Tang server never sees your LUKS passphrase; it just participates in the math.

Let's say that Tang server is unreachable, then Clevis gets no response, the key exchange fails, and the disk stays locked. You can still fall back to a manual passphrase, which is a separate LUKS keyslot you keep as a backup.

Keep a backup passphrase keyslot! Clevis adds its own keyslot but doesn't touch your existing passphrase. Keep it. Store it in your password manager. If Tang ever goes down permanently you'll need it. LUKS supports multiple keyslots for exactly this reason.

Installing Tang on your secure key server which is located in different location.

Tang runs as a simple systemd socket service. It's lightweight — It functions solely as a key exchange endpoint, requiring no database and no configuration files other than the key material it generates automatically. it automatically generates its key material in /var/db/tang/. That's it. No config needed.

apt-get update

apt install tang jose

# Enable and start
systemctl enable --now tangd.socket

# Change its port to any. Example: 9102
nano /lib/systemd/system/tangd.socket

systemctl daemon-reload

# Verify it's running
curl 127.0.0.1:9102/adv

Keep the server security hardened via a separated network segment and a secure random port. The /adv endpoint returns Tang's public key advertisement as JSON. If you can curl it, Clevis can reach it during boot. If you can't, neither can Clevis — fix your firewall first.

Installing Clevis on your luks encrypted server.

apt-get update

apt install clevis clevis-luks clevis-initramfs clevis-systemd

# Find your LUKS2 device
# Replace /dev/sda3 with your actual LUKS partition
cryptsetup luksDump /dev/sda3

# Check your manual passphrase before reboot!
cryptsetup --test-passphrase --key-slot 0 open /dev/sda3

# Bind your LUKS2 device to Tang key server
# it will ask for your existing LUKS passphrase
# Then will fetch Tang's public key and add a new keyslot for LUKS partition.
clevis luks bind -d /dev/sda3 tang '{"url":"http://your-tang-server-ip:9102"}'

When you run that bind command, Clevis contacts Tang, fetches its public key, generates a random key, encrypts it using Tang's key material, stores the encrypted blob in the LUKS2 token metadata, and registers it as a new keyslot. The actual decryption key never leaves your machine unencrypted.

Before embedding Clevis into your boot process, check your network interface name — it could be ens192, eth0, or something similar.

ip a | grep -E "^[0-9]+:"

⚠️ Important Gotcha: To avoid the "network isn't up yet" issue during boot, check how your server receives its IP address.

Clevis needs to reach Tang before the root filesystem mounts — but if your network interface isn't up yet, the whole thing silently fails and drops you to a passphrase prompt.

Open /etc/netplan/50-cloud-init.yaml and verify whether your server is configured for a static IP or DHCP.

Open initramfs

nano /etc/initramfs-tools/initramfs.conf

# and add this to end of the file if your server is configured for static ip
IP=SERVER_IP::SERVER_GATEWAY_IP:SERVER_SUBNET::NETWORK_INTERFACE_NAME:none

# if your server is configured for dhcp then
BOOT=network
DEVICE=NETWORK_INTERFACE_NAME (ens192)
IP=dhcp

# Update your boot process
sudo update-initramfs -u -k all

Wait before rebooting. Test !

# Try to unlock manually using Clevis 
clevis luks unlock -d /dev/sda3 
# Check if Tang server is reachable
curl http://your-tang-server:9102/adv

And that's all there is to it. Your disk will now decrypt and unlock automatically during boot, no manual intervention required.