Knowledge Base
Browse Docs
  • Introduction
    1. DefensX
    2. DNS & Web Filtering
    3. Zero Trust Files
    4. Zero Trust Credentials
    5. ADWare Protection
    6. Remote Browser Isolation
    7. Secure Browser Extension
    8. Secure Mobile Browser
  • Management
    1. Role-Based Access Control
  • Deployment
    1. Deployment via RMM
    2. Operating System Agent
    3. Deployment via GPO
    4. Deployment via Intune
    5. VDI and Terminal Servers
    6. Windows Manual Deployment
    7. Mac MDM Deployment
    8. Mac Manual Deployment
    9. Network Deployment
    10. Secure Mobile Browser
    11. Bypass Option
    12. AI Protections
    13. SaaS Restrictions
    14. Bookmark Manager
  • Integrations
    1. Azure AD
    2. Identity Providers
    3. SIEM
  • Policy Management
    1. Configuring Policies
    2. Configuring Consents
  • Secure Access (ZTNA)
    1. Introduction to ZTNA
    2. Configuration
  • Questions & Answers
    1. Licensing
    2. Incognito Mode
    3. Onboarding
    4. Active Directory
    5. Group Synchronization
    6. Agent
    7. Conflicting Softwares
    8. Reporting
    9. Virtual Desktops
    10. Using the Backend
    11. DNS & Web Filtering
  • Training Videos
    1. Onboarding Videos
    2. Attack Scenarios
    3. MSP Admin Training Series
  • MSP Automation
    1. Overview
    2. External Notifications
    3. Integrations
    4. Partner API
ONLINE DOCUMENTATION

Introduction to Zero Trust Network Access (ZTNA)

In this document
  • Traffic Flow and Mesh Routing
  • ZTNA Architecture in DefensX
    • User Device
    • DefensX Agent
    • Secure Access Connector
    • Secure Access Service
    • Secure Access Policy
  • How Access Works: Connectors, Services and Policies
  • ZTNA Modes
Important
To use all DefensX ZTNA features, the DefensX Agent version 2.2.99 or later is required.

Zero Trust Network Access (ZTNA) is a security approach that allows users to access specific applications or services without exposing the entire internal network.

Traditional remote access solutions often rely on VPN connections. When users connect through a VPN, they typically gain access to the internal network before accessing specific resources.

ZTNA works differently.

Instead of providing network access, ZTNA grants access only to the specific services defined in access policies.

This approach follows the Zero Trust principle:

Never trust, always verify.

Access decisions are based on identity and defined policies rather than network location.

The DefensX Secure Access solution creates a Zero Trust Network Access (ZTNA) mesh network on top of a distributed infrastructure deployed across Kubernetes clusters.

In this model, every packet includes both a source user identifier and a destination service identifier. Each packet is verified against the security policies defined in the DefensX Backend.

Although this approach introduces more processing overhead compared to conventional VPN routing, it offers significantly enhanced security by enforcing strict user-to-service-based access validation.

Note
In DefensX ZTNA, the local IP address assigned by the DefensX Tunnel adapter cannot be used to identify users. All client devices receive the same local IP address: 100.80.0.1.

This design reinforces the user–service mapping model, where IP addresses are irrelevant. Access control is determined entirely by user identity and service configuration policies.

Traffic Flow and Mesh Routing

Depending on availability and load balancing parameters, a user may connect through a different worker cluster than the connector hosting the target service.

In such cases, the user’s encapsulated traffic securely traverses the DefensX Mesh Network, reaching the target connector privately.

It is also possible to use multiple connectors across different regions for various services. Traffic is always routed based on the user and target service relationship.

All traffic passing through the DefensX ZTNA network is end-to-end encrypted:

  • If you provide a clear-text service (e.g., HTTP), the traffic is fully encrypted within the tunnel.

  • If you provide an already encrypted service (e.g., HTTPS), it undergoes double encryption.

When traffic moves between clusters within the mesh network, no intermediate node decrypts it. Decryption only occurs on the final client or service endpoint, while intermediate nodes can see only the minimal user and service identifiers required for routing.

ZTNA Architecture in DefensX

DefensX implements Zero Trust Network Access using several core components.

User Device

The endpoint used by the user. The DefensX Agent installed on the device enforces security policies and communicates with the DefensX platform.

DefensX Agent

The agent monitors network activity and applies policy decisions defined in the DefensX management console.

Secure Access Connector

A connector is an agent that has network access to the service. It acts as a bridge between the user and the service.

Secure Access Service

A Secure Access Service represents the service that will be accessible through ZTNA.

Examples include:

  • RDP connection

  • File Sharing

Secure Access Policy

Policies determine which users are allowed to access specific services.

How Access Works: Connectors, Services and Policies

Every DefensX Agent can function as a ZTNA Connector by assigning the Connector role from the DefensX Backend, no additional software installation is required.

Once designated as a connector, the agent can start providing TCP or UDP-based services, either:

  • Hosted locally on the same machine, or

  • Accessible via the local network or public internet.

The key requirement is that the connector must have network-level access to the service it exposes.

Any DefensX Agent can access services provided by connectors, as long as permitted by the Secure Access Policies.

Secure Access Policies:

  • Are attached to user groups.

  • Contain Secure Access Services offered by one or more DefensX Connectors.

  • Can be multiple, serving different user groups (similar to Web Filter policy configurations).

ZTNA Modes

The ZTNA connection mode can be configured per deployment group.

DefensX supports four ZTNA connection modes:

  • Disabled: Use this mode if ZTNA is not required on certain agents. Agents can be reassigned between deployment groups later.

  • Automatic (Always-On): The ZTNA tunnel is automatically established based on the active authentication token.

  • Manual: The tunnel uses the existing token but must be manually initiated by the end user.

  • With Authentication: The tunnel requires an interactive sign-in process before connecting.

www.defensx.com
Secure Industries, Inc 101 Avenue of The Americas, Floor 9 New York, NY 10013