To reroute WireGuard traffic from a PC to a VPS and then to another VPN server, you must establish a three-peer chain where the VPS acts as an intermediate relay. This configuration requires careful adjustment of IP addresses, allowed IPs, and kernel routing policies on both endpoints to ensure packets traverse the correct interfaces without looping or dropping.
Understanding the Three-Peer Topology
In this scenario, you have three distinct entities: your local PC (Client), a Virtual Private Server (VPS) acting as the middleman, and a final destination which is another VPN server or network. The goal is not just to connect two devices, but to tunnel traffic through one secure link into another. Standard WireGuard configurations typically handle point-to-point connections. To achieve a chain like PC -> VPS -> VPN, the VPS must be configured to forward traffic between its own WireGuard interface and its external network interface or another internal WireGuard peer.
This setup is particularly useful when your local ISP blocks certain ports or when you need to hide your origin IP from the final destination by using the VPS as a proxy. It effectively creates a multi-hop tunnel. Before proceeding, ensure that all three parties have unique private IP ranges assigned within their respective
[Peer] sections to prevent IP conflicts. For instance, if the PC uses
10.0.0.2/32, the VPS might use
10.0.1.2/32, and the final VPN server might use
10.0.2.2/32.
Configuring the Intermediate VPS
The most complex part of this architecture is the VPS. It must listen for connections from the PC and simultaneously route those packets toward the final VPN server. First, install WireGuard on the VPS if it is not already present. Create a new configuration file, typically located at
/etc/wireguard/wg0.conf.
You need to define two peers in this configuration: one for the PC and one for the final VPN server. However, since the VPS is the "server" for the PC and a "client" for the final VPN, the structure varies slightly depending on whether the final link is also a WireGuard tunnel or just standard internet traffic routed through the VPS. If the final destination is another WireGuard server, you essentially have two separate tunnels meeting at the VPS.
The VPS configuration should look similar to this for the PC connection:
[Interface]
Address = 10.0.1.1/24
ListenPort = 51820
PrivateKey = YOUR_VPS_PRIVATE_KEY
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -D FORWARD -o wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
[Peer]
# Configuration for the PC
PublicKey = PC_PUBLIC_KEY
AllowedIPs = 10.0.0.0/24
PersistentKeepalive = 25
The critical line here is
PostUp. This enables IP forwarding and masquerading, allowing the VPS to act as a gateway. Without this, the VPS will receive the packet but drop it because it does not know how to send it out to the internet or the next hop. You must also enable IP forwarding in the Linux kernel by running
sysctl -w net.ipv4.ip_forward=1 and making it permanent in
/etc/sysctl.conf.
If the VPS is connecting to another WireGuard server, you would add a second
[Peer] section for that server, treating the VPS as a client to that specific peer. In this case, the
AllowedIPs for the PC peer should include the entire range of the next hop, not just the PC's subnet.
Setting Up the Local PC Client
On your local PC, the configuration remains relatively simple. You only need to configure the connection to the VPS. The key difference lies in the
AllowedIPs directive. Normally, you might set
AllowedIPs = 0.0.0.0/0 to route all traffic through the VPN. However, in a multi-hop scenario, you must be precise.
If you want all your internet traffic to go PC -> VPS -> Final VPN, your
AllowedIPs should still be
0.0.0.0/0. This tells the PC to send everything to the VPS. The VPS then handles the rest. Ensure that the
Endpoint points to your VPS's public IP address and port.
[Interface]
Address = 10.0.0.2/32
PrivateKey = YOUR_PC_PRIVATE_KEY
[Peer]
PublicKey = VPS_PUBLIC_KEY
Endpoint = VPS_PUBLIC_IP:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25
Note the use of
/32 for the Address. This is crucial. Since the VPS is managing the routing for the next hop, the PC only needs its own specific IP. Using a larger subnet mask like
/24 can cause routing conflicts if the VPS expects specific subnet behaviors.
Configuring the Final VPN Server
The final step depends on what the "VPN Server" actually is. If it is a standard commercial VPN service accessed via the VPS, no additional WireGuard configuration is needed on the final end. The VPS routes the traffic out to the public internet, and the commercial VPN sees the VPS's IP.
If the final endpoint is another self-hosted WireGuard instance, you must configure that server similarly to the VPS. It needs to accept connections from the VPS and route them appropriately. You may find it helpful to read
How to Isolate WireGuard Networks on a Small Linux VPS Host with Multiple VPNs to understand how to manage overlapping IP spaces if your networks are complex.
Ensure that the final server's
AllowedIPs includes the source range from the VPS. Also, verify that firewall rules on the final server allow incoming traffic from the VPS's IP address on the WireGuard port.
Troubleshooting Common Issues
When setting up such a chain, several issues can arise. The most common is asymmetric routing or packet loss due to incorrect
AllowedIPs. If traffic stops flowing after the VPS, check the VPS logs using
journalctl -u [email protected]. Look for errors related to dropped packets.
Another frequent problem is MTU mismatches. WireGuard adds overhead to packets. If your underlying network has a lower MTU than the default 1500, packets may fragment or drop. Try setting
MTU = 1420 in your WireGuard configuration files on all three ends.
For more detailed guidance on handling communication between home setups and VPS instances, refer to
Communication between home Wireguard w/o public IP and another Wireguard instance in a VPS. This resource provides deeper insights into NAT traversal and connectivity stability.
Finally, ensure that
PersistentKeepalive is set correctly. If any device is behind a strict NAT, omitting this flag can cause the connection to drop after a period of inactivity. A value of
25 seconds is generally safe for most residential and cloud environments.
Frequently Asked Questions
Can I route specific websites through the chain?
Yes, you can modify the
AllowedIPs field on your PC to list specific IP ranges or subnets instead of
0.0.0.0/0. This allows selective routing while keeping other traffic direct. You can also use split DNS or routing tables on the VPS to direct specific domains.
Does this setup increase latency?
Absolutely. Each hop adds processing time and physical distance. Traffic travels from your PC to the VPS, and then from the VPS to the final destination. This double-hopping significantly increases ping times compared to a single-hop connection.
What happens if the VPS goes offline?
Your connection to the final VPN server will break immediately. The PC will continue to try to connect to the VPS endpoint, but packets will be lost. You will need to manually reconnect once the VPS is back online, unless you have implemented failover mechanisms at the OS level.
Is this configuration secure?
It is as secure as the weakest link. All data is encrypted between PC and VPS, and between VPS and the final server. However, the VPS operator can potentially see unencrypted traffic if it exits to the plain internet between hops. Always ensure the final leg is also encrypted.
Do I need root access on the VPS?
Yes, configuring WireGuard with IP forwarding and iptables rules requires root privileges. You cannot easily run this as a standard user without complex namespace isolation, which is beyond basic routing setups.