Remote-Access or Site-to-Site VPN: Which One Fits?

A traveling employee and a branch office need different tunnels, and picking the wrong one produces a design that works in a lab and fails on the first Monday. Remote access joins a device to a gateway. Site-to-site joins two gateways that represent networks. The checklist below settles which one the requirement actually describes.

Who dials, and what sits behind the dialer

In remote access, software on the laptop or phone establishes the tunnel, and the gateway authenticates a user, a device, or both before assigning an address and routes. In site-to-site, routers, firewalls, or cloud gateways establish the connection, and devices behind them use ordinary routing instead of running a client. That difference decides who owns the tunnel's uptime: an employee's device in the first case, a managed appliance in the second. It also decides whether authentication describes a person or a network.

Stop here if the requirement is that every machine in one office reaches another office without per-device setup. That is site-to-site, and a pile of remote-access logins is a poor substitute.

Addressing and the return path

Plan distinct local and remote ranges. Two sites can both use the same private subnet, and the design then needs translation or renumbering before routing can be unambiguous. A home router using the same range as headquarters creates the same problem for one remote worker. Overlap is common enough that checking for it belongs in the first conversation.

The reply path matters as much as the outbound one. A server can receive a request and still have no route back to the client network.

Document which router knows the remote prefix, especially with cloud networks and several gateways. A green tunnel icon cannot answer whether a destination has a working return route, and neither can a ping in one direction. In remote access the gateway usually owns the pool route; in site-to-site, every intermediate router that carries the prefix has to agree. Translation can hide a missing route until an application that embeds addresses breaks.

Internet exit is a separate decision

Private reachability does not require the tunnel to carry public browsing. Whether ordinary web traffic exits through the gateway is a second decision, made per design and recorded in the client profile or the site configuration.

Full-tunnel and split-tunnel are answers to that question, not to the remote-access versus site-to-site question. Internal names need suitable DNS in both designs, because a public resolver has no answer for a private office hostname. Pushing a resolver and pushing a default route are related settings, and changing one without the other produces failures that look like DNS problems.

Use the topology to narrow the fault

One roaming laptop losing access points at the client, its account, or its local network. A whole branch losing access points at shared paths and gateways.

Check tunnel establishment first, then routes, then permitted traffic, then name resolution, then application login, and stop at the first step that fails. ip route get 10.60.8.15 answers the routing question before you read a single application log. Encryption settings do not fix a file-share permission error, and a working ping does not prove an application is authorized. Keeping the order fixed prevents the random configuration changes that turn one fault into three.

Finally, keep the definitions straight when reading vendor material: a commercial internet-exit server is a different service from a company's private gateway and grants no access to that company's network.