How to set up a business VPN for remote workers

Your team is going remote, or you finally have enough people working from home that the old “everyone connects to the office” model has stopped working. You need a VPN. The internet has a hundred guides that assume you know what you are doing, or try to sell you a specific product before explaining why you need one. This is the practical version.

This guide walks through the decisions that matter when you are standing up a business VPN: which kind of VPN, on what hardware, with which options, and how to actually configure the client side so employees are productive on day one. It also covers the parts most guides skip, like split tunneling, user account management, and when a VPN is the wrong answer. If users are complaining the VPN feels slow, the cause is usually further upstream than the tunnel itself – see why your small business network is slow and how to fix it for the diagnosis order.

Before we start: if you are picking between a traditional VPN and zero trust network access (ZTNA), read that comparison first. For many modern SMBs, ZTNA is the better direction. The rest of this guide assumes you have already decided a VPN is the right fit for your situation. The VPN configuration sits on the office firewall, so the broader firewall deployment context is covered in how to set up a business firewall for a small office – this article focuses on the VPN configuration itself.

What a business VPN actually does

A business VPN creates an encrypted tunnel between a remote device and your office network (or a cloud-hosted server that acts as your network gateway). Once the tunnel is up, the remote device behaves as if it were plugged into a network port in the office. It gets an IP address from your network, can reach internal servers and file shares, and sees your internal DNS.

This solves two things at once:

• Access to internal resources. The employee can reach the file server, the accounting system, the on-prem ERP, the QuickBooks server – anything that lives on the office network and does not have a public address.
• Encrypted traffic. Whatever the employee sends through the tunnel is encrypted between their device and the VPN endpoint, which matters on untrusted networks like coffee shops or hotel Wi-Fi.

What a VPN does not do: protect against phishing, stop malware on the device, enforce device compliance, or provide identity-based access controls. Those are different problems with different solutions.

The two VPN types every SMB should know

Remote access VPN

The setup most small businesses need. Individual employees install a VPN client on their laptop or phone, authenticate, and connect to the office network on demand. Each user gets their own account.

Use cases: remote workers, traveling sales, occasional work-from-home, contractors who need access to internal tools.

Site-to-site VPN

A tunnel between two networks. The office network and a branch office, or the office network and a cloud environment, connect permanently so resources on both sides can talk to each other as if they were on the same LAN.

Use cases: multi-office businesses, hybrid cloud setups, extending on-prem networks to AWS or Azure. The depth on connecting offices to each other – including when site-to-site VPN is still the right tool vs when SD-WAN or another option fits the multi-site case better – is in how to network multiple office locations for a small business.

For this guide, the focus is remote access VPN, because that is what “VPN for remote workers” almost always means.

Hardware VPN vs software VPN

Hardware VPN appliance

A physical box in your office (or a cloud VM acting as one) that terminates VPN connections. Common names: Fortinet FortiGate, SonicWall, Cisco Meraki MX, WatchGuard, Sophos XGS.

Strengths:

• Integrated firewall, routing, and VPN in one device
• Good performance for small-to-medium concurrent user counts
• One vendor for network edge and remote access
• Support contracts cover firmware updates and security patches
• Hardware usually sized for the office network anyway, so VPN is “free” in incremental cost

Weaknesses:

• Capital expense and multi-year hardware commitment
• Requires someone who knows how to configure it, which is usually a networking specialist
• Office-dependent: if the office internet goes down, remote VPN goes with it
• Scaling means buying a bigger box

Software VPN / cloud VPN

Software you install on a server (cloud or on-prem), or a SaaS VPN product that you subscribe to.

Open-source options: OpenVPN Access Server, WireGuard (increasingly popular for modern setups).

SaaS options: NordLayer, Perimeter 81 (now Check Point Harmony SASE), Tailscale (technically ZTNA-like), OpenVPN Cloud.

Strengths:

• No hardware to buy or maintain
• Scales by subscription tier, not hardware replacement
• Independent of your office internet – can host VPN endpoints in the cloud
• Modern options have clean admin consoles and low setup friction
• Often cheaper for small teams than a hardware appliance

Weaknesses:

