Basic ZTNA configuration

To deploy a ZTNA application gateway, configure the following components on the FortiGate:

1. Configure a FortiClient EMS connector

2. Configure a ZTNA server

3. Configure a ZTNA policy

4. Optional authentication

5. Optional HA configurations

This feature is not supported on FortiGate models with 2 GB RAM or less. See Proxy-related features not supported on FortiGate 2 GB RAM models for more information.

To configure ZTNA in the GUI, go to System > Feature Visibility and enable Zero Trust Network Access.

Configure a FortiClient EMS connector

To add an on-premise FortiClient EMS server in the GUI:

1. Go to Security Fabric > Fabric Connectors and double-click the FortiClient EMS card.

2. Set the Status to Enabled.

3. Enter a name for the connector and the IP address or FQDN of the EMS.

4. Click OK.

5. A window appears to verify the EMS server certificate. Click Accept.

   See FortiClient EMS for more information.

To add an on-premise FortiClient EMS server in the CLI:

config endpoint-control fctems
    edit <ems-id>
        set server <server IP or domain>
    next
end

To add FortiClient EMS Cloud in the GUI:

1. Go to Security Fabric > Fabric Connectors and double-click the FortiClient EMS card.

2. Set the Status to Enabled.

3. Set the Type to FortiClient EMS Cloud.

4. Enter a name for the connector.

5. Click OK. A window appears to verify the EMS server certificate.

6. Click Accept.

   See FortiClient EMS for more information.

To add FortiClient EMS Cloud in the CLI:

config endpoint-control fctems
    edit <ems-id>
        set fortinetone-cloud-authentication enable
        set certificate <string>
    next
end

Security posture tags

After the FortiGate connects to the FortiClient EMS, it automatically synchronizes security posture tags (formerly ZTNA tags). Security posture tags are generated from tagging rules configured on the FortiClient EMS. These tagging rules are based on various posture checks that can be applied on the endpoints. See Endpoint Posture Check Reference.

To view the synchronized security posture tags in the GUI:

1. Go to Policy & Objects > ZTNA and select the Security Posture Tag tab.

2. Hover the cursor over a tag name to view more information about the tag, such as its resolved addresses.

   

To create a security posture tag group in the GUI:

1. Go to Policy & Objects > ZTNA and select the Security Posture Tag Group tab.

2. Click Create New.

3. Enter a name for the group and select the group members.

   

4. Click OK.

To view the synchronized security posture tags in the CLI:

# diagnose firewall dynamic address
# diagnose firewall dynamic list

To create a security posture tag group in the CLI:

config firewall addrgrp
    edit <group name>
        set category ztna-ems-tag
        set member <members>
    next
end

Configure a ZTNA server

To configure a ZTNA server, define the access proxy VIP and the real servers that clients will connect to. The access proxy VIP is the FortiGate ZTNA gateway that clients make HTTPS connections to. The service/server mappings define the virtual host matching rules and the real server mappings of the HTTPS requests.

To create a ZTNA server for HTTPS access proxy in the GUI:

1. Go to Policy & Objects > ZTNA and select the ZTNA Server tab.

2. Click Create New.

3. Enter a name for the server.

4. Select an Interface. The IP address and Port fields are automatically filled in based on the interface selection.

   Verify that the IP address and port do not conflict with management access to the interface. Otherwise, change the IP address to another address on that subnet. You may specify the IP address as 0.0.0.0 if an interface other than Any is selected. The ZTNA Application Gateway IP address will dynamically use the primary and secondary IPv4 address of the interface as its external IP address.

5. Select the Default certificate. Clients will be presented with this certificate when they connect to the access proxy VIP.

   

6. Add a server mapping:

   1. In the Service/server mapping table, click Create New.

   2. Set Service to HTTPS.

   3. Set Virtual Host to Any Host or Specify.

      • Any Host: Any request that resolves to the access proxy VIP will be mapped to your real servers. For example, if both www.example1.com and www.example2.com resolve to the VIP, then both requests are mapped to your real servers.

      • Specify: Enter the name or IP address of the host that the request must match. For example, if www.example1.com is entered as the host, then only requests to www.example1.com will match.

   4. Configure the path as needed.

      The path can be matched by substring, wildcard, or regular expression. For example, if the virtual host is specified as www.example1.com, and the path substring is map1, then www.example1/map1 will be matched.

      

   5. In the Server section, enter the server IP address and port number.

   6. Click OK.

7. Click OK.

