Migrating FortiGate SSL-VPN to NetBird: the procedure

Replace remote access without interrupting operations? WZ-IT plans and operates the move from VPN appliances to identity-based access - NetBird, IdP integration, sites and machines, from one team. See managed secure access

With FortiOS 7.6.3 Fortinet removed SSL-VPN tunnel mode on all FortiGate models. That turns an architecture debate into a deadline: every remote access configuration has to be touched. This guide shows the path to NetBird - not as a concept but as a procedure: inventory, identity, peers, access policies, sites and cutover. As of July 2026.

Table of contents

• The trigger and the two paths
• What changes architecturally
• Step 1: Take inventory
• Step 2: Control plane and identity
• Step 3: Roll out peers
• Step 4: Groups and access policies
• Step 5: Sites and machines without a client
• Step 6: Cutover and the way back
• Pitfalls from practice

The trigger and the two paths

From FortiOS 7.6.3 onwards, SSL-VPN tunnel mode is available in neither the GUI nor the CLI, on all FortiGate models. Two details from the release notes are decisive: existing configurations including the associated firewall policies are not carried over, and the migration must happen before the upgrade, otherwise remote access breaks.

That leaves two paths:

• IPsec - the direct successor named by Fortinet, optionally over TCP 443. Shortest path, stays in the familiar ecosystem, sensible above all for fixed site-to-site tunnels.
• Identity-based overlay - remote access moves from the appliance into a mesh that grants access per identity and resource. More rebuilding, but the exposed listener disappears.

This guide describes the second path. For the background on why exposed appliances became a liability, see FortiGate SSL-VPN risk in 2026.

What changes architecturally

The difference is not the protocol but the order of access and verification:

The practical gain: after the migration there is no anonymously reachable service left for a scanner to find - and a compromised endpoint only reaches what its group has been assigned.

Step 1: Take inventory

Before anything is built, the current state has to be on the table. Four questions:

1. Who has access today? Employees, external contractors, machine manufacturers - and via which accounts? Local FortiGate users are the most common blind spot here because they appear in no directory.
2. What do they access? Concrete target systems instead of "the network". This list later becomes the policy matrix.
3. Which access paths are not tied to a person? Shared accounts, shared credentials, machine access. They need their own solution in the target design.
4. What is internet-exposed? Not only the SSL-VPN but every open management interface.

The result is a table of "who accesses what, with which account, for what purpose". Without it, the policy work later becomes guesswork.

Step 2: Control plane and identity

First the control plane is set up - self-hosted on your own infrastructure or as an operated service in the EU. It distributes keys, routes and rules; the data traffic then runs directly between peers.

The more important part is identity. NetBird connects OIDC-capable identity providers, including the self-hostable Authentik and Keycloak. This is where users, groups and multi-factor authentication live - and this is where the compliance lever sits: the German NIS2 implementation act in force since 6 December 2025 explicitly names multi-factor authentication as a risk management measure (see NIS2-compliant remote access).

Practical advice: define the group structure in the IdP first, not as an afterthought. It determines every access rule later, and rebuilding it afterwards costs more than thinking it through once.

Step 3: Roll out peers

A peer is a device in the overlay. There are two ways to register: interactive login via the IdP - the normal case for workstations - or setup keys for everything that starts unattended.

On setup keys (NetBird documentation):

• One-off for individual machines, reusable with a usage limit for rolling out in series.
• Auto-assign groups: the key automatically assigns newly registered peers to groups - so the right access rules apply from the first second.
• Ephemeral peers: peers registered in this mode are automatically removed after staying offline for more than ten minutes - useful for containers and short-lived instances.

For servers and recurring rollouts the key belongs in automation (Ansible, Terraform), not in a document to be typed out by hand.

Step 4: Groups and access policies

Now the network becomes controlled access. NetBird works with groups and policies: a policy defines source and destination group plus protocol, ports and direction - bidirectional or initiated by the source peer only (documentation).

The single most important step of the whole migration: on first setup a default policy is created that allows connections between all peers. Anyone who leaves it in place has faithfully rebuilt the appliance's flat network. It belongs replaced by rules following the table from step 1 - per group only the targets, protocols and ports actually needed.

In addition, posture checks verify properties of the device before a connection is established. This can enforce, for instance, that only current clients get access.

Step 5: Sites and machines without a client

Not every system can or should run an agent - legacy servers, controllers, HMIs, printers. That is what routing peers are for: a NetBird peer in the respective network that forwards traffic between the overlay and the local subnet. This makes entire networks reachable without installing anything on the target systems, and access still stays policy-based.

One detail that saves time in operations: NetBird performs the required outbound SNAT itself only on Linux routing peers. On other platforms - OPNsense and pfSense are the usual examples - it has to be configured manually. For site connectivity a Linux routing peer is therefore the calmer path.

For machine and plant access the segmentation rules from the OT world apply on top; the background is in OT/IT segmentation and DMZ.

Step 6: Cutover and the way back

The switch runs in parallel, never as a cut-off date:

1. One uncritical user group and one uncritical target system first - including verifying that logging and policies take effect.
2. Move user groups one after another; the SSL-VPN stays active as the way back during this phase.
3. Contractor and machine access follows, because it needs the most coordination.
4. Only when nobody works over the old path any more is the SSL-VPN listener disabled. That removes the exposed attack surface - and only then is the upgrade to 7.6.3 uncritical.

The FortiGate usually stays in place as a firewall and for site-to-site tunnels. What is replaced is remote access, not the network design.

Pitfalls from practice

• Forgetting the default policy. The most common mistake, see step 4. Without restrictive rules the security gain is gone.
• Overlooking local appliance accounts. Accounts that only existed in the FortiGate appear in no IdP and surface during cutover.
• Carrying shared accounts over one to one. Shared credentials cannot sensibly be protected with MFA and render any logging worthless. The migration is the right moment to dissolve them.
• SNAT on non-Linux routing peers. Leads to connections failing for seemingly no reason.
• Switching off too early. The old access is the way back. It may only go once the last group has migrated and been confirmed in operation.

How the target architecture works in detail is explained in What is NetBird?; the basis for deciding between the overlay options is in NetBird vs Tailscale vs WireGuard.