DEV Community: Mišo Oroz

WireGuard VPN for Production: The Exact Setup I Deploy for Small Businesses

Mišo Oroz — Tue, 15 Sep 2026 09:11:45 +0000

WireGuard is the VPN I deploy for every small business I migrate to Linux. Not because it is trendy, but because it is the most honest piece of networking software I have worked with in fifteen years.

In 2026, WireGuard is the default VPN protocol for a reason: it is in the mainline Linux kernel since version 5.6, independently audited, and faster than OpenVPN on the same hardware. For small businesses this means no kernel modules to maintain, no CVE backlog, and no performance complaints.

The entire trust model fits in a single config file. When something breaks, you can audit it in minutes. That matters at 8am on a Monday when a client cannot connect and you need to diagnose fast.

This is not a theoretical walkthrough. This is exactly what I deploy in production.

Before you start

Server with static public IP
UDP 51820 open on server firewall
SSH access to the server
Client machine with working internet connection
A clear decision on whether all traffic routes through the tunnel or only the internal network (more on this below)
A backup access plan if the tunnel breaks (physical access, out-of-band SSH, etc.)

Why WireGuard specifically

The WireGuard codebase is roughly 4,000 lines. OpenVPN's core daemon is closer to 70,000. This is not a marketing detail. Smaller codebase means smaller attack surface, faster patching, and a security posture you can actually reason about.

WireGuard has been independently audited. The Cure53 audit in 2021 and the Trail of Bits review found no critical vulnerabilities. OpenVPN has also been audited, but its larger codebase makes comprehensive auditing more time-consuming and leaves more surface area for potential issues.

I evaluated three options before standardizing on WireGuard:

OpenVPN: mature, flexible, but complex. Requires certificate management, has a larger attack surface, and is noticeably slower on low-end hardware.

IPsec/IKEv2: fast and secure, but configuration is opaque. Debugging failures often requires deep protocol knowledge.

WireGuard: minimal, audited, fast. The trade-off is manual key management, which is acceptable for teams under 20 people.

For small businesses that cannot afford enterprise security teams, choosing audited software with a minimal codebase is one of the few concrete security decisions they can make.

What you need

A Linux server you control. In my case a VPS hosted in Italy, running Debian 12. A static IP on the server side. A client machine running Linux, in most cases Kubuntu 26.04 LTS.

I use a VPS for the relay in most deployments because it gives clients a stable public IP without managing physical hardware at the office. For businesses with an on-premise server already in place, running WireGuard directly on that machine works equally well. The config is identical.

Debian 12 is the default for server deployments: predictable release cycle, five years of security updates, no surprises. I avoid rolling releases on anything client-facing.

WireGuard uses public key cryptography. Each peer generates a key pair. You exchange public keys. No certificates, no certificate authorities, no complexity that lives outside the config file.

Server setup

Install WireGuard:

apt install wireguard

Generate the server key pair. Set permissions before the key is used:

wg genkey > /etc/wireguard/privatekey
chmod 600 /etc/wireguard/privatekey
wg pubkey < /etc/wireguard/privatekey > /etc/wireguard/publickey

Create the server configuration at /etc/wireguard/wg0.conf:

[Interface]
PrivateKey = <server_private_key>
Address = 10.0.0.1/24
ListenPort = 51820
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o <interface> -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -D FORWARD -o wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o <interface> -j MASQUERADE

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

Replace <interface> with your actual network interface name. On Debian 12 modern installs this is typically ens3, enp1s0, or similar. Check with ip link before editing the config. Almost never eth0.

Why 10.0.0.0/24? This is RFC 1918 private space, unlikely to conflict with most office networks. I use 10.0.0.1 for the server and increment client IPs from 10.0.0.2. If your office already uses 10.0.0.0/24, choose a different range such as 10.100.0.0/24 to avoid routing conflicts.

On the /32 for each peer: this tells WireGuard that this specific public key is only allowed to use the IP 10.0.0.2. Each peer must have its own /32 entry. Without it, a compromised client could potentially spoof other addresses on the tunnel.

Note on cloud providers: if you use a VPS with a cloud security group (Hetzner, DigitalOcean, AWS), open UDP 51820 in the security group rather than via iptables. The PostUp rules above handle forwarding and NAT, not port access itself.

