WireGuard has become a go-to VPN tunnel for performance-conscious network engineers and site operators. Its minimal codebase and modern cryptography make it attractive, but real-world deployments often require nuanced peer configurations to meet security, routing, and operational needs. This article focuses on advanced peer configuration examples and the rationale behind them, aimed at webmasters, enterprise operators, and developers who manage production-grade WireGuard deployments.

Design Principles Before You Configure Peers

Before touching configuration files, adopt a few guiding principles. First, treat peers as both identity and routing constructs: a peer’s public key identifies an endpoint, while its AllowedIPs dictate routing decisions. Second, prefer explicit and minimal AllowedIPs to avoid accidental traffic leaks. Third, consider lifecycle management — keys rotate, IP allocations change, and endpoints move (mobile clients). Document and automate peer creation and revocation where possible.

IP Addressing Strategy

Choose an addressing scheme that scales. For small deployments, a /24 such as 10.10.10.0/24 is simple: assign 10.10.10.1 to the server and .2–.254 to peers. For medium/large deployments, use a /16 and subdivide: one /24 per site or per role (clients, gateways, IoT). Consistently map static DNS or internal hostnames to these addresses for easier firewall rules and troubleshooting.

Key Management and Rotation

Automate key generation and rotation using scripts or orchestration tools. Keep private keys only on the intended host; never embed them in SCM. When rotating keys, plan a short overlap window where both old and new public keys are accepted by the server to avoid downtime.

Advanced Peer Configuration Patterns

Below are pragmatic peer configurations you can adapt. Each example includes explanation and critical flags you should consider at deployment.

Example 1 — Road Warrior (Mobile Client) with Split Tunneling

Use-case: A mobile employee needs secure access to internal services, but should not tunnel all Internet traffic through the corporate gateway.

Client-side (wg0.conf snippet):
PrivateKey = [client-private-key]
Address = 10.10.10.42/32
DNS = 10.10.10.53

Server-side peer entry:
PublicKey = [client-public-key]
AllowedIPs = 10.10.10.42/32

Rationale: AllowedIPs restricts the VPN to only the client’s internal IP. This forces the client to only route corporate subnet destinations over the tunnel. On the client, you can configure system routing rules or policy-based routing to send specific subnets to wg0 while leaving default Internet traffic unmodified.

Example 2 — Full-Tunnel Mobile Client with Persistent Connection

Use-case: A contractor connects from untrusted networks and must route all traffic through the corporate network. PersistentKeepalive prevents NAT timeouts for clients behind symmetric NAT.

Client-side:
PrivateKey = [client-private-key]
Address = 10.10.10.43/32
DNS = 10.10.10.53

Server-side peer entry:
PublicKey = [client-public-key]
AllowedIPs = 10.10.10.43/32, 0.0.0.0/0, ::/0

Client-side additional option: PersistentKeepalive = 25

Rationale: The server’s AllowedIPs include 0.0.0.0/0 to accept routes for all IPv4 traffic; the client sets PersistentKeepalive so the NAT mapping remains active — typically every 20–30 seconds. Ensure the server performs SNAT (MASQUERADE) on outbound traffic and apply strict firewall rules to prevent the client from abusing the upstream connection.

Example 3 — Site-to-Site Mesh with Selective Routing

Use-case: Two remote offices must exchange specific subnets without establishing a full-mesh configuration for every host.

Office A WireGuard server:
Address = 10.20.0.1/24

Peer (Office B) entry on Office A:

PublicKey = [officeB-pub]
Endpoint = b.office.example.com:51820
AllowedIPs = 10.30.0.0/24

Peer (Office A) entry on Office B:

PublicKey = [officeA-pub]
Endpoint = a.office.example.com:51820
AllowedIPs = 10.20.0.0/24

Rationale: Each endpoint advertises only the remote LAN subnet, preventing either site from claiming all traffic. This makes routing deterministic and avoids overlapping subnets. In larger topologies, consider using BGP or static routes on internal routers to avoid pushing lots of AllowedIPs into WireGuard peers.

