When a Remote-Access Client Has to Act as a Branch Gateway

A laptop connected to a VPN can reach headquarters. The printer and file server on the same desk cannot, because nothing forwards their packets into that tunnel or brings the replies back. Turning the client into a branch gateway is a routing and ownership decision before it is a configuration one. The protocol name on the box does not answer whether that role is supported.

What the protocol label does not tell you

OpenVPN documents a site-to-site design in which a connector forwards a whole subnet, and Access Server implements it with a gateway role and explicit routing. A different product marketed as an SSL VPN may expose only remote-user functions, with no supported way to advertise a network behind the client. Version matters as well, since a feature present in one release is not a promise about another. Read the implementation you actually run, and treat a recipe written for a different product as a hint rather than a design.

The question to settle first is whether the VPN owner supports the forwarding role at all. If not, no amount of client-side routing makes it supported.

The contract has two sides: branch and headquarters

On the branch side, one host owns forwarding, filtering, and recovery. It needs a deliberate path from every branch device, and the outer VPN connection has to stay reachable through the underlying network even while the tunnel is down. On the headquarters side, someone must define the branch subnet, accept the gateway's identity, and permit specific resources. Neither half works alone.

The return path is the part that gets skipped. A tunnel address for the client does not advertise the subnet behind it, so headquarters routers need a route that points at the VPN gateway for that prefix.

In a routed design, the concentrator forwards packets for the branch prefix and upstream LAN routing knows how to send replies back to it. In a translated design, the source headquarters sees is rewritten, which can remove the need for one return route while hiding which branch machine sent the traffic. That trade-off belongs in the design document, because application logs and access rules lose per-device identity once translation is in play.

Routed or translated: pick the return path deliberately

Choose routed when per-device identity and per-host policy matter and you can maintain the return route on every relevant router.

Choose translated when you cannot add routes but can accept that headquarters sees one source address. Mixed designs exist and are harder to reason about, so write down which prefixes are routed and which are translated. Then verify the choice with a capture on both ends instead of trusting the tunnel status.

A useful check is asymmetric: request a resource from a branch device, then confirm the reply leaves headquarters toward the branch prefix. traceroute -n 10.60.4.20 from a headquarters host shows whether that path goes through the VPN gateway.

Operate it like infrastructure, not a login

Decide how the gateway starts, authenticates, updates, and recovers with nobody logged in. Credential renewal, multifactor prompts, sleep behavior, and who responds when the branch loses access all become operational questions. Several people sharing one network path must not inherit the gateway user's personal privileges, so resource authorization, logging scope, and the failure policy need a named owner. Sharing an account to avoid per-device enrollment is not a design.

Compare the arrangement with a supported site gateway under the same requirements before committing. Reusing an old desktop does not remove maintenance or recovery work, and the second-hand price does not describe the operating cost.

Validate the intended branch applications, their return traffic, and one denied destination under an approved plan. Success looks like an owned network service with a named branch identity and an explicit policy, not a client window that says Connected.