FortiClient VPN in Morocco: secure remote work and ZTNA with FortiGate

The short answer: on a recent FortiGate, remote work is secured with FortiClient over IPsec VPN, protected by a FortiToken second factor, and rules that open only the servers each group actually needs. SSL VPN tunnel mode, long the default choice, was removed from FortiOS from version 7.6.3. The free FortiClient VPN client is enough for simple remote access; the FortiClient EMS console becomes necessary as soon as you want to check device posture and move to ZTNA, which opens an application rather than a network.

This guide focuses on the Fortinet ecosystem. For the general choice between IPsec, SSL and ZTNA across vendors, start with Business VPN for remote work: IPsec, SSL or ZTNA?. At ALLSAFE SOLUTIONS, we deploy this kind of access in Casablanca and across Morocco as a Fortinet integrator in Morocco. The technical information below comes from Fortinet’s official documentation.

What changed with FortiOS 7.6.3

The FortiOS 7.6.3 release notes are explicit: SSL VPN tunnel mode is no longer available, in either the GUI or the CLI. Fortinet replaces it with IPsec VPN, which can be configured to use TCP port 443, the HTTPS port that hotel and customer networks rarely block. Two practical consequences:

• Settings are not converted. Fortinet states that SSL VPN tunnel mode configuration is not carried over during the upgrade. You need to build the equivalent IPsec access before upgrading, otherwise remote workers lose access the next morning.
• Web mode changes name and scope. The former SSL VPN web portal is now called “Agentless VPN”. It is not supported on the FortiGate 40F, 60F and 90G series, which are very common in SMBs.

This change is good for security. The FortiOS SSL VPN service has been the subject of several critical vulnerabilities published by Fortinet, some of them exploited on the internet. We cover how to handle these flaws in FortiOS upgrades: managing FortiGate vulnerabilities safely. If your FortiGate has been kept on an older version to preserve SSL VPN, that is a sign a migration to IPsec should be planned, not postponed.

FortiClient editions, without the confusion

The name “FortiClient” covers several products. Fortinet presents them as follows on its download page and in its documentation:

Edition	What it provides	Management	Best for
FortiClient VPN (free)	Basic IPsec and SSL VPN	Device by device, no console	Small team, simple access, no vendor support
FortiClient Standalone	Remote access VPN with MFA, FortiIdentity Cloud Basic subscription, email support	No EMS console	Small organisation wanting a client supported by Fortinet
FortiClient ZTNA Edition	ZTNA application access, continuous device posture checks, enhanced VPN, web filtering	FortiClient EMS console	SMB managing its devices and wanting to check compliance
FortiClient EPP/APT Edition	All of ZTNA, plus antivirus and anti-ransomware protection, removable media control, software inventory	FortiClient EMS console	SMB wanting a single agent for access and endpoint protection

The free version is not a trap: for a few remote workers accessing a file server and a business application, it does the job. Its limits are clear. It does not check whether the device is up to date or protected, it is configured by hand on each machine, and Fortinet does not support it. As the number of devices grows, or as personal computers start connecting, the EMS console changes the picture.

For endpoint protection itself, the EPP/APT edition is only one option among others; we compare approaches in EDR vs antivirus for SMBs.

Building clean IPsec access with FortiClient

A well-designed IPsec VPN rests on a few simple principles, which we apply on every deployment:

1. A dedicated remote access tunnel, separate from the tunnels linking your branches. For site interconnection, see SD-WAN with FortiGate.
2. User groups, not isolated accounts: accounting, sales, management, contractors. Each group gets its own rules.
3. Rules that open only what is needed: the file server and ERP for accounting, not the entire local network. FortiGate security profiles also apply to VPN traffic.
4. TCP port 443 as a fallback, for networks that filter standard IPsec, as Fortinet provides from version 7.6.3.
5. A deliberate choice between full tunnel and split tunnelling, explained in our general VPN guide.
6. Connection logs kept off the appliance, so you know who connected, when and from where.

For the user, FortiClient is configured once, and connecting then comes down to a username, a password and an approval on the phone. With the EMS console, the tunnel configuration is pushed automatically to devices: no more machine-by-machine work.

One more point is often overlooked: the people who will actually use the VPN. A short guide with screenshots, a test session with each group before the switchover, and a clear contact for the first days avoid most support calls. We also agree in advance on what happens when a phone is lost or replaced, since it carries the second factor: who disables the token, who issues a new one, and how the user proves their identity.