If your server has IPv6 enabled, which is common on modern VPS, add ip6tables rules as well:

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o <interface> -j MASQUERADE; ip6tables -A FORWARD -i wg0 -j ACCEPT; ip6tables -A FORWARD -o wg0 -j ACCEPT; ip6tables -t nat -A POSTROUTING -o <interface> -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -D FORWARD -o wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o <interface> -j MASQUERADE; ip6tables -D FORWARD -i wg0 -j ACCEPT; ip6tables -D FORWARD -o wg0 -j ACCEPT; ip6tables -t nat -D POSTROUTING -o <interface> -j MASQUERADE

Enable IP forwarding:

echo 'net.ipv4.ip_forward = 1' >> /etc/sysctl.conf
sysctl -p

Enable and start:

systemctl enable --now wg-quick@wg0

Client setup

Install WireGuard and openresolv:

apt install wireguard openresolv

Generate client key pair:

wg genkey > /etc/wireguard/privatekey
chmod 600 /etc/wireguard/privatekey
wg pubkey < /etc/wireguard/privatekey > /etc/wireguard/publickey

Create /etc/wireguard/wg0.conf on the client:

[Interface]
PrivateKey = <client_private_key>
Address = 10.0.0.2/32
DNS = 1.1.1.1

[Peer]
PublicKey = <server_public_key>
Endpoint = <server_public_ip>:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

Why /32 on the client? The client is a single host, not a subnet. Using /32 is semantically correct and avoids confusion when adding more clients later. The /24 on the server interface is correct because it represents the entire tunnel network.

0.0.0.0/0, ::/0 routes all traffic through the VPN, including IPv6. If you only need access to the internal network without routing everything, use the specific subnet instead, for example 10.0.0.0/24. Understand what you are routing before you route it.

PersistentKeepalive = 25 sends a keepalive every 25 seconds. Required when the client is behind NAT, which is almost always the case for small business remote workers. Without it the NAT mapping expires and the tunnel silently drops.

Enable and start:

systemctl enable --now wg-quick@wg0

Verify the tunnel:

wg show
ping 10.0.0.1

wg show confirms the handshake happened. ping 10.0.0.1 confirms the tunnel carries traffic. Both should work before you call it done.

DNS on Kubuntu 26.04 with systemd-resolved

Kubuntu 26.04 uses systemd-resolved by default. The DNS = directive in wg0.conf works correctly with systemd-resolved, but you must ensure /etc/resolv.conf points to the stub resolver:

ls -l /etc/resolv.conf

Expected output:

/etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

If it points elsewhere, fix it:

sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

Bring up the tunnel and verify DNS is routing correctly:

resolvectl status wg0

You should see your configured DNS listed under the wg0 interface.

Verify no DNS leaks

A DNS leak means your DNS queries are going outside the tunnel, exposing which domains you visit even if the traffic itself is encrypted. After bringing up the tunnel, verify:

dig +short myip.opendns.com @resolver1.opendns.com

This should return your VPN server's public IP, not your client's real IP. If it returns your real IP, DNS is leaking.

Also check for IPv6 leaks:

curl -6 ifconfig.co

If this returns an IP, IPv6 traffic is not going through the tunnel. Either disable IPv6 on the client or ensure ::/0 is in AllowedIPs and add an IPv6 DNS server: DNS = 1.1.1.1, 2606:4700:4700::1111.

Key management

WireGuard has no built-in key rotation. When an employee leaves or a device is compromised, you must manually remove the [Peer] block from the server config and redistribute new keys.

My workflow for small businesses: I keep a simple spreadsheet with peer name (for example "alice-laptop"), public key copied from /etc/wireguard/publickey, device owner, creation date, and last rotation date. Rotate keys every 12 to 18 months as standard practice. If a device is lost, revoke immediately: remove the [Peer] block, restart WireGuard, and generate new keys for the affected client.

This manual process is a trade-off: you gain simplicity and auditability, but lose automated lifecycle management. For teams under 20 people it is acceptable. Beyond that, consider a WireGuard management layer like Netmaker or Headscale.

Monitoring and troubleshooting

Check handshake age — should be under two minutes on an active connection:

wg show | grep "latest handshake"

Watch live traffic through the tunnel:

watch -n1 'wg show | grep transfer'

For proactive monitoring I use a simple cron job that pings the tunnel IP every 5 minutes and logs failures:

*/5 * * * * ping -c1 10.0.0.1 || logger "WireGuard tunnel down"

If the tunnel drops:

