Windows VPN Gateway: Three Jobs and Three Owners

Three functions get bundled together whenever someone says VPN server: ending the encrypted tunnel, moving packets between networks, and optionally rewriting addresses. On Windows those live in different parts of the stack, even when one box performs all of them. Each has its own inputs and its own failure mode, and each can be handed to a different product. Separating them on paper is the cheapest way to keep a small deployment understandable.

A readable design names the owner of each flow instead of describing the machine as a role.

Terminate, Forward, Translate

RRAS handles the tunnel for the Windows-native case: it authenticates the user, assigns an address from a pool and decides which destinations are permitted. A different VPN product can own the listener and the virtual adapter instead, leaving Windows to forward the decrypted packets. Microsoft's Remote Access documentation separates VPN, site-to-site and routing roles, and installing the routing role does not create a second VPN identity. Adding another VPN application does not hand its adapter to every existing gateway feature either.

Translation is the third and most optional job. It sits after forwarding and changes the source address the far network observes. Whether you need it depends on what the destination network will accept as a source, not on the fact that the machine is called a VPN gateway.

Who Owns the Adapter and the Pool

When several products share the host, four things need a single owner each: listener ports, adapter lifetime, client address pool and routes. The adapter is the awkward one, because a VPN service may create it dynamically and destroy it on disconnect. Treating that interface as a permanently named NIC, and writing rules against its name, works until the next reconnect. Use the product's supported integration point rather than hard-coding an interface name.

The address pool is the second collision. Two products handing out overlapping ranges produce routing that looks correct and delivers nothing. Keep the pools in the same document as the routes, so a change to one is visible against the other.

Preserve the Source or Rewrite It

Preserving the client's source address keeps per-user visibility: logs, quotas and firewall rules can distinguish one user from another. The price is that the destination LAN needs a return route pointing back at the gateway, and somebody has to maintain it. Rewriting the source with NAT removes that requirement and removes the visibility with it. Choose deliberately and write down which information the rewrite hides.

Private-network access, internet egress and connections that terminate on the gateway itself are three different paths. They do not all need the same treatment.

Describe the Flow in One Sentence

One sentence should describe the design: which clients this service admits, which resources that forwarding policy grants, and how the return path completes the flow. If the sentence needs a second NAT layer to be true, that is usually a sign the earlier pieces were not settled. The host is also a shared failure and trust boundary, so a routing change can affect both user access and administration. Keep an independent recovery path for the latter.

Maintain a role inventory next to the configuration: which product terminates, which forwards, which translates, and who can change each. That list is what makes the next change reviewable.

When the sentence becomes unclear, adding another translation layer rarely clarifies it. Removing one usually does.