A business VPN does one of two jobs: it connects people to the company network (remote access), or it connects one location to another (site-to-site). Carrier private networks and SD-WAN do the site-to-site job in different ways, and zero trust access is replacing the remote-access VPN for many companies. The right choice depends on what is connecting to what, how many of them there are, and how much the traffic matters.
The consumer VPN apps advertised for privacy and streaming are a different product. They route your traffic through a provider's servers to hide your location. A business VPN connects you to your own systems. The rest of this guide is about the business kind.
Remote-access VPN: connecting people
A remote-access VPN puts software on each laptop or phone. When a user connects, the software builds an encrypted tunnel to a VPN gateway, usually your office firewall or a cloud service, and the device behaves as if it were on the office network.
The protocols you will hear about
- IPsec, usually with IKEv2. A long-standing standard, widely supported by firewalls and built into most operating systems.
- SSL or TLS VPN. Runs over the same port as secure websites, so it passes through hotel and airport networks that block other traffic. Many firewall vendors ship their own client for this.
- WireGuard. A newer, lean protocol known for simple configuration and good performance. Increasingly common in commercial products and mesh VPN services.
For most buyers the protocol matters less than whether the product supports multi-factor sign-in, works on every device you use, and is kept patched.
Full tunnel or split tunnel
In a full tunnel, all of a user's traffic goes through the VPN, including web browsing and cloud apps. That gives the office firewall full visibility, but every video call from a remote worker crosses your office circuit twice. In a split tunnel, only traffic for company systems goes through the VPN and everything else goes directly to the internet. Split tunnelling saves bandwidth and improves call quality, at the cost of the office firewall not seeing the rest of the traffic. Many businesses split-tunnel and rely on protection on the device itself.
Site-to-site VPN: connecting places
A site-to-site VPN links two networks permanently. The firewall at each location builds an encrypted IPsec tunnel to the other over the ordinary internet, and staff do not need to do anything. A branch can print to the head office printer or reach a server as if it were down the hall.
- Hub and spoke. Every branch connects to one central site. Simple, but branch-to-branch traffic goes through the hub and the hub's circuit becomes critical.
- Mesh. Every site connects to every other site. Better paths, more tunnels to manage as the count grows.
- Cloud gateways. The major cloud providers offer VPN gateways so an office firewall can build a tunnel straight into your cloud environment.
Site-to-site tunnels work best when at least one end has a static IP address. A dynamic address can be handled with extra configuration, but it is one more thing to break.
Carrier private networks
Before internet VPNs were reliable, businesses connected sites with private networks bought from a carrier, mainly MPLS and Ethernet services. These do not cross the public internet. Traffic stays on the carrier's network, with performance commitments in the contract. They are private but not necessarily encrypted, so some businesses add encryption on top. They cost more than internet-based tunnels and suit traffic where predictable performance matters more than price. We compare them in MPLS vs SD-WAN.
SD-WAN: tunnels that manage themselves
SD-WAN builds encrypted tunnels between sites automatically, over whatever circuits each site has, and steers traffic over the best path at that moment. In practice it is a managed fleet of site-to-site VPNs with central control, failover between circuits and per-application rules. Once you pass a handful of sites, managing individual IPsec tunnels by hand gets tedious, and that is usually when SD-WAN earns its fee.
The options side by side
| Option | Connects | Runs over | Encrypted | Fits best when |
|---|---|---|---|---|
| Remote-access VPN | People to the network | Any internet connection | Yes | A modest number of remote users need office systems |
| Zero trust access (ZTNA) | People to specific apps | Any internet connection | Yes | You want to limit what each user reaches |
| Site-to-site IPsec | Site to site, or site to cloud | Internet circuits at each end | Yes | Two to a handful of locations |
| SD-WAN | Many sites | Any mix of circuits | Yes | Several sites, more than one circuit each |
| MPLS or Ethernet private line | Sites on one carrier network | Carrier's private network | Not by default | Performance-sensitive traffic between fixed sites |
Remote access is increasingly moving to zero trust products, which give each user access to specific applications rather than the whole network. We explain the difference in zero trust network access explained.
Sizing: the number on the datasheet
Encryption takes processing power. Firewall datasheets usually list a "firewall throughput" figure and a much lower "IPsec VPN throughput" figure, and it is the second one that limits your tunnels. If your office has a 1 Gbps circuit but the firewall's VPN throughput is a fraction of that, VPN traffic will hit the firewall's ceiling well before the circuit's. Check both numbers, and check the maximum number of concurrent remote users the license allows.
Two other things catch people out. Encryption adds a little overhead to every packet, which can cause problems with packet size if it is not configured properly. And a hub site needs good upload as well as download, because every remote user and branch pulls data out of it.
A worked example
A hypothetical illustration. The business and figures are invented.
A company has a head office, two branches and 25 people who work from home some of the time. The file server and an inventory system live at head office. The branches each need to reach both systems all day.
A sensible design: site-to-site IPsec from each branch firewall to head office, and a remote-access solution for the 25 home workers, split-tunnelled so their video calls do not cross head office. Say each branch pulls up to 50 Mbps from head office at busy times and remote users add another 60 Mbps combined. Head office needs roughly 160 Mbps of upload headroom for this traffic on top of its own use, and a firewall whose VPN throughput comfortably exceeds that. A symmetrical fiber circuit at head office fits. A cable plan with a thin upload probably does not.
If the company later adds a fourth and fifth site, or wants each branch on two circuits with automatic failover, that is the point to price SD-WAN rather than keep adding tunnels by hand.
Security basics for any VPN
- Require multi-factor authentication for every remote user, without exceptions for executives.
- Patch the VPN gateway promptly. Internet-facing VPN appliances are a common target, and vendors regularly publish urgent fixes.
- Disable old protocols and unused features on the gateway.
- Remove accounts the day someone leaves.
- Log connections and review them, or have someone review them for you.
- Limit what each remote group can reach, rather than giving every user the whole network.
Our cybersecurity page covers managed firewall and remote-access options.
Where the VPN gateway should live
For a single office, the gateway is usually the office firewall, which is simple and costs nothing extra. It also means remote access depends on that one office: if the office circuit or firewall goes down, nobody working from home can reach anything, even systems that live in the cloud. Businesses whose applications have mostly moved to the cloud sometimes put the gateway in the cloud instead, or use a hosted remote-access service, so remote staff are not tied to the health of one building.
If the gateway stays at the office, two things help. A backup circuit with automatic failover keeps remote access up when the primary line fails, and the VPN should be configured to answer on both circuits. And the firewall itself should be on a battery backup, because a short power cut at the office otherwise disconnects every remote user at once.
Mistakes we see often
- One shared VPN login. Everyone using the same account means you cannot tell who connected, and you cannot remove one person without changing it for everybody.
- Overlapping address ranges. If a branch and head office both use the same internal address range, a site-to-site tunnel between them will not route properly. Plan addressing before the second site opens.
- A firewall sized for the circuit, not the tunnels. The headline throughput fits; the VPN throughput does not.
- Forgotten tunnels. Tunnels to closed sites, old vendors or former cloud accounts left running for years. Each one is a door.
- No monitoring. A tunnel that drops overnight is discovered when the branch opens and cannot print.
Questions to ask your provider
- What is the firewall's real VPN throughput and its concurrent user limit, not just its headline throughput?
- Does the remote-access client support multi-factor sign-in with our identity provider?
- Will you configure split or full tunnelling, and why?
- Do our circuits include static IP addresses at the sites that need them?
- How are firmware updates handled, and how fast are urgent security patches applied?
- At what number of sites would you recommend SD-WAN instead of individual tunnels?
Getting it priced around your sites
A VPN is only as good as the circuits under it, and a hub office with a weak upload will drag down every branch and remote user. We qualify each address across several Tier 1 carriers and bring back the best offer, including static IPs where the design needs them. The carrier pays us, so there is no markup, the quote is free, and we usually respond the same day. If your current setup already works and the price is fair, we will say so. Send us your sites, call 478-758-8091 or text (347) 870-0965.
