Business VPN for remote work: IPsec, SSL or ZTNA?

Your staff work from home, on the road or from a branch, and they need the file server, the accounting software or the ERP hosted at head office. The usual answer is “let’s install a VPN”. But that word covers very different technologies, and a badly configured VPN is one of attackers’ favourite ways in. The short answer: for most SMBs, an IPsec VPN with mandatory MFA, run by the firewall and segmented by user group, is the right foundation today, and ZTNA is the next step once devices are managed. Here is how to choose, configure and avoid the mistakes we see most often.

Site-to-site or remote access: two different needs

Before talking protocols, separate two uses.

• A site-to-site VPN permanently links two networks, between two firewalls. A branch in Tangier sees the servers at head office in Casablanca as if they were in the same building. Nobody has to launch anything: the tunnel is always up. With several sites, these tunnels are often organised as SD-WAN, which adds management of multiple internet links.
• A remote access VPN links a single device to the company network. The remote worker launches a client on their computer, authenticates and reaches the authorised resources.

Both run on the same firewall but are not configured with the same rules. This article focuses on the second, the more exposed one: it opens a portal visible from the internet and depends on human credentials.

IPsec, SSL or ZTNA: the comparison

Criterion	IPsec VPN (IKEv2)	SSL VPN	ZTNA
Principle	Standard encrypted tunnel between device and firewall	Encrypted tunnel over the HTTPS port	Access to a specific application, not the network
What the user sees	The networks allowed by the rules	The networks allowed by the rules	Only the authorised applications
Device checks	Possible, depending on the solution	Possible, depending on the solution	Core to the model: posture checked at each access
Works on filtered networks (hotels, clients)	Good with IKEv2 and NAT traversal, sometimes blocked	Very good, gets through almost anywhere	Good, relies on HTTPS
Surface exposed to the internet	IKE service	Web portal, historically heavily targeted	Application access point
Prerequisites	Firewall and VPN client	Firewall and VPN client	Managed devices, application inventory, licences
For whom	The default foundation for SMBs	Fallback and special cases	SMBs ready for the next Zero Trust step

IPsec: the default choice

IPsec is an open standard, supported by every firewall and operating system. In its IKEv2 version it reconnects well after a network change, from WiFi to 4G for instance, and performs well. It is also the direction vendors are taking: Fortinet is steering remote access toward IPsec on recent FortiOS versions. Before designing or changing your setup, check the version installed on your FortiGate and what it actually supports.

SSL: convenient, but worth reconsidering

SSL VPN was long popular because it runs over the HTTPS port, which is rarely blocked. On the other hand, several vendors’ SSL VPN portals have been hit by many critical vulnerabilities in recent years, exploited quickly after disclosure. If you still use it, it must be kept up to date at all times, protected by MFA, and its web portal disabled if unused.

ZTNA: access to an application, not the network

Once connected, a traditional VPN opens entire networks. ZTNA (Zero Trust Network Access) reverses the logic: the user reaches only the requested application, after their identity and their device’s posture (system up to date, antivirus running, disk encrypted) are checked. We explain how it fits into a broader approach in Zero Trust for SMBs: where to start. ZTNA requires managed devices and a clean application inventory: it is not a starting point but an outcome.

VPN clients: FortiClient and WatchGuard Mobile VPN

On a FortiGate, the client is FortiClient. The free, VPN-only version is enough for simple remote access; the console-managed version adds device posture checks and opens the door to ZTNA. On a WatchGuard Firebox, Mobile VPN with IKEv2 uses the native Windows and macOS client or the WatchGuard client, and Mobile VPN with SSL remains available for special cases. In both cases a second factor is easy to add: FortiToken with Fortinet, AuthPoint with WatchGuard, or your existing identity provider such as Microsoft Entra ID. To compare the two ranges, see FortiGate or WatchGuard for an SMB and our Fortinet and WatchGuard pages.

Split tunnelling or full tunnel?

A full tunnel sends all the device’s traffic through the company, web browsing included: the firewall filters everything, but the head office link carries the traffic of every remote worker, video calls included. Split tunnelling sends only traffic bound for company networks through the VPN; the rest goes straight out through the home connection.

Our recommendation depends on how well the device itself is protected. If computers have an EDR and web filtering that works outside the office, split tunnelling is reasonable and relieves head office; otherwise, a full tunnel keeps browsing under the firewall’s control. Either way, Microsoft 365 and video calls benefit from going out directly, so call quality does not suffer. On the difference between antivirus and EDR, see EDR or antivirus for an SMB.

Our method, step by step

1. Inventory the needs: who works remotely, from which devices, and to reach what exactly.
2. Create access groups: accounting, sales, management, contractors. Each group opens only the servers and ports it needs.
3. Choose the protocol: IPsec IKEv2 by default, SSL only if a specific need justifies it.
4. Connect authentication to the company directory, so that a departure also disables VPN access, and enforce MFA for everyone, with no exceptions. Our MFA rollout guide details the method.
5. Decide the tunnel mode based on device protection.
6. Harden the firewall: firmware up to date, admin interface closed to the internet, login attempt limits, as in the 10 FortiGate security settings.
7. Monitor: alerts on logins from unusual countries, repeated failures and inactive accounts.

The most common mistakes

• A VPN without MFA: a password stolen by phishing is enough to get in.
• “Whole network” access for every user, contractors included, instead of per-group rules.
• Local VPN accounts created on the firewall and never removed when staff leave.
• Outdated firmware while critical patches concern the VPN itself.
• The SSL web portal left on although nobody uses it.
• A contractor permanently connected instead of on-demand access limited to their server.
• Logs never reviewed: nobody notices a 3 a.m. login from another continent.

Remote work VPN checklist

• MFA enabled on every VPN account, with no exceptions.
• IPsec IKEv2 preferred, firmware version checked and current.
• Authentication tied to the directory, no orphaned local accounts.
• Per-group access rules, limited to the servers and ports required.
• SSL portal disabled if unused.
• Tunnel mode chosen according to device protection.
• Contractor access opened on demand and logged.
• Alerts on unusual logins and regular account reviews.

How we do it

We start with a review of your remote access: protocol, firmware version, existing accounts, rules, MFA and logs. We then propose a target configuration, IPsec with MFA and per-group rules, and migrate users in waves without cutting off anyone who is working. The firewalls we manage are under 24/7 monitoring, and a critical incident is handled in under 15 minutes. When devices are ready, we support the gradual move to ZTNA. This work is part of our business cybersecurity offering, and our case studies show comparable deployments.

Take action

Not sure whether your VPN is protected by MFA, or which version runs on your firewall? That is exactly what the initial audit covers, free of charge. Contact us: we reply within 24 business hours.