Site-to-Site vs Remote Access VPN: Differences and Use Cases
Basics4 minInnovialabs editorial team
In short
A site-to-site VPN permanently links whole networks, such as a head office and a branch, through routers, while a remote access VPN connects individual employees from their laptops and phones through a client app.
The short answer
A site-to-site VPN is a permanent encrypted tunnel between two or more networks. Routers or firewalls at each location build it, and employees do nothing: a computer in the branch simply sees the server in the head office as if they were on the same network.
A remote access VPN connects a single device to the company network. An employee at home or travelling starts a VPN client, signs in and gets access to internal resources.
Put simply: site-to-site connects buildings, remote access connects people.
Side-by-side comparison
| Aspect | Site-to-site | Remote access |
|---|---|---|
| What it connects | Network to network | Device to network |
| Who starts it | Routers, automatically | The user, via a client |
| Tunnel uptime | Always on | Only during a session |
| Hardware | Router or firewall at each site | Gateway at the office plus a client on each device |
| Authentication | Between gateways: keys, certificates | Per user: login, certificate, MFA |
| Typical use | Branches, warehouses, shops | Remote work, business trips, contractors |
Protocols in use
- IPsec is the classic choice for site-to-site. Nearly all business network gear supports it, which helps when sites run routers from different vendors. It is also used for remote access (for example IKEv2), including by built-in OS clients.
- WireGuard is a modern protocol with a small codebase and simple key-based setup. It works for both scenarios and is fast, but managing many users by hand is awkward: you need extra tooling to issue and revoke keys.
- OpenVPN is a flexible option running over TLS. It is popular for remote access: clients exist for every platform and it passes through restrictive networks more easily.
- SSL VPN features in firewalls are vendor solutions with their own client or web portal, aimed at remote staff.
A minimal WireGuard config for a tunnel between two offices (one side):
[Interface]
Address = 10.99.0.1/30
PrivateKey = <office A private key>
ListenPort = 51820
[Peer]
PublicKey = <office B public key>
Endpoint = office-b.example.com:51820
AllowedIPs = 10.99.0.2/32, 192.168.20.0/24
PersistentKeepalive = 25
AllowedIPs defines which branch subnets are reachable through the tunnel.
Hardware you need
For site-to-site:
- a VPN-capable router or firewall at every site;
- ideally a static IP at least at one end, or DDNS;
- non-overlapping subnets: if both office and branch use 192.168.1.0/24, routing breaks.
For remote access:
- a VPN gateway in the office or in the cloud, sized for the number of simultaneous connections;
- clients on laptops and phones;
- an account system, ideally tied to your user directory, with multi-factor authentication.
How much upkeep to expect
Site-to-site is usually configured once and then watched for stability: tunnel monitoring, firmware updates, certificate renewals. Users never notice it.
Remote access needs ongoing work: granting and revoking access when people join or leave, helping with clients, resetting passwords, controlling what each person can reach. The more people, the more central management matters.
Common mistakes
- Full network access for every remote user. Limit access to the servers and ports people actually need.
- No MFA on remote access — one leaked username and password opens the network.
- Identical subnets across offices when setting up site-to-site.
- Forgotten accounts of former employees and contractors.
- No monitoring — you learn the tunnel is down from branch staff.
How to choose
- You have several permanent locations that share a server, accounting system or cameras — choose site-to-site.
- Staff work from home or on the road — choose remote access.
- You have both — use both types: branches linked by tunnels, remote staff connecting to a central gateway.
- If most resources already live in the cloud, consider per-application access models (Zero Trust) instead of whole-network access.