• Subscription cost over time can exceed a one-time hardware purchase for stable long-term workloads
• For small teams, self-hosting OpenVPN or WireGuard requires ongoing maintenance
• SaaS VPNs route traffic through their infrastructure, which adds a dependency

Which to pick

For most SMBs today, a SaaS VPN is the practical default. The setup time is shorter, the ongoing maintenance is less, and the feature sets (MFA, per-user policies, logging) are better aligned with modern security expectations than a decade-old hardware appliance.

Hardware VPNs still make sense if:

• You already have a managed firewall that includes VPN as a feature (Meraki, FortiGate)
• You have heavy on-prem infrastructure and want a single network edge
• Your business has specific compliance requirements that favor on-prem termination

Planning before you configure anything

The VPN is not where the work starts. Before clicking “new VPN,” decide:

Who needs access, and to what

List the users. List the resources they need to reach. Resist the urge to give everyone access to everything – you want to at least restrict by group. Sales may need the CRM and file shares; engineering may need different servers; accounting needs QuickBooks and nothing else.

This information drives the network segmentation you will configure, and it drives the access policies you will apply per user group.

Authentication approach

At minimum, username and password. Better: username + password + MFA. Best: integration with your identity provider (Entra/Azure AD, Okta, Google Workspace) so VPN login is tied to the same account as Microsoft 365, with the same password policy, the same MFA, and the same disable-on-offboarding flow.

If you set up a VPN with local accounts that are separate from your identity provider, you will regret it. Every offboarding becomes “remember to disable the VPN account too,” and most businesses forget half the time.

IP addressing plan

The VPN will hand out IP addresses to connected clients. These need to be from a separate subnet than your office LAN, to avoid routing confusion. Pick a range that does not overlap with anything else in your network, and document it.

For example, if the office LAN is 192.168.1.0/24, you might use 10.10.10.0/24 for VPN clients.

DNS strategy

When connected, should VPN clients use your internal DNS server (so they can resolve internal hostnames)? Almost always yes, for the resources on the VPN side. But you may want to keep external lookups going through the client’s normal DNS to avoid the VPN becoming a DNS bottleneck.

Logging and audit

What activity should be logged? At minimum, connection events (who connected, when, from where, how long). For compliance-heavy environments, also traffic logs (though full packet capture gets expensive fast). Decide where logs go and how long you keep them.

Step-by-step setup (generic)

The exact steps depend on the product, but the sequence is the same across hardware and software VPNs.

Step 1: Deploy or provision the VPN server/appliance

For hardware: physically install the appliance, configure the WAN interface, configure the LAN interface, apply firmware updates.

For cloud/software: spin up the VM or the SaaS tenant, connect it to your identity provider, set the region/location.

Step 2: Configure the VPN protocol

Pick the protocol your clients will use. The practical choices in 2026:

• WireGuard. Modern, fast, simple. The right default for new deployments if your product supports it.
• OpenVPN. Mature, well-tested, works everywhere. Slower and more CPU-intensive than WireGuard but more battle-tested for enterprise use.
• IKEv2/IPsec. Built into Windows, macOS, iOS, and Android natively. Good for “no client install” scenarios.
• L2TP/IPsec. Older, still works, not recommended for new deployments.
• PPTP. Do not use. It is deprecated and insecure.
• SSL VPN (proprietary). Common on hardware appliances (Cisco AnyConnect, FortiClient). Works fine if you are already in that ecosystem.

Step 3: Configure authentication

Integrate with your identity provider. For most SMBs, this means either:

• RADIUS pointed at Microsoft Entra (via Azure AD Application Proxy or NPS extension), Okta, or your on-prem Active Directory.
• SAML with the identity provider acting as the SAML IdP.
• Native directory sync if the VPN product has a built-in connector for Entra/Okta/Google Workspace.

Enable MFA. This is not optional. Username and password alone is not sufficient authentication for remote access to your network.

Step 4: Configure the IP pool and routing

Assign the IP range you planned for VPN clients. Configure routes so VPN clients can reach the internal subnets they need – and only those subnets. If Sales only needs to reach the CRM server and file shares, do not route them to the server subnet where your domain controllers live.

