Home

Fortinet ZTNA Policy Configuration Guide: Mastering Full vs. Simple Modes and Rule Order

.

Fortinet Zero Trust Network Access (ZTNA) framework has undergone significant evolution since its introduction in FortiOS 7.0, culminating in the introduction of simplified policy configuration options in FortiOS 7.4. This evolution represents a strategic shift toward making zero-trust security more accessible and manageable for network administrators of varying expertise levels.

The traditional ZTNA implementation required configuring multiple distinct components: an EMS connection and tags, ZTNA server configuration, specialized ZTNA rules, and optional authentication schemes. With the 7.4 enhancement, administrators now have two configuration approaches—full ZTNA policies and simple ZTNA policies—each with distinct characteristics and use cases. Understanding when to deploy each mode and how to properly order rules within your security architecture is critical to implementing effective zero-trust security.

Key Takeaway: Fortinet has streamlined ZTNA implementation by introducing two configuration modes—full (proxy-based) and simple (firewall-based)—giving administrators flexibility based on their specific security requirements and infrastructure complexity.

Understanding Full vs. Simple ZTNA Policies

Full ZTNA Policies: The Traditional Proxy-Based Approach

Full ZTNA policies, available since FortiOS 7.0, utilize proxy policies to control access to ZTNA servers. These policies offer granular control over traffic inspection and security processing. According to Fortinet's documentation, "UTM processing of the traffic happens at the ZTNA rule" when using full ZTNA mode, meaning all security inspection occurs at the proxy policy level rather than the firewall policy level.

The configuration for full ZTNA policies involves creating specialized proxy policies that can be configured from the Policy & Objects > Proxy Policy page by setting the Type to ZTNA. These policies support advanced features including destination interface control, real server destination address filtering, and comprehensive application-layer security inspection.

Simple ZTNA Policies: The Streamlined Firewall-Based Approach

Introduced in FortiOS 7.4, simple ZTNA policies utilize regular firewall policies for ZTNA enforcement. This represents a significant simplification, allowing administrators to configure ZTNA access controls using the familiar firewall policy interface. When creating a new firewall policy, administrators can now set the Type to ZTNA to enable this simplified mode.

However, there are important limitations to simple ZTNA policies. Fortinet's documentation explicitly states: "A simple ZTNA policy cannot control access based on the destination interface or the real server's destination address." This means simple policies are best suited for straightforward ZTNA deployments where these granular controls aren't necessary.

Critical Configuration Components for Both Modes

Essential ZTNA Building Blocks

Regardless of whether you choose full or simple ZTNA policies, several foundational components must be properly configured:

  1. FortiClient EMS Connector: This establishes communication between FortiGate and FortiClient EMS for synchronizing endpoint information and ZTNA tags. Configuration involves adding the EMS server in Security Fabric > Fabric Connectors.

  2. ZTNA Tags and Tag Groups: These dynamic address objects are synchronized from FortiClient EMS and form the basis of posture-based access controls. Tags can be viewed in Policy & Objects > ZTNA > ZTNA Tags tab.

  3. ZTNA Server Configuration: This defines the access proxy VIP and the real servers that clients connect to. It includes virtual host matching rules and server mappings that determine how HTTPS requests are processed.

  4. Authentication Infrastructure: Both policy modes require properly configured authentication schemes and rules to handle user authentication. The methods remain consistent between modes, with basic HTTP and SAML authentication being supported.

Rule Order and Processing Logic

Policy Evaluation Sequence

Understanding ZTNA policy evaluation order is critical for proper implementation. Based on Fortinet documentation and community discussions, the processing logic follows this sequence:

  1. Firewall Policy Match: Traffic first matches against the firewall policy that has ZTNA enabled (either full or simple mode).

  2. ZTNA Rule Evaluation: For full ZTNA, traffic is then evaluated against proxy policies (ZTNA rules). For simple ZTNA, evaluation continues within the firewall policy context.

  3. Tag and Authentication Verification: The system checks whether the endpoint has the required ZTNA tags and whether user authentication requirements are met.

  4. Security Processing: UTM inspection occurs based on the policy configuration—at the ZTNA rule level for full mode, or potentially at different points depending on the configuration.

The ztna-policy-redirect Feature

FortiOS 7.4 introduced a valuable feature for connecting simple and full ZTNA policies: ztna-policy-redirect. This CLI-only setting (disabled by default) allows traffic that matches a simple ZTNA policy to be redirected for a full ZTNA policy match. This enables hybrid deployments where simple policies handle initial filtering, but certain traffic undergoes more thorough inspection through full ZTNA policies.

The configuration is straightforward:

config firewall policy     edit <id>         set ztna-policy-redirect {enable | disable}     next end

