For years, FortiGate SSL VPN has been one of the most common ways to provide remote access to corporate networks. Thousands of companies got used to a simple model: install FortiClient, authenticate the user and build a tunnel to the company firewall.

But Fortinet is changing direction.

From FortiOS 7.6.3, SSL VPN tunnel mode is no longer available on FortiGate models. Fortinet recommends migrating existing configurations to IPsec VPN before upgrading. On certain entry-level models with 2 GB of memory, the removal of SSL VPN started even earlier.

The question for many companies and MSPs is obvious: if I have to migrate my remote access anyway, does it make sense to swap SSL VPN for another VPN, or is it time to adopt a Zero Trust model?

That is where a third option appears: ConnectaSec.

What exactly happened to FortiGate SSL VPN?

Let us be precise: Fortinet has not abandoned remote access or VPNs. What it removed is SSL VPN in tunnel mode.

Since FortiOS 7.6.3 the feature no longer appears in the GUI or the CLI, and existing SSL VPN tunnel configurations are not preserved on upgrade. Fortinet even publishes specific documentation to migrate from SSL VPN to IPsec VPN.

The vendor''s proposed path is therefore:

SSL VPN → IPsec VPN

It is a perfectly valid migration, and a logical one for organisations that want to keep using the FortiGate as their remote access concentrator. But it raises another question: do we simply want to change VPN protocol, or do we want to rethink how we grant access to our infrastructure?

SSL VPN and IPsec share the same philosophy

SSL VPN and IPsec use different technologies, but conceptually they share an important trait: they connect a remote device to a network.

The user establishes a tunnel into the corporate infrastructure and firewall rules then decide what traffic may flow. This model can be hardened a great deal with MFA, certificates, policies and segmentation.

The problem is not that IPsec is insecure. The problem is that we still start from an access model based on network connectivity.

Zero Trust flips the concept:

The user or device does not need to enter the network. It only needs access to the resources it is explicitly authorised for.

FortiGate IPsec vs ConnectaSec

ConnectaSec is built around exactly that model: a remote access platform based on Zero Trust Network Access (ZTNA), where you define in a granular way which resources each user or device can reach.

For example, a back-office user may need:

ERP: 192.168.10.20:443
SQL: 192.168.10.25:1433

But they have no reason to reach domain controllers, printers, NAS devices, hypervisors, IoT devices or other workstations.

1. Network access vs resource access

With FortiGate SSL VPN / IPsec, the device builds a tunnel to the firewall and policies then limit how far it can go. It is a powerful and flexible model, especially when full network connectivity is required.

With ConnectaSec, by default you have access to nothing. The administrator explicitly decides which resources must be reachable. That dramatically reduces lateral movement if a device is compromised.

2. The firewall stops being the entry point

A traditional VPN needs a service reachable from the internet: the FortiGate has to accept connections from remote users.

ConnectaSec''s architecture is different: connections are established towards ConnectaSec infrastructure, so there is no need to publish the internal service you want to protect. No port opened to the ERP, no RDP published, no self-hosted VPN server exposed for that access.

For many SMBs this is a huge operational difference.

3. The firewall can still be a FortiGate

ConnectaSec does not aim to replace the FortiGate as a firewall. A FortiGate still makes complete sense for perimeter firewalling, IPS, filtering, SD-WAN, inter-VLAN security, traffic inspection, site-to-site connectivity and LAN protection.

What changes is one specific function: user remote access.

Instead of:

User → FortiClient → VPN → FortiGate → LAN

you get:

User → ConnectaSec → authorised resource

FortiGate protects the network. ConnectaSec controls who reaches which remote resource. Both technologies coexist perfectly.

4. Microsegmentation from day one

One of the main risks of any remote access is lateral movement. If a remote laptop is compromised, the attacker will try to discover servers, SMB, RDP, SQL, Active Directory, NAS, hypervisors, printers or network devices.

With a Zero Trust model, the goal is that the compromised machine does not even have a valid route to the resources it does not need.

5. Device security before connecting