Step 5: Configure access policies

Set up user groups, map identity provider groups to VPN groups, and apply access rules per group. This is where the “who needs access to what” work from earlier pays off.

Step 6: Set up split tunneling

Configure what traffic goes through the VPN tunnel and what goes directly to the internet from the client’s local connection.

Full tunnel: All traffic from the client goes through the VPN. Everything the user does on the internet routes through your office/VPN endpoint, then out to the internet. Adds latency, consumes office bandwidth, but gives you visibility into all user traffic.

Split tunnel: Only traffic destined for your internal network goes through the VPN. Everything else (Microsoft 365, web browsing, Zoom, SaaS apps) goes directly to the internet from the client. Fast, low overhead, but you lose visibility into non-internal traffic.

For most SMBs, split tunnel is the right choice. Microsoft specifically recommends excluding Microsoft 365 endpoints from the VPN tunnel because their service is designed to be accessed directly from the user’s local network, and full-tunneling it breaks optimizations like Teams audio/video routing.

There is a middle ground – split tunnel with DNS filtering applied to the split-out traffic via a cloud-delivered security service (Umbrella, Cloudflare Gateway) – which gives you both performance and visibility.

Step 7: Firewall rules

The VPN gives clients access to the network. Firewall rules decide what they can actually reach. Apply the principle of least privilege: allow what groups need, deny everything else. Default-deny is safer than default-allow, even if it takes more configuration.

Step 8: Logging

Enable connection and authentication logs. Send them somewhere you can actually look at them (SIEM, the identity provider’s log stream, or at minimum a log retention point within the VPN product itself). VPN logs are useful forensic data when something goes wrong.

Step 9: Test with one user

Do not roll out to the whole team on day one. Test with one technically comfortable user from outside the office – ideally on a home network and a coffee shop network, on both Wi-Fi and cellular. Verify connection, authentication, access to intended resources, and that excluded resources are correctly blocked.

Step 10: Write the user documentation

Before rolling out to the team, write the instructions they will follow. Installing the client, signing in, what to do if MFA fails, who to contact for help. A one-page document with screenshots is enough for most users and saves an enormous amount of time on support.

Client setup on Windows

Most Windows VPN clients follow the same pattern:

1. Download the VPN client installer from your VPN product’s admin portal or vendor site
2. Run the installer (administrator rights required for most)
3. Launch the client and enter the connection details (server address, typically pre-configured if using an MDM deployment)
4. Sign in with the user’s identity provider credentials
5. Complete MFA
6. Connect

For businesses using Microsoft Intune, the cleaner approach is to deploy the VPN client as a required application and push the connection configuration via policy. The user never has to enter server addresses – it is pre-filled when the app installs.

For Windows’ built-in VPN (useful if you picked IKEv2/IPsec), the configuration lives in Settings > Network & Internet > VPN. You can script the creation with PowerShell for consistent deployment, or push it via Group Policy or Intune.

Client setup on Mac

macOS has native support for IKEv2/IPsec, L2TP/IPsec, and Cisco IPsec. For these, configure in System Settings > Network > VPN. A configuration profile (.mobileconfig) can pre-configure the connection for distribution to users – useful for MDM-deployed setups.

For third-party VPN clients (OpenVPN, WireGuard, or vendor clients like FortiClient or NordLayer), install the client from the vendor site or Mac App Store, import the configuration file, authenticate, connect.

For Apple fleets managed through Intune, Jamf, or Apple Business Manager, deploy the configuration profile centrally so users do not touch network settings manually.

Client setup on mobile

iOS and Android both have native VPN support and a broad ecosystem of VPN client apps. Most business VPN products ship iOS and Android apps that handle the configuration through an enrollment flow.

For mobile device fleets managed via Intune or similar MDM, push the VPN configuration to enrolled devices so they are connection-ready the first time the user opens the app.

Per-app VPN is a useful option on mobile – the VPN only activates when specific apps (the internal ticketing app, the line-of-business application) are in use, not for everything on the phone. This reduces battery drain and preserves performance for everything else.

Managing VPN user accounts