MFA with FortiToken: non-negotiable

A VPN protected by a password alone is one of the first entry points for attackers, especially after a phishing campaign. With Fortinet, the second factor naturally means FortiToken:

• FortiToken Mobile, a smartphone app that generates codes or receives a push notification to approve;
• Hardware FortiToken, a key fob, for people without a work smartphone or for shared workstations.

Fortinet documentation states that a FortiGate includes free FortiToken Mobile tokens, the number of which is shown in the console, to be imported once the appliance is registered. We reserve them first for firewall administrator accounts. For users, you buy additional tokens or rely on an authentication method already in place. In a high availability cluster, FortiToken Mobile tokens are registered on the primary unit and synchronised to the second, as explained in FortiGate high availability. For the rollout method with your teams, see MFA rollout guide for SMBs.

ZTNA with FortiGate and FortiClient EMS

A traditional VPN, once connected, puts the device inside the network. Fortinet ZTNA works differently. The FortiGate acts as an access proxy: it publishes a specific application (an intranet, remote desktop, a file share) and serves it only after several checks.

The mechanism, as Fortinet describes it:

1. Devices running licensed FortiClient register with FortiClient EMS, whether in the office or outside.
2. EMS collects device information (logged-on user, operating system, protection) and assigns ZTNA tags based on rules you define.
3. These tags and the client certificate are synchronised in real time with the FortiGate.
4. The FortiGate verifies identity using the certificate and allows or denies access based on the tags. A device tagged as compromised is blocked, even with a valid password.

The benefit for an SMB is twofold. Users only see the applications they are entitled to, and a non-compliant personal computer reaches nothing. It is one of the workstreams described in Zero Trust for SMBs: where to start.

ZTNA does have prerequisites: inventoried and managed devices, an EMS console, FortiClient licences, and a clear list of applications to publish. It is not a starting point, it is the logical next step after a well-run IPsec VPN.

IPsec VPN, VPN with EMS or ZTNA: which to choose?

Situation	Our recommendation
A few remote workers, company devices, access to a file server	Free FortiClient VPN over IPsec, with FortiToken
Dozens of devices to configure and monitor	Licensed FortiClient with EMS console, configuration pushed remotely
Personal computers or external contractors	ZTNA, or access limited to a single application
Internal web applications, remote desktop	ZTNA with the FortiGate as access proxy
IP telephony, older business software	IPsec VPN, alongside ZTNA if needed
FortiGate still on SSL VPN tunnel mode	Migrate to IPsec before any upgrade to 7.6.3 or later

Mistakes we fix

1. SSL VPN kept “because it works”, on a FortiOS version never updated so as not to break anything. That is exactly the configuration attacks target.
2. An upgrade started without prior migration: tunnel mode disappears and remote workers are locked out.
3. No second factor, or MFA enabled for management only.
4. A VPN rule to “the whole network”, when each group only needs two or three servers.
5. VPN accounts of former employees still active, for lack of a leaver procedure.
6. FortiClient installed on personal computers without any check of their state.
7. Connection logs kept only on the firewall, lost in an incident.

SSL VPN to IPsec migration checklist

• Record the FortiOS version, the FortiGate model and the number of active VPN users.
• List the groups, authorised resources and authentication methods of the current SSL VPN.
• Build the remote access IPsec tunnel, with MFA and per-group rules, alongside the existing setup.
• Test with a pilot group, including from a 4G network and a hotel network, using TCP port 443 if needed.
• Update FortiClient on devices and share a simple user guide.
• Switch all users over, then disable SSL VPN.
• Then plan the FortiOS upgrade, following Fortinet’s upgrade path.

How we work

We start with a free initial audit of your remote access: FortiOS version, VPN mode in use, active accounts, MFA, rules and logs. We then propose the right target, from a simple IPsec VPN with FortiToken up to ZTNA with FortiClient EMS, and we supply the licences and tokens you need, with or without installation. Migration runs alongside the existing setup, group by group, without cutting off remote workers. Once in production, the FortiGate and connections are monitored 24/7, and critical incidents are handled in under 15 minutes.

Discover our approach to cybersecurity in Morocco, see our partner statuses on the Certifications page, then request your free initial audit: we reply within 24 business hours.