Corporate VPN Inside WireGuard: Which Layer Goes First?

Two legitimate reasons exist for nesting tunnels on a developer laptop. Either the corporate client has to appear to come from a specific country, or two private networks need to be reachable at the same time. Both cases need the outer tunnel to carry the inner client's own connection.

Starting two clients in some order does not produce that. The routing does.

Compare the Two Possible Orders

Pick the outer layer as the tunnel whose endpoint the public internet can reach. The inner layer is the tunnel whose server only answers through that exit. On Windows the practical split is WireGuard outside and the corporate client inside. The deciding factor is control.

The official WireGuard client applies a complete configuration file, routes and DNS included. Commercial corporate clients usually hide both. Putting a hidden client on the outside leaves you guessing about the path underneath.

The reverse order is not impossible. It is harder to reason about, because the outer client rewrites routes on a schedule you never see.

Let AllowedIPs Name the Corporate Range Only

AllowedIPs lists the destinations that WireGuard routes into the tunnel. For nesting it only needs the inner server address and the corporate prefixes. Everything else stays on the local network, printers and hypervisor included. That is a split tunnel by design, and it avoids the exclusion problem entirely.

A full-tunnel outer layer needs 0.0.0.0/0 minus the local ranges. The format cannot express an exclusion, so the complement has to be computed and pasted in.

[Interface]
PrivateKey = ...
Address = 10.99.4.2/32

[Peer]
PublicKey = ...
Endpoint = 198.51.100.44:51820
AllowedIPs = 198.51.100.44/32, 10.20.0.0/16, 10.21.0.0/16

When the inner client does not install its own routes, list the corporate prefixes yourself. A prefix left off that line is a destination the outer tunnel never carries. A stale copy of the list is worse than none, because it still looks correct.

Order, Metrics and the Second Adapter

Connect the outer tunnel first, then start the corporate client. Its endpoint connection then leaves through WireGuard instead of the local gateway. Give the corporate interface a lower metric so its prefixes win for the addresses it owns.

# which interface currently claims the corporate prefix?
Find-NetRoute -RemoteIPAddress 10.20.10.5 | Select-Object -First 1

# prefer the corporate interface for its own prefixes
Set-NetIPInterface -InterfaceAlias 'Corp VPN' -InterfaceMetric 3
Set-NetIPInterface -InterfaceAlias 'wg-personal' -InterfaceMetric 40

wg show interfaces

Metrics are the step people skip. Without an ordering, whichever route was installed last wins for the overlapping prefix. That changes between boots, which is why the problem looks intermittent.

Clients built on OpenVPN 2.6 add a trap of their own. When the data channel offload adapter is already occupied, a second instance simply refuses to start. Adding disable-dco to the profile falls back to the older TAP path, and both then run side by side.

Where the Nested Path Breaks

Disconnecting the outer tunnel kills the inner one. Reconnecting the inner client alone often sends it straight to the internet, quietly removing the nesting. Test the sequence from scratch each time, starting with both tunnels stopped.

Expect a smaller usable MTU. Each layer adds overhead, so a starting pair around 1420 and 1400 is a place to begin. A transfer that hangs on large packets while small requests succeed is the usual signature. Corporate policy is the other limit, because a client that wants a managed device can treat a nested path as a breach.

When both ends are fixed networks, a site-to-site tunnel between the gateways removes the ordering problem instead of managing it. On one laptop, two tunnels coexist only when each has its own interface and a rule that selects destinations per prefix.