Accounts live in the identity provider, ideally, not as local accounts on the VPN appliance. When you set the VPN up with RADIUS or SAML integration, the user management story becomes: add user to the correct group in Entra/Okta, user automatically gets VPN access with the right permissions.

Offboarding becomes: disable the user in Entra/Okta, access is revoked automatically. No separate “also remember to disable the VPN account” step.

If you end up with local accounts on the VPN, they need to be manually provisioned and deprovisioned. This is how terminated employees end up retaining VPN access for weeks after leaving. The fix is to include VPN in the offboarding checklist, and better yet, to remove the local account problem by integrating with your identity provider in the first place.

Common VPN setup mistakes

• No MFA. Username and password alone is not sufficient for remote network access. Every VPN sign-in should require MFA.
• Full tunnel by default. Forces every packet through your office, slows everything down, breaks Microsoft 365 optimizations, and rarely provides security benefit proportional to the cost.
• Flat network on the VPN side. VPN clients can reach everything the LAN can reach, with no segmentation. Compromise one VPN user and you have compromised access to the entire network.
• Local VPN accounts. Separate from the identity provider, separately provisioned, separately disabled – and often missed during offboarding.
• No documentation for users. Employees try to set it up themselves, get confused, call IT, generate a wave of repetitive tickets.
• No monitoring. VPN connections are logged but nobody looks at the logs until an incident. Set alerts for failed authentications and unusual connection patterns.
• Outdated VPN firmware. VPN appliances have been a recurring target for zero-day exploits. Fortinet, Citrix, and Pulse Secure have all had VPN vulnerabilities actively exploited by ransomware groups in recent years. Patch promptly and subscribe to vendor security advisories.
• Assuming VPN is enough. VPN solves network access. It does not solve identity theft, phishing, device compromise, or MFA bypass attacks. Treat VPN as one layer in a broader security posture, not as the whole answer.

When to bring in managed support

Small VPN deployments (under 10 users, one office, simple access needs) are within reach of a technical founder or an IT generalist to set up and maintain. Past that threshold, the operational load grows faster than most SMBs expect:

• Patching the VPN appliance when vulnerabilities are disclosed (often urgent – zero days in VPN gear are actively weaponized within days)
• Managing user groups, access policies, and integration with the identity provider as the team grows
• Troubleshooting connection issues from users on various residential connections
• Reviewing logs for unusual activity
• Planning scale (bigger hardware, more licenses, migrating to cloud)

Managed IT services typically handle the VPN as part of broader network management. For SMBs who do not want to become VPN experts, this is a reasonable division of labor: the business focuses on its product; the managed provider runs the VPN, keeps it patched, monitors it, and handles user changes.

For specific scenarios that warrant calling in help sooner:

• Compliance requirements (HIPAA, PCI, SOC 2) that require specific VPN configurations and logging
• Integration with complex identity setups (multiple identity providers, federation, conditional access)
• Performance problems as the team scales
• Planning a migration to ZTNA

How this fits into your remote access strategy

A VPN is one piece of supporting a remote workforce, not the whole picture. Even a well-configured VPN needs to sit inside a broader architecture that includes MFA everywhere, device compliance enforcement, endpoint security, patch management, and identity-based access controls.

For many SMBs, the VPN is a bridge – a workable solution right now that will eventually be replaced by ZTNA or a SASE platform as the team grows and the access model shifts toward identity-first. That is fine. A VPN today is better than no remote access strategy today. Just plan for the migration before the current setup becomes a bottleneck.

How Sequentur handles VPN setup and ongoing management

For clients on our managed IT support for remote and hybrid teams with a need for remote access, we handle the full lifecycle: assessing whether a VPN or ZTNA is the right fit, configuring the chosen solution against the client’s identity provider and device management, deploying clients via MDM, configuring access policies, monitoring for anomalies, and keeping the VPN gear patched as vulnerabilities emerge.

In practice, this means new hires get VPN access automatically when they are added to the right identity group, departing employees lose access automatically when disabled, and the business does not have to track which appliance needs a firmware update this month. The operational burden moves off the client and onto the provider.

If you are setting up a VPN from scratch or inherited one that has become a source of friction, schedule a call and we will walk through the options.