Skip to main content
pjang
Staff & Editor
pjang
Staff & Editor
May 6, 2026

Technical Tip: Explaining ZTNA Forward Proxy vs. Service Connectors (FortiOS 8.0 and later)

  • May 6, 2026
  • 0 replies
  • 139 views

Description


This article provides an explanation of the Zero Trust Network Access (ZTNA) traffic proxying options available on FortiOS v8.0.0 and later. More specifically, this article compares existing forward proxy functionality against the new ZTNA service connector functionality that has been added in v7.6 and v8.0.

Scope


FortiOS v7.6.0, v8.0.0, and later


Solution


Starting from FortiOS v7.0, the FortiGate can act as a ZTNA traffic proxy. With this functionality, client devices on untrusted networks can connect to the FortiGate, be subjected to authentication (through a combination of certificate and username/password authentication, plus EMS-based ZTNA tags), and subsequently access a protected resource using the FortiGate as a proxy server. See also: Zero Trust Network Access introduction.


This article refers to the above functionality as ZTNA forward proxying, where a single Fortinet device (such as a FortiGate, FortiProxy, or FortiPAM) receives a connection from the end-client and also makes a proxy connection to the protected server on-behalf of that client.


Note: FortiOS v8.0 changes ZTNA terminology compared to previous versions, and this article will utilize that updated version of terminology going forward. For more info, refer to the following document: ZTNA configuration simplification.


ZTNA forward proxy:

4ec9a0ca.png


Later, FortiOS v8.0.0 formally introduced new ZTNA service connector functionality that allowed the FortiGate to chain ZTNA proxy requests across multiple Fortinet devices. This allowed for two new methods of traffic proxy operation: ZTNA forward-mode service connectors and ZTNA reverse-mode service connectors.


Note #1: Before discussing service-connector based ZTNA, it is important to define some key terminology for these configurations:

  • ZTNA Edge refers to a Fortinet device (such as the FortiGate, FortiProxy, or FortiPAM) that receives connection requests from an end-client device and then initiates an outgoing connection to a downstream Fortinet device.

  • ZTNA Gateway refers to a Fortinet device that receives proxy connections from an upstream ZTNA Edge device and then initiates an outgoing connections to the protected servers (aka the ZTNA Destinations, or 'realservers').


Note #2: Technically, FortiOS v7.6.0 implemented partial-support for ZTNA reverse-mode service connector functionality. However, the FortiGate could only act as a ZTNA Gateway (not as the ZTNA Edge) and the functionality was also not broadly advertised in the FortiOS 7.6 Admin Guide. See also:


FortiOS v8.0 fully implements ZTNA service connector functionality, allowing the FortiGate to be used for both roles.


ZTNA forward-mode service connectors:


eaf91ecc.png


The diagram above demonstrates ZTNA forward-mode service connectors, where ZTNA proxy chaining and traffic flow is fully in the forward direction. Clients initiate connections to the ZTNA Edge, which then initiates its own outgoing connection to the ZTNA Gateway, which finally initiates an outgoing connection to the protected destination server.

ZTNA reverse-mode service connectors:

019ef5ba.png


The diagram above demonstrates ZTNA reverse-mode service connectors, which are similar to forward-mode service connectors (proxying chaining from end-client to the destination server), but include two major differences:

  1. The ZTNA Gateway initiates a persistent control channel connection outwards to the ZTNA Edge (shown above in green).

  2. When the ZTNA Edge receives a connection attempt from the end-client for a specific protected service, it must first make a request to the ZTNA Gateway over the established control channel connection. The ZTNA Gateway then initiates a second outgoing connection to the ZTNA Edge that is utilized for the ZTNA data channel traffic (shown in red above).


Comparing the three methods:

ZTNA traffic forwarding method

Minimum Number of Devices required

Benefits

Drawbacks

ZTNA forward proxying

One FortiGate

  • Simple configuration and network flow: one FortiGate both receives connections from end-clients and also makes proxy connections to the protected destination.

  • Clients that must access services behind different FortiGates would need multiple ZTNA Destinations (for traffic forward proxies) and/or DNS FQDNs (for web proxies).

  • Each FortiGate would need to be configured separately for ZTNA authentication and permissions.

ZTNA forward-mode service connectors

Two FortiGates (one ZTNA Edge, one ZTNA Gateway)

  • Separates the ZTNA Edge and ZTNA Gateway roles so that only one device (the ZTNA Edge) needs to allow incoming client connections from an untrusted network.

  • One ZTNA Edge device can be configured to reach multiple ZTNA Gateways, which simplifies the client-side experience (connecting to a ZTNA Edge device enables access to all ZTNA destinations, as well as centralized authentication rules).

  • Traffic flow is somewhat more complex than ZTNA forward proxying, as the ZTNA Edge must have routes and outgoing reachability to the ZTNA Gateway(s).

  • Configuration is slightly more complex than ZTNA forward proxying (similar setup required on both FortiGates, with small additional configuration on the ZTNA Edge).

  • Security implications: the ZTNA Edge (connected to untrusted networks) must be allowed to initiate connections into the trusted network towards the ZTNA Gateway(s), which means that firewall policies/ACLs for intermediate devices must allow the traffic flow.

ZTNA reverse-mode service connectors

Two FortiGates (one ZTNA Edge, one ZTNA Gateway)

  • Similar to forward-mode, reverse-mode also separates ZTNA roles so that only the ZTNA Edge is exposed to untrusted networks and clients only need to connect/authenticate to the ZTNA Edge to access all ZTNA Gateway destinations.

  • Improved security posture, as the ZTNA Gateway in the trusted network initiates both the control and data channel connections to the ZTNA Edge (no need to allow the ZTNA Edge to initiate connections into the trusted network).

  • Supports situations where the ZTNA Gateway is located behind NAT/private networks (no requirement to have port-forwarding, and the ZTNA Edge does not need to be configured with the IP address of the ZTNA Gateway).

  • Traffic flow is more complex than above two options, as clients and ZTNA Gateways initiate connections towards the ZTNA Edge. Additionally, control channels must establish correctly or else data channel connection establishment is not possible.

  • Configuration is more complex than forward-mode service-connectors since mutual TLS authentication is required to protect the control channel (i.e. proper X.509 certificates must be configured with trusted Root CA certificates on each FortiGate) and there is more configuration required in-general on both FortiGates.


Related document:

ZTNA service connector

ZTNA connector - reverse gateway and forwarder - Provides reference configuration snippets, along with the document linked above.

    Terms & ConditionsAccessibility statement