IPsec VPN vs ZTNA: which path makes sense for your migration

Fortinet removed SSL VPN tunnel mode from FortiOS 7.6.3. Thousands of organisations now face a forced migration, and the choice between IPsec and Zero Trust Network Access will shape their security posture for years. This guide breaks down the technical differences, operational trade-offs, and compliance implications to help you make the right call.

Quick decision framework: IPsec vs ZTNA

When to choose IPsec:

1. You need full network-level access for legacy applications that cannot be published individually
2. Your infrastructure is entirely on-premises with no cloud components
3. You have dedicated network engineers who can manage complex dial-up profiles and Peer ID configurations
4. Your users only connect from controlled environments where UDP ports 500 and 4500 are always open

When to choose ZTNA:

1. You need application-specific access with least privilege enforcement
2. Your users work from hotels, airports, and public wifi where UDP ports are blocked
3. You want to reduce the attack surface by hiding infrastructure from internet scanners
4. NIS2 compliance requires you to demonstrate granular access controls and segmentation

Why this migration matters now

The deprecation of SSL VPN is not arbitrary. SSL libraries have accumulated security vulnerabilities over time, making it increasingly difficult for vendors to guarantee integrity. For devices with limited memory (2 GB RAM), Fortinet has removed proxy-related functions entirely, which affects scalability for small and mid-market deployments.

The timing coincides with NIS2 enforcement in Belgium and across Europe. The directive requires essential and important entities to implement proportionate technical measures for network security. Maintaining broad network access through a traditional VPN is increasingly viewed as a failure to meet the board’s duty of care.

The hidden problem with IPsec: TCP meltdown

Before comparing IPsec and ZTNA on features, you need to understand a fundamental performance issue that affects both SSL VPN and IPsec when running over TCP.

When organisations deploy IPsec over TCP port 443 to bypass firewall restrictions, they create a TCP-over-TCP tunnel. The outer TCP connection handles the VPN encryption. The inner TCP connection carries the actual application traffic. Both layers have their own congestion control and retransmission logic.

When packet loss occurs on an unstable connection (hotel wifi, saturated 4G), both TCP layers detect the problem simultaneously. The outer tunnel attempts retransmission. Before that completes, the inner application layer times out and triggers its own retransmission. The result is an exponential increase in traffic on an already congested link.

This cascade effect, sometimes called the “doom loop”, causes connections to freeze or drop entirely. Users experience this as inexplicable slowdowns that resolve only after reconnecting.

ZTNA solutions built on WireGuard avoid this entirely by using UDP at the transport layer. UDP does not perform retransmission, leaving error correction to the application layer where it belongs. The result is stable performance even on challenging networks.

IPsec migration: operational challenges

For IT teams accustomed to SSL VPN’s web-based portals and flexible user groups, IPsec introduces significant configuration overhead.

User grouping complexity

SSL VPN allowed straightforward assignment of users to portals and access groups. IPsec requires dial-up profiles with specific Peer IDs and IP ranges. Segmenting users effectively means maintaining parallel configuration structures that drift over time.

Active Directory integration limitations

FSSO (Fortinet Single Sign-On) integration with IPsec has known issues. Sessions can drop when AD logon events are incorrectly mapped to IPsec IP addresses. Teams report spending hours troubleshooting authentication failures that worked fine under SSL VPN.

Public network access

This is the most persistent operational issue. Hotels, airports, and corporate guest networks typically allow only HTTP and HTTPS traffic on ports 80 and 443. The UDP ports required for IPsec (500 and 4500) are blocked by default.

Fortinet offers IPsec over TCP as a workaround, but this requires a paid EMS license and reintroduces the TCP meltdown problem described above. For organisations without budget for additional licensing, this means reduced mobility for remote workers.

ZTNA: application-level access by design

The shift to ZTNA represents a different security model entirely. Instead of creating a tunnel to the network and then applying access controls, ZTNA grants access to specific applications only after verifying identity and device posture.

Eliminating lateral movement

Traditional VPNs operate on implicit trust. Once connected, users can often reach any system on the network segment. This is exactly how ransomware spreads after initial compromise. A user with access to email should not automatically have a path to the ERP database or industrial control systems.

ZTNA enforces explicit access per application. A finance team member can reach the accounting application but nothing else. If their credentials are compromised, the attacker gains access to one application, not the entire network.

Device posture as a gate

ZTNA solutions check device state before granting access. OS version, disk encryption, screen lock, endpoint protection. A device that fails posture requirements gets denied or receives limited access until remediated.

This addresses a gap that VPNs cannot fill. A personal laptop with outdated patches connecting via VPN has the same network access as a fully managed corporate device.

Stealth mode and reduced attack surface

VPN concentrators are visible on the internet. Attackers scan for them continuously, looking for vulnerable firmware or weak configurations. ZTNA architectures can hide infrastructure entirely, presenting no open ports for reconnaissance.

