To route all internet traffic through a Wireguard peer, you must configure the client's
AllowedIPs to include
0.0.0.0/0 and
::/0, then set up a persistent default gateway or use policy-based routing to ensure the kernel directs all outbound packets into the tunnel interface. This effectively creates a "kill switch" scenario where any traffic not destined for the local network is forced through the encrypted VPN pipe, enhancing privacy by preventing DNS leaks or direct IP exposure.
Understanding the Configuration Logic
Wireguard operates differently from traditional VPN clients like OpenVPN because it does not automatically manage system routing tables. By default, Wireguard only routes traffic that matches the specific subnets defined in the
AllowedIPs field. To force all internet traffic through the tunnel, you need to tell the operating system that the entire IPv4 and IPv6 address space is reachable via the Wireguard interface. This requires modifying the peer configuration on the client side and ensuring the server side is prepared to handle this load.
The core mechanism relies on the principle of longest prefix match in routing tables. When you add
0.0.0.0/0 to the client's allowed IPs, you are creating a catch-all rule. However, simply adding this to the Wireguard config file is not enough; the system needs to know how to reach the Wireguard endpoint itself before it can send traffic through it. If your default gateway points to your physical router (e.g.,
192.168.1.1) and your Wireguard config tries to route everything through the tunnel, you will create a routing loop unless you carefully manage the precedence of routes.
For more granular control over specific applications, you might prefer binding them to the interface rather than redirecting all traffic. See
Configuring WireGuard VPN Routes for Network Application on Binded Network Interface if you want to isolate specific services instead of global redirection.
Step-by-Step Client Configuration
The first step is to edit your Wireguard client configuration file, typically located at
/etc/wireguard/wg0.conf. You need to locate the
[Peer] section corresponding to your VPN server. Inside this section, find the
AllowedIPs directive. By default, it might look like
AllowedIPs = 10.8.0.0/24. You must change this to include both IPv4 and IPv6 default routes:
[Peer]
PublicKey = ...
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25
Setting
AllowedIPs to
0.0.0.0/0 tells the Wireguard module to encapsulate all IPv4 traffic. Adding
::/0 ensures IPv6 traffic is also routed through the tunnel, which is critical because many systems have IPv6 enabled but may not properly leak traffic if ignored. The
PersistentKeepalive setting helps maintain the connection through NAT devices, ensuring the tunnel stays active even when no data is flowing.
After saving the file, restart the Wireguard service using
sudo systemctl restart wg-quick@wg0. At this point, the kernel routing table has been updated. However, there is a critical caveat: if your system's default gateway remains pointing to your local router, the initial handshake packets required to establish the Wireguard tunnel itself might be sent outside the tunnel, potentially exposing your real IP address during the connection setup phase.
Managing Default Gateways and Routing Tables
To ensure true anonymity, you should verify that the Wireguard interface has become the primary path for internet traffic. You can check this by running
ip route show default. If the output shows two default routes, one via your physical interface (e.g.,
dev eth0) and one via the Wireguard interface (e.g.,
dev wg0), Linux will prioritize the one with the lower metric. Usually, Wireguard adds a route with a higher metric, meaning it acts as a backup rather than a primary path.
If you want to guarantee that all traffic goes through the VPN, you may need to adjust the metric or remove the old default gateway temporarily. A safer approach for most users is to rely on the fact that once the tunnel is established, subsequent traffic will follow the new rules. However, for sensitive environments, consider using policy-based routing. This involves creating a separate routing table (e.g., table 100) and defining rules that send all traffic from the Wireguard source IP to that table.
It is important to note that forcing all traffic through a VPN can break local network access if not configured correctly. For example, accessing your local printer or NAS might fail if those addresses are not excluded. You can exclude local subnets by appending them to the
AllowedIPs list, separated by commas:
AllowedIPs = 192.168.1.0/24, 0.0.0.0/0. This ensures that local LAN traffic bypasses the tunnel while all other internet traffic is secured.
If you are configuring a server that should not use the VPN as its default gateway, refer to
How to Make a Server Not Use VPN as a Default Gateway to avoid common pitfalls in asymmetric routing scenarios.
Verifying the Setup and Leak Testing
Once configured, verify the connection status using
wg show. Ensure that the
Transfer counters are increasing, indicating that packets are being encrypted and sent through the tunnel. To confirm that your public IP is masked, visit a site like
whatismyipaddress.com from the command line or within a browser on the client machine. The reported IP should match the IP address of your Wireguard server, not your ISP-assigned IP.
Additionally, test for DNS leaks. Many browsers and OS configurations cache DNS results, so clear your DNS cache before testing. You can use tools like
dig to query external DNS servers and ensure they see the request coming from the VPN IP. If you notice that local domain resolution fails, it may be necessary to configure a split-DNS setup, allowing local domains to resolve via your local DNS server while all other queries go through the VPN provider's DNS.
For troubleshooting issues where peers cannot communicate directly through the tunnel, check
Troubleshooting WireGuard Client-to-Client Communication Issues to ensure intermediate routing is not blocking peer-to-peer traffic.
Frequently Asked Questions
Will routing all traffic through Wireguard slow down my internet?
Yes, it will likely increase latency and reduce bandwidth because all data must be encrypted, sent to the remote server, and then decrypted before reaching the final destination. The performance impact depends on the speed and distance of the VPN server. Using a nearby server and ensuring your hardware supports AES-NI instructions can mitigate some of these losses.
How do I prevent DNS leaks when using Wireguard?
Wireguard itself does not handle DNS resolution; it only routes packets. To prevent leaks, you must configure your system to use the DNS servers provided by your VPN provider or a trusted third party. On Linux, you can update your
/etc/resolv.conf or use NetworkManager settings to assign specific DNS servers to the Wireguard interface. Always flush your DNS cache after making changes.
Can I still access my local network devices while all traffic is routed through the VPN?
Yes, but you must explicitly allow local subnet traffic in the
AllowedIPs configuration. Add your local network CIDR (e.g.,
192.168.1.0/24) to the beginning of the
AllowedIPs list. This ensures that traffic destined for local IPs is handled by the local interface, while all other traffic is sent through the tunnel. Without this exclusion, local device discovery and access may fail.
What happens if the Wireguard connection drops?
By default, if the connection drops, your system will revert to its normal routing table, sending traffic directly over the internet and exposing your IP. To prevent this, you can implement a kill switch using firewall rules (iptables/nftables) that block all traffic except when the Wireguard interface is up. Alternatively, some clients offer a built-in kill switch feature that disables network access if the tunnel is lost.
Is it safe to use 0.0.0.0/0 for AllowedIPs on the server side?
No, you should never set
AllowedIPs = 0.0.0.0/0 on the server side for a client peer. This would cause the server to receive all internet traffic from that client, which is inefficient and potentially insecure. The server should only define the specific subnets it needs to reach, such as
10.8.0.0/24 or the client's specific IP. The client uses
0.0.0.0/0 to send everything out, but the server only forwards what is necessary.