Private App Management
Private App Management
The following sections explain how to create and steer Private Apps.
Create a Private App Definition for the Publisher to steer. A message appears on the Private Apps App Definition page when you’re approaching the maximum limit. You can contact Support to increase the limit.
- Go to Settings > Security Cloud Platform > App Definition and click Private Apps.
- Click New Private App.
- Enter a meaningful app name in the Application Name field (like
jira app). - Enter the Host domain in the Host field (like
jira.site.io). The Host field supports the following syntax: Host (jira.site.io). Up to 500 hosts can be added.Important
Using a hostname is recommended. If an app needs to be accessible by hostname and IP address, enter each separately by clicking Add.
When using an IP address for a host domain, ensure the IP address differs from all IP addresses used for Publishers. Other IP factors include:
- Don’t use wildcards, like
*.com, and*.local, one level below the top-level domain. You can use wildcards two levels down, like*.test.xyz, for the purpose of private app discovery. - Don’t use 0/0.
- Don’t use any CIDR less than /8. For example, if
x.x.x.x/yis a configured CIDR, thenyshould be greater than or equal to 8. (eg 10/8 is allowed, 1/7 is not allowed). - Don’t use TLD.
- Don’t use ipv6 equivalents of 0/0:
- “::”
- “0:0:0:0:0:0:0:0”
- “::0”
If the FQDN contains a .local domain, Netskope recommends one of the following for the Ubuntu-based Publishers:
- Ensure Ubuntu publishers are running version 98 or later.
- For Ubuntu publishers prior to version 98, execute the following commands on the publisher machines.
sudo rm -f /etc/resolv.confsudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.confdocker restart $(docker ps -a -q)
- Don’t use wildcards, like
- Enter the app TCP or UDP port, port range, or ports and port ranges. For example:
- Enter a specific port:
80 - Enter a specific port range:
1024-2048 - Enter ports and port range(s):
22,80,443,1024-2048
- Enter a specific port:
- Click in the Publisher text field and select one or more Publishers from the dropdown list.
Tip
For high-availability, add multiple publishers for each private app. Up to 16 Publishers can be used per app.
- (Optional) To have the Netskope Client send DNS requests for the specified hosts to the configured Publishers, enable the Use Publisher DNS toggle. To learn more, go to Configure Private Apps for DNS with the Publisher DNS Feature Enabled.
- (Optional) Private App Tags enable you to group multiple Private App Definitions for use in a Real-time Protection policy. Select one or more Private App Tag(s) from the dropdown list. To add a new Private App Tag, click Create New Tag. To learn more, go to Use Private Apps Tags in App Definitions.
- Click Save.
Connecting the Private App to the Publisher may take several minutes. Make sure that you see the green icon for this Private App before proceeding. If the badge is red, use the Troubleshooter feature or check your firewall rules before proceeding.
Note
When a user has access to a private app on different tenants using Netskope-encoded Private App URLs from the same browser, then after accessing the Private App on one tenant, a user will need to clear the cookies from the browser before being able to access the Private App on a different tenant.
The Private App Definition page shows these specifications for each Private App.
- Whether App Discovery is enabled or not.
- The Private App name.
- Whether Browser Access is enabled or not.
- The host IP addresses or IP subnets, hostnames, or wild card domains.
- The status of the Publisher connection, and the name of the Publisher used.
- Whether Publisher DNS is enabled or not.
- The number of steering configurations used.
- The number of policies applied to a Private App.
- Any Private App tags used.
- The last modification date.
Private Apps Filtering and Exporting Options
To use these features, go to Settings > Security Cloud Platform > App Definition > Private Apps.
Filters
These filtering options are available in the Netskope UI.
- Private App Tags
- Publisher
- Reachability
- Browser Access
- Use Publisher DNS
- Host
- In Steering
- In Policy
Note
When you select a filter with a search icon 
, that value is added to the search field so you can add more specifics. When a filter has an adjacent toggle arrow 
, there are expanded options to choose from.
The results displayed can be exported by clicking Export.
When migrating to ZTNA-based solutions, you may want to retain the same user experience for your users. One of the frequent requirements is the ability to support application access by PQDN (a short name). For example, instead of app1.example.com, a user could type app1 in the browser.
When the NPA Multi Search Domains Support feature is enabled, the Netskope Client will support access using PQDNs. The Netskope Client will be able to iterate (top-down) through the multiple search domains and validate domains after appending search domains.
How does the Multi Search Domains Feature Work?
- There is no additional configuration required in the web UI for this to work.
- The Netskope Client intercepts and validates domain resolution by tunneling DNS requests (iterating through the list) to Publisher for individual Search Domains.
- Assign stub IP (
100.64.0.0/16) only if a domain match in the SRP is resolvable on the Publisher. - If the Publisher returns
NXDOMAIN, the DNS request is sent back to the local network. - Valid (stub IP –
100.64.0.0/16) responses are cached by the client. - Publisher DNS validation remains effective, assigning a real IP if the domain is resolvable on the Publisher.
Important Considerations
- It is expected that the NPA Wildcard App Validation feature is turned on. This feature gets automatically enabled along with the NPA Multi Search Domains Support; however, if the NPA Wildcard App Validation feature is explicitly disabled, Multi Search Domain support will stop working.
- It is expected that the DNS server configuration and resolution is identical for Publishers assigned to an app.
- In case of multiple valid search domain matches, only the first top-down valid domain will work.
- The Admin should manage and control search domains, not the Netskope Client.
- If the user entered domain (PQDN or FQDN) matches a wildcard app definition in the SRP, the Netskope Client sends the DNS request to the Publisher to determine if the domain is resolvable. The behavior of FQDN with this feature is explained in Scenarios 2 and 3 below. Essentially, when Multi Search Domains Support is enabled, FQDN access would continue to work.
Use Cases
Scenario 1
- Private App definition:
*.acme.com(wildcard app definition). - The DNS search domains configured on the network adapter (in order):
*.acme.com,*.acme.local,*.eu.acme.com - End user types
jira(PQDN) in a browser to access the app. The domain which end user intends to connect to isjira.eu.acme.com
| Step | Description |
|---|---|
| 1 | The Netskope Client learns all search domains configured on the network adapter. |
| 2 | The Netskope Client appends suffix domains from top to bottom and tunnels DNS requests to the Publisher for validation. |
| 3 | The First DNS request matching SRP is jira.acme.com. The Publisher returns NXDOMAIN to the Client. |
| 4 | The next suffix domain *.acme.local does not match SRP and hence, iterates to the next domain. |
| 5 | The Client attempts the next suffix domain *.eu.acme.com (SRP match) and tunnels the DNS request to the Publisher. |
| 6 | As the resolution for jira.eu.acme.com succeeds on the Publisher, the Client gets notified, and a stub IP is assigned and cached. The app access succeeds. |
Scenario 2
- Private App definition:
*.acme.com(wildcard app definition). - The DNS search domains configured on the network adapter (in order):
*.acme.com,*.acme.local,*.eu.acme.com - End user types
jira.eu.acme.com(FQDN) in a browser to access the app.
| Step | Description |
|---|---|
| 1 | The Netskope Client learns all search domains configured on the network adapter. |
| 2 | The Netskope Client appends suffix domains from top to bottom and tunnels DNS requests to the Publisher for validation. |
| 3 | When the app definition matching request is a wildcard (in this case, *.acme.com) and this feature is enabled, the first DNS request sent to the Publisher is for jira.acme.com and not jira.eu.acme.com.
The Publisher returns NXDOMAIN to the Client. |
| 4 | The next suffix domain *.acme.local does not match SRP and hence, iterates to the next domain. |
| 5 | The Client attempts the next suffix domain *.eu.acme.com (SRP match) and tunnels the DNS request for jira.acme.com to the Publisher. |
| 6 | As the resolution for jira.eu.acme.com succeeds on the Publisher, the Client gets notified, learns the position of the valid search domain in the list and a stub IP is assigned and cached. The app access succeeds. |
Scenario 3
- Private App definition:
jire.eu.acme.com(FQDN app definition). - The DNS search domains configured on the network adapter (in order):
*.acme.com,*.acme.local,*.eu.acme.com - End user types
jira.eu.acme.com(FQDN) in a browser to access the app.
| Step | Description |
|---|---|
| 1 | The user entered FQDN is an exact match with the app definition, so no further validation is required. This also means that no DNS requests are forwarded to the Publisher. |
| 2 | The Netskope Client assigns a stub IP for jira.eu.acme.com and gets cached. The app access succeeds. |
Notes
- This feature is Generally Available as of Netskope Release R114. Contact your Netskope sales representative or Netskope support team to enable this for your tenant.
- NPA Multi Search Domains Support is currently available for Windows and macOS operating systems only.
- The minimum Netskope Client version for supporting this capability is R111 or higher. For R110 or lower, the feature will not work.
- There is no Publisher version dependency.
- The Netskope Client can learn up to 10 search domains configured on a network adapter.
Validate Wildcard Private Apps
For wildcard Private App definitions like*.acme.com, a stub IP (100.64.0.0/16) is returned for any hostname matching the SRP, regardless if there is a real DNS record on the other side of the Publisher.
When this NPA Wildcard App Validation feature is enabled, the DNS request intercepted by the Netskope Client will be sent to the Publisher and validate if the domain resolves on the internal network. For a domain that can’t be resolved, the DNS request will be sent to the local network, thereby exempting the traffic from being steered by NPA. This could be very helpful for key use cases like Application Discovery, to not steer non-existent domains and for domains that are shared both internally as well as externally.
Use Case
- Private App definition:
*.acme.com - Let’s assume there are three apps matching the definition:
*.acme.com,support.acme.com(not to be steered via NPA and also, unresolvable by the Publisher),jira.acme.com(to be steered via NPA), andtest.acme.com(non-existent domain). - End-user attempts to access the above three apps.
|
Domain |
Behavior |
|---|---|
|
|
The Netskope Client sends the DNS request to Publisher for validation. The Publisher returns NXDOMAIN to the Client. The DNS request is then sent to the local network. Here, the key difference lies in the local DNS resolver successfully resolving the domain and directing the traffic either through SWG or directly to the destination. |
jira.acme.com |
The Netskope Client sends the DNS request to Publisher for validation. As the resolution succeeds, the Client gets notified and a stub IP ( |
test.acme.com |
The Netskope Client sends the DNS request to the Publisher for validation. The Publisher returns |
- This feature is Generally Available as of Netskope Release R114. Contact Netskope Support to get this feature enabled. Starting with R116, this feature will be enabled by default in new tenants
- This feature is a prerequisite for Access Private Apps using PQDN to work.
- The minimum Netskope Client version for supporting this capability is R111 or higher. For R110 or lower, this feature will not work.
- There is no Publisher version dependency.
When deploying Netskope Private Access as a ZTNA product, it may not be clear how your enterprise applications work (like ports necessary), and whether there is a reliance on other hosts to make the applications function correctly. App Discovery is a cornerstone for the successful deployment of a ZTNA product.
When configuring Private App Discovery in a production environment, using a dedicated Publisher for app discovery is recommended.
- On the Private Apps page, click the + icon beside App Discovery.
- Click Edit.
- Enter these parameters:
- Host: Enter a Hostname for the DNS-based Private Apps and click Add. You can also enter a CIDR or IP addresses for IP-based Private Apps.
- Publisher: Select the Publisher dedicated for the Private Apps.
- User: Enter the user(s) that will access the Private Apps.
- Status: Enable Allow.
- Click Save. The App Discovery Status is now green (Enabled) on the Private Apps page.
- Have users start generating traffic using the Private Apps.
Once App Discovery is Enabled, NPA will allow access to the Apps covered by the App Discovery definition, unless there is a more specific rule in a Real-time Protection policy that blocks access to the requested App. An explicit rule in a policy is not required for a Discovery definition.
To create a Private App Definition for a Discovered App, click the + icon beside App Discovery, and then click View Discovered Apps.
 |
To create an App Definition for a single Discovered App, click the menu icon for a Discovered App, and then click Create Private App.
 |
To create an App Definition for multiple Discovered Apps, select the Discovered Apps, and then click Create App in the table header.
 |
Enter a Application Name and click Save. This new App Definition can now be used in a Real-time Protection policy.
If you select multiple Discovered Apps, and the Discovered Apps have different Publishers and ports, the new App Definition will include all Publishers and ports across the selected apps. This may result in certain Publishers being unable to access selected applications.
 |
You can also add a Discovered App to an existing App Definition. Select the existing App Definition and the Discovered App(s) to add to the App Definition, and then click Create App. Review the settings and click Save.
 |
After users generate traffic via Netskope Private Access, on the Private Apps page, click the + icon beside App Discovery, and then click View Discovered Apps.
|
Another option is to go to Skope IT > Private Apps and click the + icon beside App Discovery, and then click View Discovered Apps.
 |
This page shows:
- Discovered Application Names
- Hosts
- Ports
- Publishers
- Number of users
- Bytes Uploaded
- Bytes Downloaded
Private App Tags enable you to group multiple Private App Definitions for use in a Real-time Protection Private App policy, which alleviates having to choose multiple Private App Definitions in a policy. Instead, you select the Private App tag in a policy that includes multiple Private App Definitions.
Private App Tags can be applied to new and existing Private App Definitions. In the App Definition dialog box, click in the Private App Tag text field and select one or more tags. To search for a tag, starting entering the name, and then select it when it appears. After adding a Private App Tag to an App Definition, the tag name is shown in the Private Apps Tag column on the App Definition page.
The v2 REST APIs can be used to incorporate Private App Tags in App Definitions. In your Netskope tenant, go to Settings > Tools > REST API v2 and click the API Documentation link. In the Swagger UI, look for the /api/v2/steering/apps/private/tags endpoints. To learn more, go to: REST API v2 Overview.
You can create a Private App Tag when creating an App Definition, or create a new tag when editing an existing App Definition. In both cases, click in the Private App Tag field in the App Definition dialog box, and then enter a tag name. When you see the new tag at the bottom of the list, click Create New Tag and then Save. The new tag now appears in the list and can be used in a Private App policy.
 |
After adding a tag to a Private App Definition, the name appears in the Private App Tag column on the App Definition page.
 |
You can bulk add or delete Private App Tag(s) in one or more App Definitions. Select the App Definition(s) in the left column of the App Definitions page, and then select Edit Tags from the Private App Tag dropdown list. Renaming a tag is not supported.
 |
In the Edit Tags dialog box, choose to do a bulk add or bulk remove for the tags you will select next.
 |
Search for the Private App Tags by entering text in the search field, or select the tag from the dropdown list.
 |
When finished, click Save.
You can bulk add or delete Private App Tag(s) in one or more App Definitions. . Select the App Definition(s) in the left column of the App Definitions page, and then select Tag Manager from the Private App Tag dropdown list.
|
In the Manage Tags dialog box, search for the Private App Tags by entering text in the search field, or select the tag from the dropdown list.
 |
The Pencil icon allows you to rename the Private App Tag, and the Trash icon allows you to delete the tag. When finished, click Save.
When creating a new policy, or updating an existing policy, you have the option to select Private App Tags in addition to selecting Private Apps. For Destination, click on Private App Tags to select the tags you want to include in the policy.
 |
To steer traffic for private apps, you can add users or create a steering configuration that specifies an Organizational Unit (OU) or User Group.
OUs or User Groups are specified in the Real-time Protection policy that grants access to private apps.
If you do not already have a steering configuration that specifies the Organization Unit (OU) or User Group you want to steer to a private apps, follow these steps.
If you already have such a steering configuration, you can simply enable private apps for that steering configuration. For more details, refer to Change Steering Configurations to Include Private Apps.
- Go to Settings > Security Cloud Platform > Steering Configuration and click Create a New Configuration.
- In the New Configuration dialog box, enter and select the following settings:
- Configuration Name: Enter a meaningful name for this steering configuration.
- Organizational Unit (OU)/User Group. The dropdown/search field allows you to select and search for an OU or User Group.
- Traffic: Select Cloud Apps Only or All Web Traffic.
- Status: Change to Enabled.
- Private Apps: Change to Steer All Private Apps.
- Click Save.
To update a steering configuration for private apps, follow these steps:
- Go to Settings > Security Cloud Platform > Steering Configuration. Complete the following steps for each steering configuration that you want to steer to private apps. There are two methods:
- If you have just one Default steering configuration, you can use the Edit button in the top right corner.
- If you have multiple steering configurations, click the
icon on the right side of each configuration and select Edit Configuration.
- If you have just one Default steering configuration, you can use the Edit button in the top right corner.
- For Private Apps, change to Steer All Private Apps.
- Click Done.