8. Use the CLI to add additional servers and mappings to the ZTNA server.

   After additional servers and mappings are added, the Load balancing option is visible in the GUI.

   config firewall access-proxy
       edit "ZTNA-Server"
           config api-gateway
               edit 1
                   config realservers
                       edit 0
                           set ip <real server 2 address>
                           set port <real server 2 port>
                       next
                   end
               next
           end
       next
   end

To create a ZTNA server and access proxy VIP in the CLI:

1. Configure an access proxy VIP:

   config firewall vip
       edit <name>
           set type access-proxy
           set extip <external IP>
           set extintf <external interface>
           set server-type {https | ssh}
           set extport <external port>
           set ssl-certificate <certificate>
       next
   end
   

2. If the virtual host is specified, configure the virtual host:

   config firewall access-proxy-virtual-host
       edit <auto generated when configured from GUI>
           set ssl-certificate <certificate>
           set host <host name or IP>
           set host-type {sub-string | wildcard}
       next
   end
   

3. Configure the server and path mapping:

   config firewall access-proxy
       edit <name>
           set vip <vip name>
           set client-cert {enable | disable}
           set empty-cert-action {accept | block}
           set log-blocked-traffic {enable | disable}
           config api-gateway
               edit 1
                   set url-map <mapped path>
                   set service {http | https | tcp-forwarding | samlsp}
                   set virtual-host <name of virtual-host if specified>
                   set url-map-type {sub-string | wildcard | regex}
                   config realservers
                       edit 1
                           set addr-type ip
                           set ip <ip of real server>
                           set port <port>
                           set status {active | standby | disable}
                           set health-check {enable | disable}
                           set translate-host {enable | disable}
                       next
                   end
                   set ldb-method static
                   set persistence none
                   set ssl-dh-bits 2048
                   set ssl-algorithm high
                   set ssl-min-version tls-1.1
                   set ssl-max-version tls-1.3
               next
           end
       next
   end

Configure a ZTNA policy

A ZTNA policy is used to enforce zero trust role based access control by using security posture tags or tag groups to verify a device’s security posture. A ZTNA policy can also utilize security profiles to protect this traffic.

In earlier versions, ZTNA rules were special proxy policies that controlled access to the ZTNA servers, and they could be configured from the Policy & Objects > ZTNA > ZTNA Rules tab. However, on this version and above, these special proxy policies are now configured from Policy & Objects > Proxy Policy page.

There are two ways to configure ZTNA rules in the GUI by using a full or simple ZTNA policy:

• Full ZTNA policy: The legacy method for configuring access-proxy policies.

• Simple ZTNA policy: A simplified method for configuring a ZTNA policy using firewall policies. This method covers most functionality of a Full ZTNA policy, except it cannot control access based on destination interface or real server’s destination address.

To configure a simple ZTNA policy in the GUI:

1. Go to Policy & Objects > Firewall Policy.

2. Click Create New.

3. Enter a name for the ZTNA policy.

4. Select the Action.

5. Set Type to ZTNA.

6. Select an Incoming Interface and Source.

7. Add the security posture tags or tag groups that are allowed access. If multiple tags are included, the matching method is set to Any by default.

8. Select the ZTNA server.

   

9. Configure the remaining options as needed.

10. Click OK.

To configure a simple ZTNA policy in the CLI:

config firewall policy
    edit 1
        set name <ZTNA policy name>
        set srcintf <interface>
        set dstintf "any"
        set action accept
        set srcaddr "all"
        set dstaddr <access proxy vip>
        set ztna-ems-tag <security posture tags>
        set schedule "always"
        set nat enable
    next
end

The dstintf command cannot be modified.

To configure a full ZTNA policy in the GUI:

1. Go to System > Feature Visibility.

2. Under Security Features, enable Explicit Proxy.

3. Click Apply.

4. Go to Policy & Objects > Proxy Policy.

5. Click Create New.

6. Enter a name for the rule.

7. Select an Incoming Interface and Source.

8. Add the security posture tags or tag groups that are allowed access. If multiple tags are included, the matching method is set to Any by default.

9. Select the Destination.

10. Select the ZTNA Server.

11. Select the Action.

    

12. Configure the remaining options as needed.

13. Click OK.

To configure a full ZTNA policy in the CLI:

config firewall proxy-policy
    edit 1
        set name <ZTNA policy name>
        set proxy access-proxy
        set access-proxy <access proxy>
        set srcintf <interface>
        set srcaddr "all"
        set transparent {enable | disable}
        set dstaddr "all"
        set ztna-ems-tag <security posture tag(s)>
        set ztna-tags-match-logic {or | and} 
        set action accept
        set schedule "always"
        set logtraffic all
        set poolname <ip_pool>
        set utm-status enable
        set ssl-ssh-profile <inspection profile>
    next
