Sometimes one VPN endpoint is not the route you need. You may be able to reach a nearby Windows server, while the connection you want to use for Internet access is on a second server elsewhere. We can join those two machines with WireGuard and let the first pass client connections through the second.
This is the Windows Server Core 2019 experiment I originally described in July 2021, using the official WireGuard client and WireSock VPN Gateway. The useful part is understanding the path: the client connects to Server 1, Server 1 connects to Server 2, and Server 2 provides Internet access. The screenshots below remain from that setup; use your own keys, addresses and installed-version instructions.
How the two hops fit together
The idea came up in a Reddit discussion about reaching an external VPS through a local one. The question was:
So this is solution but i’m not expert in Linux so I didn’t know how to do it technically
the solution?
1. buy one VPS Server located in Iran.
2. buy one VPS Server located out of Iran (Europe or USA)
3. tunnel Iran VPS to out side VPS
so when I connect to Iran VPS from my home or office , all my packet send to vps out of Iran. and from that VPS , we can access to internet.
The path is client → Server 1 → Server 2 → destination. Each WireGuard tunnel ends at its next gateway. Server 1 decrypts its incoming VPN traffic, passes TCP/UDP connections through its proxy, and sends the resulting traffic through a separate tunnel to Server 2. Server 2 handles the outgoing connection to the destination. Replies return through the same sequence.
This is a chain of sequential tunnels, not one tunnel nested inside another. With nesting, the first gateway would carry the client’s still-encrypted inner WireGuard packets. That is a different routing and MTU design. Here the client needs only its connection to Server 1; it does not run two tunnels itself.
Both gateways are trust points. Once a VPN layer ends, its contents are available to that gateway, but application encryption such as HTTPS/TLS remains encrypted between the application and its remote endpoint. Neither gateway automatically gets to decrypt that TLS session.
| Observer | What this chain exposes |
|---|---|
| Server 1 | The client’s connection address, the second gateway and the destinations/traffic available after the first VPN layer ends. In proxy mode it handles the client’s TCP/UDP connections. |
| Server 2 | The first gateway as its WireGuard peer, outgoing destinations and traffic available after the second VPN layer ends. Application data or accounts can still identify a user. |
| Destination | Normally Server 2’s outgoing address for connections taking this path. This is a network-path observation, not an anonymity guarantee. |
An extra hop does not make identification a measurable “twice as difficult.” Provider logs, shared administration, application identity and observations of timing and volume can link the two sides. Choosing a particular country does not remove those risks. A chain can change reachability and egress location; it does not make a blocked WireGuard protocol unrecognizable or establish protection against a global observer.
Prepare the two Windows gateways
The earlier Windows VPN-server article explains the starting point. For package selection and installation, use the WireSock VPN Gateway Server Core guide and the official WireGuard downloads. Gateway is the wiresock-service / wg-quick-config package; it is separate from the WireSock Secure Connect desktop client or CLI/SDK.
Use proxy mode on both gateways. The package overview describes it as transparent TCP/UDP forwarding through local proxies, using Windows Packet Filter. It does not forward every IP protocol: external ICMP/ping is not supported in this mode. System HTTP/SOCKS proxy settings can also affect the outgoing path.
Before changing a remote server’s routes, retain provider-console or another independent recovery access, save its configurations and service settings, and allow the required WireGuard UDP ports in the host/cloud firewalls. Server 1 must be reachable by the client; Server 2 must be reachable by Server 1. Check each single-hop connection before combining them. A small VPS may be enough for an experiment. Choose CPU and bandwidth capacity for the expected workload.
Before generating either configuration, choose different, non-overlapping private subnets for the two tunnels, avoiding conflicts with either server’s physical LAN and the end client’s LAN. The current public generator prompts for a subnet when creating a fresh configuration. Do not accept the same default on both hosts. Existing generated configurations keep their earlier settings; inspect them rather than assuming a later command changes their subnet.
| Connection | Illustrative addressing |
|---|---|
| Client ↔ Server 1 | Server 1: 10.41.41.1/24; client: 10.41.41.2; server-side peer AllowedIPs: 10.41.41.2/32. |
| Server 1 ↔ Server 2 | Server 2: 10.42.42.1/24; Server 1 uplink: 10.42.42.2/24; Server 2 peer AllowedIPs: 10.42.42.2/32. |
These addresses illustrate the roles, not values to paste over an existing installation. The proxy creates outgoing connections on Server 1; this example is not a site-to-site recipe that routes the client subnet unchanged through Server 2. If driver installation requires a reboot, schedule it with recovery access available; first check logs, binding, endpoints and firewalls rather than treating a reboot as a general connectivity fix.
With those subnet choices ready, run the following command in an elevated shell on each prepared host:
wg-quick-config -add -startIt generates the server profile wiresock.conf and a client profile such as wsclient_1.conf, starts the server tunnel, and shows a client QR code. The public tool documentation also describes adding another peer with wg-quick-config -add -restart; restarting affects existing clients.
Connect Server 1 to Server 2
Take the client profile generated on Server 2 and transfer it securely to Server 1. It is Server 1’s identity on the second tunnel, not the profile to import on your phone or laptop. Keep private keys and QR codes private; do not reuse the historical values shown in screenshots.
Server 1 now has two roles: its wiresock tunnel accepts the end client, while a separate vpn2 tunnel connects outward to Server 2. The official Windows client applies a restrictive firewall policy for a single-peer configuration with a default /0 AllowedIPs entry. To avoid that policy on the second tunnel, replace 0.0.0.0/0 with the two IPv4 halves below. The upstream networking notes document this distinction.
[Interface]
PrivateKey = YOUR_SERVER1_UPLINK_PRIVATE_KEY
Address = 10.42.42.2/24
DNS = 8.8.8.8, 1.1.1.1
MTU = 1420
[Peer]
PublicKey = YOUR_SERVER2_PUBLIC_KEY
AllowedIPs = 0.0.0.0/1, 128.0.0.0/1
Endpoint = 198.51.100.20:59075
PersistentKeepalive = 25This is an illustrative profile. Replace both key placeholders, the documentation-only endpoint, addresses and resolver choices with the values generated for your setup; retain any required preshared key. The two /1 prefixes together cover the entire IPv4 address space. They relax the official client’s /0-specific firewall behavior; they do not provide a kill switch. More-specific local routes can still win, and removing vpn2 can let outgoing connections fall back to Server 1’s ordinary route.
The listing carries IPv4 only. It says nothing about a client’s or gateway’s native IPv6 path. If IPv6 is enabled, either design and verify it through both hops or enforce and test an appropriate blocking policy for traffic that must not bypass the chain. A working IPv4 test does not establish IPv6 coverage. Likewise, MTU = 1420 is the original example’s choice, not a guarantee for every underlay; verify larger transfers and path MTU on both links.
Save the adapted profile as C:\VPN\vpn2.conf on Server 1 in a directory with access restricted to administrators and the tunnel service identity. Use your own protected location if it differs. Keep Server 2’s public UDP endpoint reachable over Server 1’s underlay, and check that the client-facing tunnel and management path remain reachable after the second tunnel starts.
On a Windows desktop, import the profile through the WireGuard GUI. For Server Core, the official tunnel-service interface supports the following PowerShell commands, assuming the standard installation directory:
& "$env:ProgramFiles\WireGuard\wireguard.exe" /installtunnelservice "C:\VPN\vpn2.conf"
& "$env:ProgramFiles\WireGuard\wg.exe" show vpn2The first command installs the separate WireGuardTunnel$vpn2 service. The second inspects its state; a recent handshake proves peer reachability, not that every client connection follows the intended route. Check counters and endpoint observations while generating actual TCP and UDP traffic.
Check DNS as well as the outgoing address
In the original experiment, a client connected to Server 1 showed Server 2’s public address, but a DNS test also reported resolvers associated with Server 1. Gateway has its own DNS-forwarding behavior, separate from the DNS field in the second WireGuard profile. Changing an upstream resolver address is useful, but it does not itself force the query through the second tunnel.
The Gateway command reference documents the -dns override. The commands below reconfigure the proxy service. They use explicit .exe names so that sc is not mistaken for the Windows PowerShell alias. Run these commands only during a planned interruption: record the current service command/account first, use the real client-facing adapter name, and preserve any custom installation options. The example assumes that adapter is named wiresock, not vpn2.
sc.exe qc wiresock-service
wiresock-service.exe uninstall
wiresock-service.exe install -start-type 2 -mode proxy -interface wiresock -log-level none -dns "1.1.1.1, 1.0.0.1"
sc.exe start wiresock-serviceThat change removed Server 1’s resolver from the original website’s report. Treat it as an observation about that setup, not a universal DNS-leak fix. Confirm where the queries actually leave Server 1 and Server 2. Ordinary Windows multi-interface DNS, the end client’s resolver configuration and application-level encrypted DNS can take different paths; a resolver’s name in a test report does not establish the path of every lookup.
The important failure test is stopping the second tunnel while the first remains active. Because the /1 approach deliberately avoids the default-route firewall restrictions, fail-closed behavior needs a separately designed policy covering the Gateway proxy’s outgoing flows and DNS, with the required transport and management exceptions. This article does not supply or claim to have tested that firewall policy.
| Test | Evidence to collect |
|---|---|
| Each hop separately | A recent handshake plus successful allowed TCP/UDP traffic. Do not use an external ping failure to diagnose proxy mode. |
| Both hops connected | Client TCP/UDP connections reach a controlled destination from the expected second-gateway egress. Observe Server 1’s and Server 2’s interfaces as well as the client-facing result. |
| Second hop stopped or failed | With the first hop still up, check for direct fallback through Server 1. If fail-closed operation is required, confirm the intended traffic is blocked rather than assuming it. |
| DNS and IPv6 | Check conventional DNS, application encrypted DNS and each enabled address family. Confirm the resolver path and any intentional blocking policy. |
| Reconnect, reboot or network change | Verify both tunnel identities, routes, service arguments and traffic paths again; retain independent recovery access. |
Why the original experiment used proxy mode
During the Server Core 2019 experiment I also tried Gateway’s NAT mode and lost connectivity when it enabled forwarding while the second WireGuard tunnel was active. My investigation associated it with the service’s call to EnableRouter: WireGuard’s transport UDP packets ended up taking the wrong interface. I kept the chain in proxy mode.
That is the historical result, not a claim that every current Windows/WireGuard/Gateway combination has the same fault. Microsoft documents EnableRouter as enabling IPv4 forwarding; it is not itself a NAT implementation or proof of a WireGuard routing bug. Without the exact binary versions, that failure cannot be attributed to a particular current release. Keep the proxy-mode scope of this walkthrough; testing another forwarding design calls for an isolated lab and console recovery.
Two hops are useful when they solve a specific reachability or egress problem. Keep that goal visible: first make each hop work, then verify the combined path, DNS and failure behavior. A second public IP address in a browser is a starting check, not the whole result.