Example 4 — Multi-Endpoint Client with Endpoint Rotation

Use-case: A client (e.g., Kubernetes node) has multiple possible public endpoints (multi-homed). We want the server to accept peer connections regardless of source IP and support switching endpoints without regenerate keys.

Solution: On the server, keep a single peer entry with the client’s public key and omit Endpoint. WireGuard will accept packets from any remote IP that match the peer’s public key and AllowedIPs. To maintain connectivity stability, use PersistentKeepalive on the client and configure firewall to allow UDP 51820 packets from known regions or ranges.

Rationale: Omitting Endpoint enables roaming. However, if you set Endpoint, WireGuard will only accept packets from that address/port for the peer. For mobile clients, either omit Endpoint or automate Endpoint updates in server config via an API when the client changes IPs.

Operational Considerations and Hardening

Advanced peer config is only part of the deployment. Address these operational needs:

  • Firewall Integration: Use iptables/nftables to control forwarding between wg0 and other interfaces. Only allow intended Services and perform SNAT for full-tunnel clients.
  • MTU Tuning: WireGuard encapsulates packets; lower MTU (e.g., 1420–1380) may be required to avoid fragmentation, especially when running over mobile or VPN-over-VPN paths.
  • Routing Table Management: On Linux, prefer specific routes (via AllowedIPs) and avoid default gateways unless intentional. Use ip rule/ip route for policy routing when multiple uplinks exist.
  • DNS Leakage Prevention: Push internal DNS to clients and ensure DNS requests for internal zones go through the tunnel. For split-tunnel clients, configure DNS split-horizon.
  • Logging and Metrics: Monitor peer handshakes and data transfer. Tools like wg show and tailing system logs can surface churn; integrate with Prometheus exporters for long-term metrics.

Firewall Example: Strict Forwarding

On the server, restrict forwarding from WireGuard to internal network subnets only for authorized peers. Enforce masquerade only for full-tunnel peers. This staging reduces lateral movement risk if a client is compromised.

Peer Lifecycle: Creation, Rotation, and Revocation

Create a process to add and remove peers safely. When revoking a peer, simply remove the peer entry from the server and reload WireGuard. For graceful key rotation:

  • Create new keypair on client.
  • Add new public key as an additional peer entry on the server (if allowing duplicate AllowedIPs, use different entries or temporarily broaden AllowedIPs to include both keys’ addresses).
  • Update client to use new private key and test connectivity.
  • Remove old key entry from server after successful validation.

For large fleets, automate via a central API that updates server-side peer entries and triggers wg-quick or wg set commands to update runtime configuration without service downtime.

Troubleshooting Tips

When a peer fails to communicate, check the following systematically:

  • Key mismatch: Verify public/private key pairs and ensure server-side PublicKey matches client’s PrivateKey.
  • AllowedIPs: Ensure the IP on the client is included in the server peer’s AllowedIPs, and vice versa if routing-specific subnets.
  • Endpoint reachability: For static Endpoint setups, verify DNS resolution and UDP reachability to the configured port.
  • PersistentKeepalive: For NATed clients, ensure PersistentKeepalive is set to maintain NAT mapping.
  • MTU/dropped fragments: Observe for PMTU issues causing one-way traffic or TCP stalls; lower MTU on wg interface if necessary.

Conclusion

WireGuard’s simplicity empowers administrators to build secure, high-performance VPNs, but production deployments require careful peer configurations for routing, security, and operations. Use minimal and explicit AllowedIPs, plan IP allocation, automate key rotation, and integrate with firewalls and routing policies. The examples above—split-tunnel road warrior, full-tunnel with persistent keepalive, selective site-to-site routing, and roaming peers—cover common real-world patterns that scale from small teams to enterprise networks.

For further resources and tools to automate WireGuard peer management, visit Dedicated-IP-VPN at https://dedicated-ip-vpn.com/.