Zero Trust should not stop at asking "is this device authorised?", but also "is this device in an acceptable security state to connect?".

ConnectaSec can add endpoint posture checks covering things like Windows patch level, antivirus or EDR status, security policy compliance and device identity. If the device stops meeting the defined conditions, its access can be limited or isolated.

Having access is not enough: you have to keep meeting the security conditions.

6. What if I really need full network access?

Let us be clear: ZTNA does not replace every VPN. There are scenarios where IPsec remains an excellent solution:

site-to-site connectivity between two offices;
permanent communication between two networks;
certain industrial environments;
legacy applications that require full network discovery;
specific routing scenarios.

But when we talk about remote workers, external suppliers, technicians, administrators, ERP access, internal applications, RDP, SQL or specific servers, ZTNA offers a far more granular model.

Quick comparison

Capability	FortiGate SSL VPN	FortiGate IPsec	ConnectaSec ZTNA
Remote access	Yes	Yes	Yes
Available in FortiOS 7.6.3+	Not in tunnel mode	Yes	Yes
VPN tunnel based	Yes	Yes	Not as a traditional VPN
Granular access	Via policies	Via policies	Per resource
Microsegmentation	Configurable	Configurable	Native to the model
Requires FortiGate	Yes	Yes	No
Published VPN service	Yes	Yes	Internal resource does not need publishing
Posture check	Depends on architecture/licensing	Depends on architecture/licensing	Built into the model
Central management	Fortinet	Fortinet	ConnectaSec console
Zero Trust oriented	Partial	Partial	Yes
Site-to-site	Not its focus	Excellent	Not its main goal

This is not about IPsec being worse

It would be a mistake to read the SSL VPN removal as "Fortinet admits VPNs are insecure". That is not what is happening: IPsec is an extremely mature and secure protocol when properly configured.

The point is different. If a company has to spend time migrating hundreds of users because its remote access technology changes, it may be a good moment to ask: do we want to migrate from SSL VPN to IPsec, or do we want to evolve from VPN to Zero Trust? Those are different decisions.

Especially relevant for MSPs

For an MSP the problem multiplies. Managing remote access for 30, 50 or 100 customers can mean maintaining multiple FortiGates, different firmware versions, VPN configurations, certificates, users, policies, MFA and VPN client incidents.

A centralised ZTNA platform lets you manage access from a single control layer. ConnectaSec is designed around a multi-tenant model: users, devices, gateways and permissions from one console. More on that in ZTNA for MSPs.

An opportunity to rethink remote access

Fortinet''s decision will accelerate many migrations over the coming years. Some companies will move straight to IPsec, and that is a perfectly valid decision. Others will use the change to modernise their architecture.

Because maybe the question should no longer be "which VPN do we use?", but "why does this user need to be connected to my network?".

If they only need the ERP, grant the ERP. If they only need RDP to one server, grant that server. If they only need SQL, allow SQL. Nothing more. That is Zero Trust applied to remote access.

FortiGate + ConnectaSec: not necessarily competitors

One of the architectures that makes the most sense is to use both technologies: FortiGate to protect the network and ConnectaSec to control remote access. The firewall keeps doing what it excels at — protecting, segmenting and inspecting — while ConnectaSec applies a Zero Trust layer over remote users and devices.

You do not have to replace the firewall. You have to stop it being the universal entry door for every remote user.

Do you have users connecting through FortiGate SSL VPN?

Before migrating them automatically to IPsec, it may be a good moment to review what they actually need. In many cases, out of 50 VPN users:

20 only need the ERP;
10 need remote desktop;
8 need a SQL application;
7 need a NAS;
and only 5 really need broader network connectivity.

Those first 45 users probably do not need a traditional VPN: they need secure access to specific applications and resources.

Secure remote access. Zero Trust. No traditional VPN. No exposed network. And only what each user actually needs.

More detail on the FortiGate SSL VPN alternative landing page, the VPN vs ZTNA comparison and ConnectaSec vs FortiClient. Check the pricing or request a demo.