Hardening WireGuard on Ubuntu: AllowedIPs, Firewalls, DNS Leaks, and Key Rotation
Jacky Wang··4 分钟阅读·
58 阅读
The Ubuntu WireGuard setup guide can help you establish a tunnel. A successful handshake, however, proves only that two peers can exchange encrypted packets. It does not prove that access boundaries, DNS routing, or key operations are secure.
WireGuard deliberately provides a focused encrypted network interface. Addressing, routing, firewall policy, and key distribution remain responsibilities of the operating system and administrator. Many real deployment risks therefore sit around the protocol rather than inside it.
AllowedIPs affects both routing and peer authorization
Ubuntu documents two roles for AllowedIPs: it acts as a routing key for outgoing packets and as a check on the source addresses a peer may claim for incoming traffic.
Using 0.0.0.0/0 on a client attempts to send all IPv4 traffic through the tunnel. Assigning an unnecessarily broad network to a server-side peer can also grant more routing scope than intended.
Use the smallest required ranges, avoid overlaps among peers, and reserve a default route for deliberate full-tunnel deployments. After every change, inspect wg show, the system routing table, and the resources the peer can actually reach.
VPN traffic is bidirectional, so add firewall policy
Ubuntu’s security guidance warns that devices on the remote network may connect back to a VPN client unless firewall rules prevent it.
Do not automatically treat all traffic arriving on wg0 as fully trusted. Give VPN clients a dedicated subnet and use nftables or ufw to expose only the required services. A developer may need SSH, an internal Git service, and monitoring—not unrestricted access to every host.
Separate rules are usually needed for the public WireGuard UDP port, traffic terminating on the VPN gateway, and traffic forwarded through it. A tunnel that handshakes but cannot reach an internal host often has a forwarding or firewall problem rather than a cryptographic failure.
Full tunnels must address DNS and IPv6 leaks
With AllowedIPs = 0.0.0.0/0, users often expect all internet traffic to leave through the VPN. DNS queries can still go to a resolver supplied by the local network unless DNS routing is configured explicitly.
Ubuntu’s default-gateway example uses resolvectl to associate a chosen resolver and default DNS domain with the WireGuard interface. Validate the public exit IP, resolver path, and IPv6 behavior separately. An IPv4-only full tunnel can still allow IPv6 traffic to bypass the expected route.
Protect private keys and design rotation before an incident
The WireGuard Quick Start uses umask 077 before key generation so other local users cannot read the created file.
Production operations should also give every device a distinct private key, maintain a mapping from public keys to devices, revoke lost devices by removing their public keys, and support a brief overlap while a new key is validated. Review file permissions, backups, automation output, and logs to ensure private keys are not copied into unsafe locations.
An optional PreSharedKey adds another symmetric layer between peers. It also adds another secret that must be distributed and rotated securely, so adopt it because the threat model calls for it—not as an unexplained default.
Enable PersistentKeepalive only when the network requires it
A peer behind NAT or a stateful firewall may need periodic traffic to keep its mapping open. The WireGuard Quick Start describes 25 seconds as a commonly useful interval and advises leaving the feature off when it is unnecessary.
Keepalive is not a health check. It does not repair wrong keys, routes, or firewall rules, and enabling it everywhere can add traffic while hiding the actual fault.
Post-deployment checklist
After adding a peer or changing a subnet, verify:
recent handshakes and bidirectional byte counters in wg show;
expected addresses and routes in ip addr and ip route;
minimal, non-overlapping AllowedIPs ranges;
firewall rejection of unauthorized ports;
persistent IP forwarding when the gateway must route traffic;
public IP, DNS, and IPv6 behavior for a full tunnel;
unique client keys and restrictive file permissions;
recovery of wg-quick@wg0 after service and system restarts;
logs that contain useful metadata but never private keys.
Ubuntu’s troubleshooting guidance recommends checking keys, AllowedIPs, addresses, routes, IP forwarding, and proxy ARP in a structured order. watch wg is useful for observing handshakes and counters, but it cannot replace end-to-end authorization tests.
Conclusion
WireGuard benefits from a small protocol and modern cryptography, but the effective security boundary is built from AllowedIPs, routes, firewall rules, DNS behavior, and key operations. “My phone connects” is not a production acceptance test. A hardened deployment proves that only authorized traffic passes and that lost devices, key rotation, and server restarts all have documented recovery paths.
Jacky Wang
4 分钟阅读
