SecureEdge Private Access with POP for Connectors

This article covers frequently asked questions about SecureEdge Private Access with Points of Presence (PoP) for the Connector.

Question: How can different users be granted access to the same domain controller using different port sets in ZTNA?

• For example: You require a Zero Trust Network Access (ZTNA) policy whereby User A is granted access to the domain controller on a specific subset of ports, while User B is authorized to access a different set of ports, for instance, including port 3389.

Answer: You must create custom network applications.

Since the Connector facilitates access to a domain controller by specifying the domain controller's hostname and internal IP address within the server configuration section, when you add a server within the Connector, a corresponding ZTNA resource is automatically generated, which can then be selected during the creation of a ZTNA policy.

Configuration Steps

1. Open SecureEdge Manager.

2. Go to Security > Apps and Resources > New Custom Network Application.

3. Create a new custom network application and specify the required information:

   • Protocol

   • Port

   • Destination

4. For the Destination, use the internal IP address of the Connector that was selected for the DC resource.
   Note: The easiest way to identify the internal IP address is to connect using the Agent and run a ping command against the hostname configured for the DC in the Connector.

5. Repeat this process to create multiple custom network applications, each pointing to the same destination (the DC) but configured with different ports.

6. Reference the appropriate custom network application in each ZTNA policy, depending on the user’s access requirements. The "Default Connector" object is created automatically for convenience.

Question: Can the Connector route traffic to resources on different Layer 2 (L2) subnets?

Answer: Yes, the Connector can route traffic to other L2 subnets as long as those networks are reachable from the system on which the Connector is installed.

How It Works

• The Connector can access all IP addresses and routes that are available to the host system’s network stack.

• The Connector accepts the incoming connection and then establishes a new outbound connection to the destination IP address. Traffic is forwarded between these two connections. From a networking perspective, this behavior is effectively equivalent to SRC-NAT, which explains why it appears that way during traffic inspection.

Question: Is it possible to send only ZTNA-related logs to Secure Edge Manager while excluding web and DNS activity logs?

• For example: You want to ensure that all ZTNA logs continue to appear in Secure Edge Manager, but they do not require visibility into DNS or web filtering activity.

Answer: Yes, this is supported. Disabling web filtering prevents unnecessary web and DNS activity logs while preserving complete visibility into all ZTNA activity.

• DNS and network traffic logs will continue to be generated only for ZTNA traffic.

• If security inspection for public SaaS applications is not enabled, related threat and network traffic logs for public SaaS traffic will not be populated, either.

Question: Why does the Connector server configuration not allow me to specify either TCP or UDP for defined ports?

Answer: For the automatically created Default Connector resource, all configured ports apply to both TCP and UDP traffic. This default Connector object is created for convenience and is intentionally protocol-agnostic. However, if you require more granular control, you can configure protocol-specific access by creating custom Network Applications.

Specify Explicit Ports and Protocols

1. Create a Custom Network Application.

2. Define the required information:

   • Destination

   • Port

   • Protocol (TCP or UDP)

3. Reference the custom Network Application in the relevant ZTNA policy.