Setting up Wireguard VPN with a custom IP range (/24)

To configure a WireGuard VPN with a custom /24 IP range, assign a unique private subnet such as 10.8.0.0/24 to each peer in the configuration file. Set the AllowedIPs directive to this specific subnet and ensure the server's Address field matches the chosen CIDR block. This setup isolates traffic, prevents routing conflicts, and allows for precise network segmentation across all connected devices.

Understanding Subnet Allocation

When deploying a WireGuard network, selecting an appropriate IP range is critical for maintaining security and preventing address collisions. A /24 subnet provides 254 usable host addresses, which is sufficient for most small to medium-sized deployments. The most common practice is to use RFC 1918 private address spaces, such as 192.168.10.0/24 or 10.8.0.0/24. It is essential that every peer on the same WireGuard interface shares the same base subnet but has a distinct host address. For example, if the server is assigned 10.8.0.1, the first client might be 10.8.0.2, and the second 10.8.0.3. This hierarchical structure ensures that packets are routed correctly without ambiguity. Misconfiguring these ranges can lead to silent packet drops or, worse, expose internal network segments to unintended peers. Proper planning of this address space is the foundation of a stable VPN architecture.

Configuring the Server Interface

The server configuration serves as the central hub for your VPN tunnel. You must define the listening port, typically UDP port 51820, and generate a strong private key. The crucial step involves setting the Address parameter to your chosen /24 subnet. For instance, if you select 10.8.0.0/24, the server itself usually takes the first available IP, such as 10.8.0.1/24. This tells the kernel networking stack how to route incoming packets destined for the VPN clients. Additionally, enable IP forwarding on the host operating system to allow traffic to traverse between the VPN interface and the physical network interface. Without this setting, clients will only have connectivity within the VPN tunnel and cannot access external resources or local LAN services unless explicitly routed.

[Interface]
PrivateKey = server_private_key_here
Address = 10.8.0.1/24
ListenPort = 51820
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

In the example above, the PostUp and PostDown scripts handle NAT (Network Address Translation). This allows clients behind the VPN to access the internet through the server’s public IP. Replace eth0 with your actual outgoing network interface name. If you intend to segment networks strictly without internet access, you may omit the NAT rules. However, for most home and office setups, enabling masquerading is standard practice. Ensure that your firewall allows inbound UDP traffic on port 51820 from any source, as WireGuard uses a single port for all communication.

Setting Up Client Peers

Each client requires its own peer configuration block within the server’s config file. The PublicKey must match the client’s public key generated during the initial setup. Assign a unique AllowedIPs value that corresponds to the client’s specific IP within the /24 range. For example, if the client is at 10.8.0.2, set AllowedIPs = 10.8.0.2/32. Using a /32 mask ensures that only traffic specifically destined for that client is allowed through the tunnel, enhancing security by limiting the scope of permitted connections. The PersistentKeepalive option should be set to 25 on mobile clients to maintain the connection through NAT devices that might otherwise drop idle UDP sessions. On the client side, the configuration mirrors the server’s logic but in reverse. The client specifies the server’s public key and endpoint (the server’s public IP or domain). The client’s Address must match the IP assigned in the server’s AllowedIPs list. This bidirectional alignment is non-negotiable; mismatched IPs will result in connection failures where packets are sent but never accepted. You can find more details on managing multiple peers in our guide on Enabling Home Network Access with WireGuard and FRITZ!Box using DynDNS, which covers dynamic DNS integration often used alongside static IP assignments.

Troubleshooting Connectivity Issues

If clients cannot connect, verify that the AllowedIPs on the server exactly match the client’s Address. Check the server logs using wg show to see if handshake attempts are being received. Common pitfalls include incorrect firewall rules blocking UDP 51820 or disabled IP forwarding on the Linux host. If you experience intermittent disconnections, ensure that PersistentKeepalive is configured correctly on mobile devices. For advanced routing scenarios, consider reading about How to Forward a Port Outside a VPN Network to understand how to expose specific services securely through the tunnel.

Security Best Practices

Using a /24 subnet offers significant advantages over smaller subnets like /32 for individual peers, primarily because it simplifies routing tables. Instead of managing hundreds of /32 entries, you can aggregate routes if needed. However, always restrict AllowedIPs to the minimum necessary. Never use 0.0.0.0/0 unless you intend to route all internet traffic through the VPN, which can cause performance issues and break local network access. Regularly rotate keys and audit the wg show output to remove inactive peers. This hygiene prevents unauthorized access attempts and keeps the configuration clean.

Frequently Asked Questions

Can I use the same /24 subnet for multiple WireGuard servers?

No, overlapping subnets will cause routing conflicts and unpredictable behavior. Each WireGuard instance must operate on a unique, non-overlapping private IP range to ensure clear path determination for packets.

How do I change the IP range after initial setup?

You must update the Address field on the server and the AllowedIPs on all clients simultaneously. Restart the WireGuard service on all devices to apply the new configurations and re-establish handshakes.

Is a /24 subnet secure enough for production environments?

Yes, provided you restrict AllowedIPs per peer. Security relies on cryptographic authentication and strict access control lists rather than subnet size alone.

What happens if I assign two clients the same IP?

The server will accept connections from both, but traffic will be ambiguous. Packets intended for one client may be delivered to the other, leading to data corruption and connection instability.

Can I route traffic from the VPN to my local LAN?

Yes, by adding the LAN subnet to the client’s AllowedIPs and ensuring the server forwards traffic correctly. This requires careful firewall configuration to prevent unauthorized lateral movement.