A visual guide to the manual order of operations for defining ZTNA applications, preparing the environment for future automation.
Must exist before configuring policies.
Define services and grant global access.
Where access control actually happens.
Create gateways to map the external proxy ports the client connects to, to the internal service listening ports.
| External (Proxy) | Internal (Service) | |
|---|---|---|
| 2443 | 443 (HTTPS) | |
| 2022 | 22 (SSH) | |
| 2025 | 25 (SMTP Ex.) |
Under Endpoint Profiles (ZTNA Destinations) -> DOI Default, everyone is granted access to ALL applications. EMS is not the policy enforcement point. Enforcement happens at the FortiGate proxy policy level.
Create destinations on the FortiGate.
Prefix by Bureau/Role (e.g., OCIO management, FAZ, FortiManager) to keep track of who needs what.
Group related objects into logical containers. Unique one-off objects go into a general container.
Separate FQDNs and IPs. "However the user is getting to it is how we want to build the apps, because that's how FortiClient will proxy them."
Append the ZTNA server configuration to the firewall policy and map the server port (e.g., 2443) to the proxy policy.
FortiGate applies AND logic to security posture tags within a policy. Therefore, a single policy cannot require both a Windows tag AND a Mac tag (a machine cannot be both).
Result: You must build 2 proxy policy entries per application/service.