Objective
The current Private App Segment definition conflicts with what is described in the Netskope Knowledge Base article.
When Publisher DNS is enabled, both IP and URL must be defined in the host configuration of a private app segment.
Reference:
https://docs.netskope.com/en/private-access-best-practices#idm46139539889184
Prerequisite
This issue generally applies to Netskope Private App Segments Definitions.
Context
We observed that in the current Netskope Private App Segment configuration, once Publisher DNS is enabled, users are unable to access a private application if only the private app URL is defined.
Do You Know?
This mechanism appears redundant. Once Publisher DNS is enabled, it is possible to configure a random port for the URL and then define a separate policy using the private IP with the correct port, since users can no longer access the URL using the originally defined port.
This configuration also introduces an additional risk: users may inadvertently be granted access to other private applications that share the same private IP.
Notes
We got reply from Support through this support case: 00596839 Issue with Publisher DNS functionality mechanism.
This is what support explained:
Scenario
Private application:portal.company.com
Internal DNS resolves it to 10.10.10.10
Accessed over TCP 443
Case 1: Publisher DNS enabled but IP is NOT added in any Private App
Flow >>
- User opens browser and accesses portal.company.com
- NPA client sends the DNS query through the tunnel to the Publisher
- Publisher DNS resolves portal.company.com → 10.10.10.10
- Endpoint browser receives 10.10.10.10 as the resolved IP
- Browser sends HTTPS traffic directly to 10.10.10.10
- NPA client checks its Private App definitions
- No Private App matches 10.10.10.10
- Traffic is not intercepted by NPA
- Connection either fails or goes directly to the network bypassing NPA
Result
- DNS works
- Traffic is not tunneled
- Private app access fails or bypasses Netskope