When enabled, this feature creates a two-stage evaluation process: first the simple policy match with basic checks, then the full policy match with more granular controls. If no full ZTNA policy matches the traffic after redirection, it is implicitly denied.

Authentication Considerations Across Modes

Authentication Scheme Requirements

A common point of confusion in the Fortinet community revolves around authentication requirements for simple ZTNA policies. The documentation clarifies that "authentication remains largely the same between both ZTNA policy configuration modes. You can specify user groups under Source to define the groups in which the access control applies to. However, the underlying authentication schemes and rules must still be in place to direct the traffic to the ZTNA application gateway."

This means that both full and simple ZTNA policies require pre-configured authentication schemes and rules. The difference lies in how authentication is processed internally—full ZTNA policies use WAD (web application daemon) for authentication, while traditional firewall policies typically use authd.

Enabling Proxy Authentication for Firewall Policies

For organizations using simple ZTNA policies (which are firewall policies) but needing the authentication method consistency of full ZTNA, FortiOS 7.4 provides an option to enable proxy authentication for regular firewall policies:

config firewall auth-portal     set proxy-auth enable end

When enabled, this setting causes firewall policies to use the same authentication scheme and rule mechanism as proxy policies, ensuring consistent authentication behavior across different policy types in a mixed environment.

Best Practices for Policy Configuration and Ordering

Choosing Between Full and Simple Modes

Based on community discussions and documentation analysis, follow these guidelines:

  • Use Full ZTNA Policies when you need:

    • Granular control based on destination interfaces
    • Real server destination address filtering
    • Comprehensive UTM inspection at the proxy level
    • Complex authentication scenarios
    • Maximum security for sensitive applications

  • Use Simple ZTNA Policies when you need:

    • Simplified management through familiar firewall policy interface
    • Quick deployment for straightforward access scenarios
    • Integration with existing firewall policy workflows
    • Basic ZTNA functionality without advanced proxy features

Policy Ordering Recommendations

  1. Place more specific policies before general ones to ensure proper matching
  2. Implement deny policies before allow policies for security-critical resources
  3. Use explicit ZTNA tag matching rather than broad "any" rules when possible
  4. Test policy order thoroughly in a non-production environment before deployment
  5. Document policy sequences to maintain clarity as configurations evolve

Troubleshooting Common ZTNA Policy Issues

Verification and Logging Techniques

Both documentation and community discussions emphasize the importance of proper verification:

  1. Check ZTNA Logs: Use the command sequence to filter and display ZTNA-specific traffic logs:

    # execute log filter category traffic # execute log filter field subtype ztna # execute log display

  2. Verify Tag Synchronization: Ensure ZTNA tags from FortiClient EMS are properly synchronized using:

    # diagnose firewall dynamic address # diagnose firewall dynamic list

  3. Confirm Policy Matching: Review traffic logs to verify which policy ID is matching traffic, noting whether it's a proxy policy (full ZTNA) or firewall policy (simple ZTNA).

Common Configuration Pitfalls

  • Missing authentication schemes/rules for simple ZTNA policies
  • Incorrect ZTNA tag assignments leading to improper access decisions
  • Policy order conflicts where broader policies override more specific ones
  • Certificate issues with client or server authentication
  • EMS connectivity problems preventing tag synchronization

FAQ: Fortinet ZTNA Policy Configuration

Q: When should I choose full ZTNA mode over simple mode? A: Choose full ZTNA mode when you need granular control based on destination interfaces or real server addresses, comprehensive UTM inspection at the proxy level, or advanced authentication scenarios. Simple mode is best for basic deployments where these advanced features aren't necessary.

Q: Do simple ZTNA policies require authentication schemes and rules? A: Yes, both full and simple ZTNA policies require pre-configured authentication schemes and rules to direct traffic to the ZTNA application gateway. The authentication infrastructure is shared between both modes.

Q: How does the ztna-policy-redirect feature work? A: This CLI-only feature (enabled with set ztna-policy-redirect enable) allows traffic matching a simple ZTNA policy to be redirected for evaluation against full ZTNA policies. This enables hybrid deployments where basic filtering happens at the firewall level, but certain traffic undergoes more thorough proxy policy inspection.

Q: What's the main limitation of simple ZTNA policies? A: Simple ZTNA policies cannot control access based on the destination interface or the real server's destination address. They also use the firewall policy framework rather than the proxy policy framework, which may limit some advanced inspection capabilities.

Q: How do I verify if my ZTNA policies are working correctly? A: Use the command execute log filter field subtype ztna followed by execute log display to view ZTNA-specific traffic logs. Check that the correct policy ID is matching traffic and verify that ZTNA tags and user authentication information appear in the logs as expected.