Check logs: journalctl -u wg-quick@wg0
Verify the port is reachable: nc -vzu <server_ip> 51820
Confirm PersistentKeepalive = 25 is set on the client
Restart the tunnel: systemctl restart wg-quick@wg0

Appendix: Kubuntu 26.04 and Wayland

Kubuntu 26.04 uses Wayland by default. This does not affect WireGuard itself, but it breaks X11-based remote desktop tools. For full remote access setups I pair WireGuard with a self-hosted RustDesk relay, which handles Wayland correctly. On Kubuntu 24.04, which still uses X11, standard remote desktop tools work without this additional step. RustDesk with a self-hosted relay is outside the scope of this guide but worth knowing before you commit to a 26.04 deployment for remote workers.

Final notes

I have been running this setup across multiple client deployments since early 2026. No security incidents, no unexplained drops. WireGuard's simplicity is its strength: when something breaks, you can read the entire config and understand it in minutes.

For small businesses migrating to Linux, this is the VPN layer I standardize on. And if a client or an auditor ever asks why I chose it, I can explain every line of the config. That is not something I could say about most alternatives.

zerolock.it

Nextcloud vs Google Drive: a practical comparison for small business migrations

Mišo Oroz — Sun, 06 Sep 2026 14:20:24 +0000

I've been migrating small businesses in northern Italy from Google Workspace and Microsoft 365 to open source stacks for a while now. One of the first questions I always get is: "What about file storage? We use Google Drive for everything."

Fair question. Let me give you an honest answer, not a sales pitch.

What we're actually comparing

When I say Google Drive in a business context, I mean the full Google Workspace package: Drive, Docs, Sheets, Gmail, Meet. It's a coherent platform that works well. I'm not going to pretend otherwise.

Nextcloud is a self-hosted (or managed-hosted) file sync and collaboration platform. Out of the box it handles file storage, sharing, and sync across devices. With apps you can add calendar, contacts, talk (video calls), and collaborative document editing via Nextcloud Office (built on Collabora).

So the comparison isn't just "where do files live." It's about how your client's business actually runs day to day.

The real differences that matter

Data location and sovereignty

With Google Drive, your files live on Google's infrastructure. Full stop. For most small businesses this isn't a problem until it is: GDPR compliance questions, a client contract that requires data to stay in Italy, or a sector with specific regulations (legal, medical, financial).

With Nextcloud you choose where data lives. I typically set up clients on Italian or Swiss-based infrastructure, choosing providers that keep data within EU jurisdiction. The client owns the data, period.

This matters more than people realize. I've had clients lose access to their Google Workspace because of billing issues during a holiday weekend. With self-hosted infrastructure, you control the keys.

Cost structure

Google Workspace Business Starter runs around 6.80 euros per user per month at the time of writing (check current pricing on their site as this changes). For a team of 8 that's around 653 euros per year, just for the base tier. Storage limits apply at 30 GB pooled per user, and many teams end up on a higher plan within a year.

Nextcloud itself is open source and free. You pay for hosting. A decent VPS with enough storage for a small team costs 15 to 30 euros per month, depending on specs and provider. For 8 users that's 180 to 360 euros per year, with no per-user licensing.

The math is straightforward. The savings compound over time.

Feature parity

This is where people get nervous. Let me be direct: Nextcloud is not Google Drive. Some things work differently, some things work better, some things are more manual.

File sync across devices works well. The desktop clients for Linux, Windows, and macOS are stable. Mobile apps exist for Android and iOS.

Collaborative editing works if you install Nextcloud Office. It's not as smooth as Google Docs in my experience, but it's functional for most business use cases. If your team lives inside documents all day, evaluate this carefully before committing.

Search is decent but not Google-level. For a team that stores lots of documents and searches constantly, this is worth testing with real data before the migration.

Sharing links, permissions, versioning: all there and well implemented.

Administration overhead

This is the honest part. Google Workspace has zero admin overhead for the IT person. You click, it works, Google handles updates, security patches, and uptime.

Nextcloud requires someone to handle updates, monitor the instance, and occasionally deal with issues. If that someone is you (the IT consultant), you need to factor this into your service contract. If it's supposed to be the client on their own, think carefully.

For the clients I manage this is part of the monthly support I provide. It's not heavy lifting, but it's not zero either.

When I recommend Nextcloud

I push for Nextcloud when the client has 2 to 20 users with straightforward storage and sharing needs and no heavy real-time collaboration on complex documents.

