SSL VPN to ZTNA Migration Guide

[keithli_FTNT]

The following snippet summarizes the migration scenario to help you migrate from SSL VPN to ZTNA application gateway for remote users accessing hosted web applications. The goal is to reduce the reliance on dial-up and SSL VPN by adding device authentication with role-based application access. To view the complete guide, go to SSL VPN to ZTNA Migration Guide.

Design Considerations

Organizations that have a mature SSL VPN solution in place likely have the following in common:

• Remote access users and groups are defined on an external server, for example, on a Windows Active Directory.

• Granular rules are defined to grant distinct user groups access to different resources.

• For scaling the VPN solution, SSL VPN is offered in tunnel mode to remote users.

• Remote users have FortiClient installed on their endpoints, and is actively managed by FortiClient EMS.

When the above criteria are met, the basic components and configurations for ZTNA is already in place. Namely, a FortiGate with various user groups defined and FortiClients provisioned and managed by EMS. Administrators can take a phased approach in migrating hosted servers and user groups to ZTNA while incrementally disabling access through SSL VPN.

Deployment Procedures

Before migration can occur, we must examine the current SSL VPN configuration and topology, assess components and configurations that can be re-used, and then prepare the components for ZTNA. Migrations is performed one server at a time, starting with servers accessible by the least number of users and groups.

This guide will walk through the following:

1. Existing teleworking configurations

2. Prepare FortiClient and FortiClient EMS for ZTNA

3. Migrate Web access to infrastructure devices for Administrators

4. Migrate Web access to Finance server for Finance group

5. Migrate Web access to Webserver1 and Webserver2

6. Configuring and verifying rules for on-net access

7. Shut off all SSL VPN access

The goal is to apply device identity and posture check to prevent unauthorized devices or vulnerable devices from accessing the hosted Web applications. Security posture check in our example amounts to the following:

• Devices are checked for critical vulnerabilities. If critical vulnerabilities exist, devices cannot be trusted.

• Devices are checked for domain registration. They must be registered to the company’s Active Directory domain and part of the Domain Users group.

For more information, go to SSL VPN to ZTNA Migration Guide.