FortiOS 7.6.3 removed SSL VPN tunnel mode from every FortiGate model. Fortinet points administrators toward IPsec. But many are looking beyond that default, weighing WireGuard for its speed or Fortinet ZTNA for its access controls.
The problem is that both options inside the Fortinet ecosystem come with significant trade-offs. WireGuard isn’t natively supported on FortiGate. Fortinet ZTNA requires a multi-component setup that many mid-market teams struggle to manage. A third path, one that combines WireGuard tunnelling with Zero Trust access controls in a single platform, avoids those trade-offs entirely.
This comparison puts all three options side by side so you can make an informed decision.
Three approaches compared at a glance
| WireGuard (with FortiGate) | Fortinet ZTNA | Jimber SASE | |
|---|---|---|---|
| Native FortiOS support | No. Requires separate server | Yes, FortiOS 7.0+ | Independent platform |
| Tunnel protocol | WireGuard (UDP) | HTTPS reverse proxy | WireGuard (UDP + stealth HTTPS) |
| Access model | Network-level | Application-level | Application-level |
| Required components | WireGuard server, VIP, port forwarding | FortiGate + FortiClient EMS + FortiClient agent | Cloud console + lightweight agent or browser |
| Device posture checks | None | Yes, via EMS tagging | Yes, built-in |
| SSO / MFA integration | Manual or third-party | FortiClient + EMS certificates | Native (Microsoft, Google, standard IdPs) |
| Agentless device support | None | Limited (web mode only) | Yes (browser-based isolation) |
| Multi-site management | None | Complex Fabric setup | Single cloud console |
| MSP / multi-tenant | No | Complex | Built-in |
| Fortinet licence dependency | None | FortiClient EMS licence | None |
Why FortiGate administrators are searching for WireGuard
The appeal is straightforward. WireGuard’s codebase is roughly 4,000 lines compared to hundreds of thousands in IPsec. It uses modern cryptography (ChaCha20-Poly1305, Curve25519), reconnects instantly when users switch networks, and consistently outperforms both IPsec and the now-deprecated SSL VPN in throughput tests.
The Fortinet community has requested native WireGuard integration since 2021, with threads still drawing comments into late 2025. Fortinet has not added it. The likely reason is commercial: native WireGuard would reduce dependence on FortiClient licensing and the broader Fabric ecosystem.
For administrators, this means WireGuard on FortiGate remains a workaround, not a supported feature.
How WireGuard actually works with a FortiGate
There is no WireGuard toggle in the FortiGate GUI. You need a separate WireGuard server (typically a Linux VM) behind the FortiGate with port forwarding to pass UDP 51820 traffic through. The setup involves creating a Virtual IP, configuring firewall policies, adjusting application control so FortiGuard doesn’t block WireGuard (it identifies and blocks it by default), and managing routing.
This works in production. But you get no Fortinet TAC support, no integration with FortiGuard threat intelligence, no built-in MFA or device posture checks, and no centralised management. For organisations with NIS2 compliance obligations, these gaps are difficult to justify during an audit.
How Jimber handles this differently: Jimber builds WireGuard into its ZTNA platform natively. No separate server, no VIP configuration, no FortiGuard exceptions. Users get the same low-latency WireGuard performance with identity verification and device posture applied before every session. And because Jimber adds a stealth mode that wraps WireGuard inside HTTPS, connections work even on networks that block UDP traffic, something a standalone WireGuard setup cannot solve.
How Fortinet ZTNA works (and where it gets complicated)
Fortinet ZTNA provides application-level access through an HTTPS reverse proxy on the FortiGate. Every connection is verified against user identity, device certificates, and posture tags. The architecture requires three components in concert: the FortiGate as access proxy, FortiClient EMS for certificate and posture management, and the FortiClient agent on every endpoint.
Setting this up means connecting EMS to FortiGate via Fabric Connectors, configuring Zero Trust tagging rules in EMS, creating ZTNA server definitions per application, and building proxy policies that match users and tags to resources.
You gain application-level access, continuous posture verification, and applications hidden from the public internet. You lose simplicity. Every application needs its own ZTNA server configuration and proxy policy. FortiClient EMS requires a separate licence. BYOD devices and contractors need FortiClient installed or are limited to web mode. The HTTPS proxy adds latency to every request, noticeable for chatty protocols like SMB or database connections.
How Jimber handles this differently: Jimber delivers the same application-level Zero Trust access from a single cloud console. No EMS server to maintain, no per-application proxy definitions, no FortiClient agent dependency. Policies are defined once by identity and role, then enforced across all applications. For contractors and BYOD scenarios, browser-based access through isolation technology means users reach specific applications without installing anything on their device, a gap that Fortinet ZTNA cannot fill without FortiClient.
Where each option falls short
The core issue with the Fortinet-native paths is that they force a trade-off. WireGuard gives you speed but no access control. ZTNA gives you access control but adds complexity and latency.
| Your priority | WireGuard (FortiGate) | Fortinet ZTNA | Jimber SASE |
|---|---|---|---|
| Fast, reliable tunnels | Excellent | Proxy adds latency | Excellent (native WireGuard) |
| Application-level access | Not available | Yes | Yes |
| Device posture verification | Not available | Yes (EMS required) | Yes (built-in) |
| BYOD / contractor access | Agent required | Agent required | Agentless via browser isolation |
| Small team manageability | Moderate (unsupported) | High overhead | Low (single console) |
| Multi-site deployment | No central management | Complex Fabric setup | Cloud-managed across all sites |
| NIS2 audit evidence | Minimal logging | Good, spread across tools | Centralised in one console |
| Restrictive networks | Partial (UDP may be blocked) | No solution | Stealth mode (WireGuard over HTTPS) |
Jimber eliminates the trade-off because it doesn’t treat WireGuard and ZTNA as separate concerns. The tunnel protocol and the access controls are one architecture, managed in one place.
What makes Jimber the strongest option for FortiGate administrators
Three capabilities are particularly relevant when migrating from a FortiGate environment.
WireGuard speed without the workaround.
Jimber uses WireGuard as its core tunnel, with all the performance advantages that FortiGate administrators want: instant reconnection on network switches, low CPU overhead, modern cryptography. But instead of running an unsupported server behind your firewall, it comes integrated with identity-based access policies, device posture checks, and centralised logging. You keep the speed and gain the controls.
Agentless access that actually works.
Both standalone WireGuard and Fortinet ZTNA require software on every endpoint. For external consultants, partners, and BYOD users, that’s a hard sell. Jimber provides browser-based access through isolation, meaning users see and interact with an internal application without any code running on their device. No agent installation, no FortiClient licence, no device management argument with external parties.
One console replaces multiple Fortinet components.
Where Fortinet ZTNA requires FortiGate + FortiClient EMS + FortiClient agents (and optionally FortiAnalyzer for reporting), Jimber consolidates access control, web security, and multi-site connectivity into a single cloud-managed platform. For MSPs managing multiple client environments, the built-in multi-tenant architecture replaces per-customer EMS instances entirely.
The platform also includes NIAC hardware for securing devices that can’t run any agent, like printers, IoT sensors, and industrial equipment, with transparent pricing and no hidden licence tiers.
How a migration from FortiGate to Jimber works
Jimber deploys alongside existing Fortinet infrastructure. There is no forced cutover.
Stage 1: Pilot. Publish 2-3 internal web applications through Jimber’s ZTNA. Keep existing FortiGate access active for everything else. Measure user experience and support ticket volume. This takes days, not weeks.
Stage 2: Expand. Migrate additional applications and user groups. Enable device posture checks. Deploy NIAC for agentless devices. Activate the Secure Web Gateway for web filtering.
Stage 3: Consolidate. Once coverage reaches 80% or more, decommission legacy VPN access for migrated users. Your FortiGate stays active for north-south traffic inspection where it’s most effective.
For a detailed look at the IPsec-versus-ZTNA decision as a protocol comparison, see our migration path guide. If you’ve already completed an IPsec migration and want to evaluate next steps, this post-migration assessment covers the friction points worth addressing.
Ready to see WireGuard performance with Zero Trust access controls in a single console? Book a demo and we’ll map a migration path for your FortiGate environment.
FAQ
Does FortiOS support WireGuard natively?
No. As of early 2026, there is no native WireGuard option in the FortiGate GUI or CLI. Administrators must run a separate server behind the FortiGate with manual port forwarding. Jimber integrates WireGuard natively into its ZTNA platform, removing that workaround entirely.
Can I run WireGuard and Fortinet ZTNA at the same time?
Technically yes, but you’d manage two separate architectures with no shared policy model. Jimber combines WireGuard tunnelling and Zero Trust access controls in one platform, so you don’t need to choose.
What happened to SSL VPN web mode?
Fortinet renamed it “Agentless VPN” in FortiOS 7.6.3. It still works on models with more than 2 GB RAM, but is removed from entry-level models like the 40F, 60F, and 90G series.
Is Fortinet ZTNA worth the complexity for mid-market teams?
If you have dedicated staff to manage FortiClient EMS, certificate chains, and per-application proxy rules, Fortinet ZTNA provides genuine security improvements over VPN. For teams that find this too heavy, Jimber achieves the same Zero Trust outcome from a single cloud console without the multi-component overhead.
How does Jimber handle the transition from a FortiGate environment?
Jimber deploys alongside existing FortiGate infrastructure. Migrate user groups and applications incrementally. Your FortiGate stays active for traffic it handles well while remote access shifts to the SASE platform.