Securing devices without agents

Not every device can run a ZTNA agent. Printers, scanners, medical equipment, and industrial controllers often run legacy operating systems that cannot support modern software. These agentless devices become blind spots in any security architecture.

A Network Isolation Access Controller (NIAC) provides hardware-level isolation for these devices. Instead of placing a printer on the same network segment as workstations, the NIAC creates a controlled boundary. The printer can reach only the print server. Nothing else can reach the printer.

This approach is particularly valuable for IT-OT integration. Industrial PLCs and SCADA systems rarely support agents, yet they increasingly need connectivity to IT networks for monitoring and maintenance. Inline isolation allows controlled access without exposing production systems to lateral movement risks.

NIS2 and CyFun compliance implications

The CyberFundamentals (CyFun) framework developed by the Belgian Centre for Cybersecurity translates NIS2 requirements into practical controls. For external access, the relevant controls (AC-3.2, PR.AC-3, PR.AC-4) explicitly require:

• Multi-factor authentication for remote access
• Strong encryption standards (WPA-3, AES)
• Granular access control based on least privilege

A traditional VPN that grants broad network access after authentication does not meet the least privilege requirement. Auditors will ask how you prevent a compromised account from accessing systems beyond its role. With VPN, the honest answer is “we cannot.”

ZTNA provides the evidence trail auditors expect. Each access request is logged with identity, device, application, and posture status. Policy changes are versioned with approvers and timestamps. Access scope is demonstrably limited to what each role requires.

Essential entities under NIS2 must achieve CyFun certification by April 2026. The gap between VPN architectures and compliance requirements is closing rapidly.

Total cost of ownership comparison

License cost per user is the wrong metric for this comparison. The real cost difference emerges in operational overhead and risk exposure.

VPN management burden

IT teams report spending 15 to 20 hours monthly on VPN-related tasks: configuring new users, patching hardware appliances, troubleshooting connectivity issues. At typical internal rates, this adds up to substantial annual cost before counting productivity loss from slow or dropped connections.

ZTNA operational model

Cloud-native ZTNA eliminates hardware patching. User onboarding happens through a central dashboard rather than per-device configuration. Posture enforcement is automatic rather than manual. Teams report management time dropping to 3 to 5 hours monthly.

How Jimber enables this migration

Jimber delivers ZTNA within a unified SASE platform. Zero Trust Network Access provides granular per-application access with identity and device context. The Secure Web Gateway and Firewall-as-a-Service ensure consistent web controls. SD-WAN delivers resilient site-to-site connectivity.

For agentless devices, Jimber’s NIAC hardware creates an IT-OT bridge without requiring software installation on legacy equipment. Industrial controllers and printers get isolated access paths rather than flat network membership.

The platform uses WireGuard-based tunnels running on UDP, eliminating TCP meltdown issues entirely. Users experience consistent performance whether connecting from the office, home, or a hotel with restrictive wifi.

Single console management means one place for policies, logging, and compliance reporting. MSPs can operate multi-tenant environments with standardised templates. Evidence exports support NIS2 audits without scrambling to compile documentation.

Practical migration approach

Phase 1: Inventory and planning

Map all applications currently accessed via SSL VPN. Identify data sensitivity, user groups, and device requirements for each. Flag agentless devices that need NIAC rather than agent-based access.

Phase 2: Parallel deployment

Deploy ZTNA for 2 to 3 low-risk applications first. Run alongside existing VPN while measuring user experience and access logs.

Phase 3: Expand and enforce

Add business-critical applications. Enable device posture checks. Move agentless devices behind inline isolation.

Phase 4: VPN decommission

Once application coverage reaches 80 percent and support ticket volume stabilises, disable SSL VPN access for migrated applications. Maintain a documented exception process for edge cases.

FAQ

Is IPsec ever the right choice?

For purely on-premises environments with dedicated network staff and no public network access requirements, IPsec can work. But the operational overhead and public wifi limitations make it a poor fit for most mid-market organisations.

What about users who need full network access?

Audit whether they actually need full network access or whether that is simply how VPN was configured. Most users need access to 3 to 5 applications. ZTNA makes explicit what VPN left implicit.

How does ZTNA handle legacy applications?

Applications that cannot be published directly can be accessed through a secure application proxy. The user authenticates to the proxy, which then establishes the connection to the legacy system.

Does ZTNA require an agent on every device?

Agents provide the best posture visibility and user experience. For devices that cannot run agents, NIAC hardware provides inline isolation with controlled access paths.

What is the timeline for NIS2 compliance?

Essential entities must achieve CyFun certification by 18 April 2026. Important entities follow shortly after. Access control architecture is a core audit area.

Ready to plan your migration from VPN to ZTNA? Book a demo and see how Jimber makes the transition straightforward for your team.