There's a compliance or sovereignty angle that matters. Legal practices, small financial advisors, healthcare adjacent businesses. Anything where "your data is on Google's servers" is a problem worth solving.

The client wants predictable costs with no per-user licensing that grows as they hire.

They're already moving to a Linux-based workstation setup, so the open source philosophy is consistent across the stack.

When I don't

If the client's workflow is deeply integrated into Google Workspace, a migration is painful and the value is lower. At Zerolock we've walked away from a couple of these rather than force a migration that would hurt the client more than help them. Heavy Docs and Sheets collaboration, Gmail filtering built into daily operations, Google Meet for all external calls: these are signals to evaluate carefully before committing to a switch.

Same with shops that use Teams heavily for video and internal communication. The Nextcloud Talk feature is improving but it's not Teams, and if video collaboration is critical, that matters.

The migration process in practice

For a typical 5 to 8 person team, here's roughly how it goes.

Set up the Nextcloud instance. I use Docker on a VPS, behind a reverse proxy, with automated backups to a separate location.

Migrate existing files from Google Drive using rclone. It handles the OAuth flow cleanly and can do incremental syncs during the transition period.

Install and configure desktop clients on each workstation. On Linux (Kubuntu in my case) this is straightforward via the official package.

Train the team. Usually half a day. Most people adapt quickly because the core experience, folder, file, share, is familiar.

Run parallel for two to four weeks. Both systems active, with the team gradually moving their work to Nextcloud. Then cut over.

The hardest part is usually email. If they're leaving Gmail too, that's a separate migration with Thunderbird or a webmail setup. But that's a different article.

One thing I'd add

I've found that clients are more comfortable with Nextcloud than they expect, mostly because it looks and behaves like a normal file system. The "everything is a proprietary document format" model confuses some users who just want to store a PDF and find it later. Nextcloud handles that interaction more naturally.

It's not the right tool for every situation. But for a lot of small businesses that don't need the full cloud suite and do care about where their data lives, it's a solid, honest choice.

If you're doing similar migrations and have questions about the setup, happy to compare notes.

zerolock.it

How we migrated an Italian logistics company from Windows to Linux: a real case study

Mišo Oroz — Wed, 02 Sep 2026 14:34:47 +0000

In early 2026 I migrated a logistics and transport company in Bergamo, Italy from a fully proprietary setup to Linux and open source. Five workstations, five employees, zero technical background on their side. Here is what we did, what happened, and what I learned.

The starting point

The company was running Windows on every workstation, Microsoft Office for documents, a third-party antivirus renewed annually, and an external IT technician called in every time something broke. They had no internal IT knowledge and no interest in acquiring any. They just wanted things to work.

Their main pain points were slow machines, frequent crashes after Windows updates, and a recurring bill that kept growing without any visible improvement.

What we installed

I replaced everything with a fully open source stack:

Kubuntu as the operating system on all five workstations
LibreOffice in place of Microsoft Office
Thunderbird for email
Nextcloud for file sharing and internal document management, self-hosted on a server in Italy
Mattermost for internal team communication
pfSense as the network firewall
WireGuard for VPN access
Automated encrypted backups running nightly

Total recurring licence cost after migration: zero.

The migration process

The full migration took approximately one week. I configured everything on a test machine first, validated all workflows with the team, then rolled out workstation by workstation during off-hours to avoid interruptions.

The biggest challenge was not technical. It was psychological. People are used to what they know. I spent as much time sitting with each employee and showing them that LibreOffice opens their Word files and Nextcloud works like Google Drive as I did on the actual technical setup.

After three days they stopped asking about Windows.

Results after six months

Six months in, the company has not called me for a single ordinary technical issue. The machines are faster. Updates do not break anything. There have been zero security incidents.

The most concrete result: each employee recovered roughly one hour per day that was previously lost to slowdowns, crashes and waiting for the external technician. On five people that is five hours a day returned to productive work.

Licence costs are gone. The infrastructure belongs to them, not to a vendor.

Why this matters beyond one company

Most Italian SMEs are in the same situation. They pay recurring fees for software they do not own, store data on foreign servers subject to the US Cloud Act, and depend on vendors who can change the rules at any time.

Linux and open source infrastructure is not experimental. It is mature, stable, and ready for business use. The barrier is not technical. It is awareness.

I wrote the Zerolock Manifesto (https://zerolock.org) on exactly this topic. If you are working on similar migrations or have questions about the stack, I am happy to discuss in the comments.