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

Configuration

Overview

Important
 To use all DefensX ZTNA features, the DefensX Agent version 2.2.99 or later is required.

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

Unlike traditional VPNs, which connect entire IP networks, ZTNA connects individual users to specific services.

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 Modes

You can configure the ZTNA connection mode per deployment group. To do this, go to the Policies page and click the Advanced Options (red) button for the desired 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.

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.

Access Control

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).

If a Secure Access Policy has no group assignment, it applies to all DefensX ZTNA clients, granting them access to the defined services.

On-Net / Off-Net Scenarios

If users connect from within an office network that already hosts a DefensX Connector, you can define Office IPs for that connector.

office ips

These IPs should correspond to the public IP address used by the connector when accessing the DefensX ZTNA Cloud Network.

When a ZTNA client connects from an IP address matching the defined Office IPs, all ZTNA services provided by that connector are disabled locally. This allows the client to access services directly over the local network, bypassing the ZTNA tunnel.

Using DefensX ZTNA with Active Directory

You can securely expose your Active Directory services through a DefensX Connector, without installing the DefensX Agent directly on your Primary Domain Controller (PDC).

It is best practice to use a separate machine (not the PDC) as the connector for Active Directory access. This simplifies configuration and avoids complexities related to Microsoft DNS Server settings.

After configuring all required ports in a Secure Access Service, you can:

  • Perform Group Policy updates

  • Access file servers

  • Join or remove computers from the domain

all securely over the ZTNA network.

For detailed configuration steps, see the Active Directory Services Configuration guide.