NAT at the VPN Server or at the Router? Both Can Work

Marking a connection as the default route on a laptop is the step everyone remembers, and it is the one that changes nothing on the gateway. The client now sends Internet requests into the tunnel; whether they leave the building depends on forwarding, a translation point and a return path that reaches the client's private address. Two arrangements can supply all three, they put the work in different places, and both fail in the same silent way when nobody owns the reply direction. Choosing between them is a question about who should see the client pool.

The Myth: A Client Route Builds the Exit

Force tunnelling is a client-side policy: it decides that traffic goes to the VPN adapter instead of the physical one. Microsoft's VPN routing documentation describes that split and force behaviour, and it is a statement about the client's route table rather than about the server's forwarding rules. From the client's point of view the tunnel is where the Internet lives; from the gateway's point of view a packet arrived from an address nobody upstream has ever heard of. Neither side is misconfigured in isolation, which is why the failure looks like a broken server to the person at the laptop.

That mismatch is the whole problem the rest of this article solves. Something has to make the client's private address returnable, and the choice is where.

Draw the Reply Path First

Write the path down with real addresses before touching a setting, and mark the two candidate translation points on it. This lab uses a VPN pool of 10.70.0.0/24 with one client at 10.70.0.37, a server LAN address of 172.16.40.10, a router at 172.16.40.1 and a public exit of 203.0.113.40.

client 10.70.0.37 -- tunnel --> RRAS 172.16.40.10 -- LAN --> router 172.16.40.1 --> 203.0.113.40
                                  (translate here?)                             (or here?)

The server already browsing the Internet only proves its own path. A packet forwarded on behalf of a client is a different decision, made by forwarding policy on the same machine, and it is the one that is usually missing. Marking the three decision points on the diagram keeps the conversation about one of them at a time.

Option A: Translate on the VPN Server

Here the server translates the client's source to its own LAN address before handing the packet to the router, and the router applies its ordinary translation on the way out. On the reply, the router's mapping restores the server address and the server's mapping restores the client address. Two stateful translations in series are normal and workable, provided both are recorded; the router never needs a route to the pool, which is the appeal of this arrangement.

Get-RemoteAccess | Select-Object VpnS2SInterface, RoutingDomain
Get-NetNat | Select-Object Name, InternalIPInterfaceAddressPrefix

Use these reads to see what the server already has rather than assuming a NAT is in place. A Linux masquerade rule copied from a blog is not a Windows configuration, and a host-firewall allowance for the VPN listener is not the same policy as permission to forward a client's request onward. Confirm the server's forwarding role from its own management surface, then look at translation separately, because the two are often enabled by different parts of a deployment.

Option B: Carry the Pool to the Router

In the second arrangement the server forwards the client's real source address, and the router translates it. That keeps the client pool visible at the edge, which helps if the router is where traffic policy, logging or inspection lives. It also means the router needs a return route for 10.70.0.0/24 pointing at 172.16.40.10, plus an Internet policy that actually includes that prefix; a rule written for the LAN subnet does not silently extend to the pool.

Choose this when the edge device is the intended policy owner and can accept another prefix in its routing and translation tables. Choose the server-side translation when the pool should stay invisible upstream and the router is not administered by the same team. Neither option is implied by any checkbox on the client, and neither is more secure in general; they place visibility and maintenance in different places.

Make DNS, IPv6 and Acceptance Explicit

Address translation does not fix name resolution. The client may use a resolver delivered with the VPN profile, a private resolver for specific namespaces, or an approved public one, and an unreachable resolver under that policy will keep failing after the routing works. Test a name and an address separately so the two failures never get merged into one report.

IPv6 needs its own paragraph in the design. A working IPv4 translation says nothing about whether IPv6 clients have a route, a valid public source or a policy that blocks them when the tunnel drops. Leaving that unstated means half the clients quietly bypass the gateway while the other half work.

For acceptance, follow one permitted client request and its reply across both boundaries, and write down the address each boundary should see at that moment. That record is what makes the next pool change a five-minute edit instead of an argument about who owns the missing return route. Keep the record with the client profile rather than in a ticket, since the profile is what the next engineer will find first.