WireGuard for Business: Secure Remote Access

Within a few years, WireGuard has become a widely used VPN protocol. It is part of the Linux kernel and available for all major operating systems. This article explains what makes WireGuard technically distinctive, what a configuration looks like and what you need to add to turn it into secure remote access for employees working from home.

What sets WireGuard apart

WireGuard is a VPN protocol, a method for building an encrypted connection between two devices over the internet. Compared with older solutions such as IPsec or OpenVPN, it takes a deliberately minimal approach.

Its key properties:

• Fixed, modern cryptography: WireGuard uses ChaCha20 and Poly1305 for encryption, Curve25519 for key exchange and BLAKE2s for hashing. The handshake is based on the Noise Protocol Framework.
• No cipher negotiation: unlike IPsec or TLS, peers do not negotiate algorithms. That reduces configuration mistakes and attacks that try to force weaker algorithms.
• Small code base: the code is compact compared with older VPN solutions, which makes it easier for security researchers to review.
• UDP-based: WireGuard sends all packets over UDP.
• Stays silent: WireGuard does not respond to packets that are not properly authenticated, so the service is hard to detect with a port scan.
• Roaming: if a device changes networks, for example from Wi-Fi to mobile data, the connection persists.
• Regular key rotation: new session keys are negotiated every few minutes. This provides forward secrecy: a key that leaks later does not expose traffic recorded earlier.

WireGuard has been part of the Linux kernel since version 5.6. Official clients are available for Windows, macOS, iOS and Android, among others.

The core principle: cryptokey routing

Every device in a WireGuard network, called a peer, has a key pair consisting of a private and a public key. Instead of a username and password, peers identify each other by their public keys.

The central setting is AllowedIPs. It defines which IP addresses belong to each peer. For outgoing traffic it acts like a routing table, for incoming traffic like an access control list. The WireGuard project calls this pairing of keys and allowed addresses cryptokey routing.

A simplified client configuration looks like this:

[Interface]
PrivateKey = LAPTOP_PRIVATE_KEY
Address = 10.20.0.15/32
DNS = 10.20.0.1

[Peer]
PublicKey = GATEWAY_PUBLIC_KEY
Endpoint = vpn.example.de:51820
AllowedIPs = 10.20.10.0/24
PersistentKeepalive = 25

In this example, the laptop only routes traffic for the 10.20.10.0/24 network through the tunnel. Everything else goes directly to the internet, which is called split tunnelling. The PersistentKeepalive option sends a small packet at regular intervals so the connection stays up behind NAT routers.

What WireGuard does not include

WireGuard is intentionally just a protocol for the encrypted tunnel. For business use, several building blocks are missing and need to be added:

Key management in particular is often underestimated. If a laptop is lost or an employee leaves, the corresponding key must be removed immediately. With a handful of devices that works by hand, with dozens it no longer does reliably.

From tunnel to zero trust access

On its own, WireGuard gives you a traditional VPN. If AllowedIPs opens entire company networks, every connected device has broad access. To apply the principle of least privilege, granting only the rights that are actually needed, you also need:

• Segmentation: internal services sit in separate network segments.
• Rules per group: a firewall on the gateway allows each group only the destinations and ports it needs.
• Per-device keys: every device gets its own key, never one shared by several people.
• Linked identity: issuing a key depends on a user account protected by multi-factor authentication.

That turns a fast tunnel into controlled access to individual services.

Common pitfalls in practice

Some problems come up again and again in home office setups:

• Overlapping address ranges: if an employee's home network uses the same range as the company network, such as 192.168.178.0/24, routing conflicts occur. A less common internal range avoids this.
• Name resolution: internal server names only work if the client uses an internal DNS server. Plan DNS settings from the start.
• MTU issues: the tunnel needs some room in each packet. On some mobile or DSL connections, sessions hang for no obvious reason. A slightly smaller MTU, the maximum packet size, often helps.
• Blocked UDP ports: hotels and guest networks sometimes restrict UDP. Test such environments in advance.
• Full tunnel without need: routing all internet traffic through the company increases load on the office connection. Decide deliberately which traffic must use the tunnel.

Rollout checklist

1. Define goals: which internal services should be reachable from home?
2. Define roles: who needs access to which services?
3. Plan addressing: use a dedicated address range for VPN clients that does not overlap with typical home networks.
4. Harden the gateway: keep the system updated and only open the UDP port for WireGuard.
5. Manage keys: generate keys on each device, document the assignment and define how revocation works.
6. Set firewall rules: allow each group only the destinations it needs.
7. Test: check connections from different networks, such as home Wi-Fi, mobile data and hotel Wi-Fi.
8. Plan offboarding: include key removal in your leaver process.

Managed WireGuard with Simplify Data

Simplify Data operates a zero trust network based on WireGuard for small and mid-sized companies. We take care of the gateway, key management and access rules, so your employees working from home only reach the services they need. Discover zero trust VPN

Sources

• WireGuard: project overview and concepts
• WireGuard: protocol and cryptography
• NIST SP 800-207: Zero Trust Architecture