One Azure VM needs the tunnel: guest client or VPN gateway?
Three conditions decide whether a single Azure VM should run its own VPN client or whether the connection belongs at the network layer instead.
One workload in one Azure VM has to reach a private network through a tunnel. The question that decides the design is not which VPN product is better; it is whether any other machine will ever need that path. Answer that first and the rest of the architecture usually picks itself. Get it wrong and you inherit a VM that quietly became a router nobody documented.
Two jobs that look alike
A VM can be an endpoint or a transit point, and the difference is not the software you install but who consumes the tunnel. As an endpoint, the guest runs a client for its own processes. As a transit point, it forwards other workloads' packets, which makes it part of your network topology.
| Job | What the VM does | Who owns routing |
|---|---|---|
| Workload endpoint | Runs a supported client for its own processes | Guest routes select the approved destinations |
| Transit appliance | Forwards other workloads into the site connection | Subnet route tables, NIC forwarding, guest policy and return paths |
Most single-VM requests are the first job wearing the language of the second. Someone says "the VM is our VPN" when they mean one application on it needs to reach a database on the other side.
Condition one: does anything else need the far side?
If the answer is no, install the client in the guest and stop designing. Nothing about that choice requires the managed gateway, and nothing about it makes the VM a gateway for its neighbors. You are adding a route inside one operating system.
If the answer is yes, or probably yes within a year, treat it as a network design now. Other VMs reach a transit VM only when the subnet route table sends them there and the NIC accepts forwarded traffic, so the work is route tables and forwarding permissions, not another client install.
Condition two: can you keep the administration path?
A VPN client that installs a broad route can capture the path you use to administer the VM. If the tunnel's destination list overlaps the management network, your SSH or RDP session drops the moment the client connects, and the fix has to be applied through the serial console or a rebuild.
Check before and after. On Linux, ip route get <management-ip> tells you which interface and source the kernel would use right now; compare that with the answer while the tunnel is up. A split tunnel with an explicit destination list is easier to defend than a default route, and it is usually what the workload actually needs.
Condition three: who patches it at midnight?
A guest client is your operating system, your client version and your certificates. That is fine when you already run the VM and its patch cycle. It is a poor trade when the VM exists only to hold the tunnel. Count the patching hours before you call the guest client cheaper. A client upgrade that needs a reboot is an outage you scheduled for a machine that exists to keep the tunnel up.
The managed gateway moves that maintenance to the platform. You still own identity, authorization and the network paths behind it, but you are not rebooting a machine to apply a client update.
What the managed gateway does not do
Azure VPN Gateway is a VNet connectivity service with its own site-to-site and point-to-site arrangements. It is not a rule that forbids guest VPN software, and it is not a drop-in replacement for a client that one application needs.
What it gives you is a connection at the network layer, reachable by many workloads through routing. What it does not give you is a tunnel that only one process on one VM uses, scoped to that process's identity. That scope is not a limitation to apologise for; it is the point of the guest-client design. One application, one route, one credential set, no effect on the other VMs in the subnet.
So the comparison is not managed versus software. It is network-scoped connectivity versus process-scoped connectivity, and the second one is legitimate when only one process needs it.
Plan the growth path before you need it
If the requirement grows from one VM to a subnet, rebuild the design instead of widening the client's allowed prefixes. Reusing a convenient session as an undocumented router ties every consumer to that VM's lifetime, its credentials and its patch window.
The Azure VPN Gateway overview is the right starting point once the connection is network-scoped rather than workload-scoped.
Before you choose, write three lines: what needs the far side, who administers the VM, and who patches the tunnel. If all three answers point at one workload, a guest client is the honest design. If any of them points at a subnet, design the network layer now.