end

The transparent and poolname settings cannot be enabled at the same time. Use one setting at a time when configuring ZTNA policies.

Optional authentication

To configure authentication to the access proxy, you must configure an authentication scheme and authentication rule in the GUI or CLI. They are used to authenticate proxy-based policies, similar to configuring authentication for explicit and transparent proxy.

The authentication scheme defines the method of authentication that is applied. For ZTNA, basic HTTP and SAML methods are supported. Each method has additional settings to define the data source to check against. For example, with basic HTTP authentication, a user database can reference an LDAP server, RADIUS server, local database, or other supported authentication servers that the user is authenticated against.

The authentication rule defines the proxy sources and destinations that require authentication, and which authentication scheme to apply. For ZTNA, active authentication method is supported. The active authentication method references a scheme where users are actively prompted for authentication, like with basic authentication.

After the authentication rule triggers the method to authenticate the user, a successful authentication returns the groups that the user belongs to. In the ZTNA policy you can define a user or user group as the allowed source. Only users that match that user or group are allowed through the proxy policy.

To configure a basic authentication scheme in the GUI:

1. Go to Policy & Objects > Authentication Rules.

2. Go to the Authentication Schemes tab.

3. Click Create New.

4. Enter a name for the scheme.

5. Set the Method as Basic.

6. Select the User database as required.

   

7. Click OK.

To configure a basic authentication scheme in the CLI:

config authentication scheme
    edit <name>
        set method basic
        set user-database <auth server>
    next
end

To configure an authentication rule in the GUI:

1. Go to Policy & Objects > Authentication Rules.

2. Click Create New.

3. Enter a name for the rule.

4. Select the Source Address.

5. Select the Incoming interface.

6. Select the Authentication Scheme.

   

7. Click OK.

To configure an authentication rule in the CLI:

config authentication rule
    edit <name>
        set status enable
        set protocol http
        set srcintf <interface>
        set srcaddr <address>
        set dstaddr <address>
        set ip-based enable
        set active-auth-method <active auth scheme>
    next
end

To apply a user group to a full ZTNA policy in the GUI:

1. Go to Policy & Objects > Proxy Policy.

2. Edit an existing rule, or click Create New to create a new rule.

3. Click in the Source field, select the User tab, and select the users and user groups that will be allowed access.

4. Configure the remaining settings as required.

5. Click OK.

To apply a user group to a full ZTNA policy in the CLI:

config firewall proxy-policy
    edit <policy ID>
        set name <ZTNA policy name>
        set proxy access-proxy
        set access-proxy <access proxy>
        set srcintf <interface>
        set srcaddr "all"
        set dstaddr "all"
        set ztna-ems-tag <security posture tags>
        set ztna-tags-match-logic {or | and}
        set action accept
        set schedule "always"
        set logtraffic all
        set groups <user group>
        set utm-status enable
        set ssl-ssh-profile <inspection profile>
    next
end

The authentication rule and scheme defines the method used to authenticate users. With basic HTTP authentication, a sign in prompt is shown after the client certificate prompt. After the authentication passes, the returned groups that the user is a member of are checked against the user groups that are defined in the ZTNA policy. If a group matches, then the user is allowed access after passing a posture check.

For basic setup information, see ZTNA HTTPS access proxy with basic authentication example.

For advanced setup information, see ZTNA application gateway with SAML authentication example and ZTNA application gateway with SAML and MFA using FortiAuthenticator example.

Optional HA configurations

User information and TLS sessions are synchronized between HA members for ZTNA proxy sessions. When a failover occurs, the new primary unit will continue allowing sessions from the logged in users without asking for the client certificate and re-authentication again.

There are no special configurations for HA. Refer to HA active-passive cluster setup and HA active-active cluster setup to configure your HA cluster.

HTTP access proxy vs TCP forwarding access proxy

In an HTTP access proxy connection, there is no configurations needed on the client endpoint. Users can simply access the HTTP website on a browser by entering its URL. For TCP forwarding access proxy, a ZTNA rule must be configured on the FortiClient endpoint. This rule instructs FortiClient to listen to traffic to the destination address and port, and redirects the traffic to the FortiGate access proxy over HTTPS.

When deciding between using HTTP access proxy or TFAP for accessing web applications, consider the following.

• Use HTTP access proxy when the protected web application address can be resolved by the remote users publicly.

• Use TFAP when the protected application address can only be resolved on the internal network. TCP forwarding rules allow the FortiClient to intercept the request to the destination address and forward them to the application gateway.

For more information, see ZTNA TCP forwarding access proxy example.