Manage Private Resources | Private Resources | Cisco Secure Access Help

Private resources are applications, networks, or subnets that are not publicly accessible from outside your network.

Private resources are applications, networks, or subnets that your organization controls. These resources are not publicly accessible from outside your network. Examples of private resources are:

Applications and services that run on-premises in your data center
Resources running on private clouds hosted from your data center

You can configure private network entities and add private resources in your Secure Access organization. Follow these steps to add a private resource and set up network connectivity to the resource, Then, set up profiles and certificates, add the private resources on the policy rules, and set up the Cisco Secure Client and distribute a URL to the private resource.

Warning
If you attach an empty private resource group to a policy, the entire rule containing the empty private resource is dropped.

Step 1: Set Up Private Resources

Configure end user connections to a private resource, and then add a private resource to a private resource group.

Understand your connection options.

Specify connection requirements for private resources where you want to allow access.

For more information, see Comparison of Zero Trust Access and VPN and Manage Branch Connections.
Add Private Resources.

Work with resource owners to gather the information needed to configure each resource. For more information, see Add Private Resources.
Add new Private Resources to Resource Connector Groups.

If your traffic connects through Resource Connectors rather than Network Tunnels, and you add a private resource after you add the resource connector group, you must add the new resource to a connector group. For more information, see Assign Private Resources to a Connector Group.
(Optional) Block zero-trust access to specified subdomains.

If you configure a Private Resource with an IP address having a leading wildcard (for example: *.example.com), you can block zero-trust connections to subdomains that you specify.

User devices must have the Cisco Secure Client deployed. For more information, see Using Wildcards to Configure Traffic Steering for Private Destinations.

If you have deployed the zero trust client on iOS devices, see unique matching information in the "Guidelines and Limitations" section of Set up the Zero Trust Access App for iOS Devices.
(Optional) Add Private Resource Groups.

To speed creation and management of access rules, and ensure consistent handling of related private resources, create groups of private resources that you want to manage as a unit. For more information, see Add Private Resource Groups.

Step 2: Set Up Network Connections, VPN Profiles, and Certificates

Note

To support decryption of traffic to private resources, you must enable global decryption. For more information, see Decryption.

Configure network connectivity for zero-trust connections.

Add Network Tunnel Groups or Resource Connectors to allow Secure Access to communicate with and direct traffic to your private resources. For more information, see Manage Network Connections.
Add VPN profiles.

To allow VPN connections to private resources, add VPN profiles to your organization. VPN configurations such as VPN traffic steering rules must exist for the applicable network address spaces. For more information, see Manage Virtual Private Networks.
Add and manage certificates for private resources.

Secure Access requires certificates in order to connect user traffic with your private resources and decrypt that traffic for inspection by the Intrusion Prevention System (IPS). You can upload the certificate for a resource when you configure the resource, or manage certificates from the certificate list. For more information, see Certificates for Private Resource Decryption.

Step 3: Add Private Resources in Policy Rules

Note

If an Access policy rule applies to traffic selected with the "Any" private destinations component, Secure Access does not evaluate the traffic using the DLP policy. Secure Access forwards the private traffic to the DLP engine only if an Access policy rule matches the traffic for the selected private resources or private resource groups.

Add private access rules to the Access policy or Real Time rules to the Data Loss Prevention (DLP) policy. After you add private resources to your organization, these resources are available for you to use as destinations in your policy rules. You can use private resources in your Access policy or DLP policy.

Add private access rules to the Access policy.

Private access rules define which users and devices can access the private resource in the organization. For more information, see Add a Private Access Rule.
Add Real Time rules to the Data Loss Prevention (DLP) policy.

Real-time DLP rules define the resources that the system scans for violations in HTTP/HTTPS and non-HTTP/non-HTTPS (such as SMB and FTP) traffic in both upload and download directions for all supported file types not including forms data. For more information, see Supported File and Form Types and Add a Real Time Rule to the Data Loss Prevention Policy.

Step 4: Set Up the Cisco Secure Client and Distribute URLs

Ensure that user devices are set up for client-based Zero Trust Access.

To configure resources for client-based zero-trust access, ensure that user devices meet the requirements for Zero Trust. You must have the Cisco Secure Client Zero Trust Access module deployed on the devices in your organization. For more information, see Zero Trust Access Requirements and Limitations.
Distribute URLs for browser-based Zero Trust Access.

Establish a system for making users aware of the special URLs needed for browser-based Zero Trust Access.

Add a Private Resource

Private resources are the applications, networks or subnets that are internal resources hosted in your data center. Private resources may include resources hosted on a private cloud in your data center or resources that have a login page that cannot be accessed from outside the network.

Configure a private resource with the connection information for the resource, then add access rules in the Access policy to determine which users and devices can access the resource using the connection methods that you have enabled.

For information on using Secure Access to learn about private resources based on your private network traffic, see Discover Private Resources.

Prerequisites: Add Private Resources

Have a full Admin user role. For more information, see Manage Accounts.
Gather IP or CIDR addresses for your private resources. Private resources cannot use IP addresses or networks listed in IP Address Restrictions.
If you specify resource addresses using fully-qualified domain names (FQDNs), add at least one internal DNS server that can route traffic to your resource. For more information, see Add DNS Servers.
For each resource, choose connection options. For descriptions of the options, see the topics under Manage Connections to Private Destinations.
If you enable Zero Trust Access for the resource:
- Meet the requirements in Requirements for Zero Trust Access.
- To allow client-based Zero Trust Access and inspect traffic using the Intrusion Prevention (IPS), file inspection, and file type blocking features, provide the resource's certificate to Secure Access so that Secure Access can display it to end-user devices.
- Cisco recommends using a certificate signed by a publicly recognized certificate authority (CA).
- If you enable browser-based zero trust access using SSH or Remote Desktop (RDP), see Allow SSH and RDP Access to Private Resources.
Plan your private resource configurations to avoid configuration conflicts such as unintentional duplicate or overlapping addresses.

For example, if a resource can be reached using multiple addresses, decide in advance whether you will create a single resource with multiple addresses or multiple resources. For more information about this particular scenario,z see Private Resource Configuration Examples.

Define a Private Resource

Configure a resource that is controlled by your organization.

Before you begin

Full Admin user role. For more information, see Manage Accounts.

Procedure

Navigate to Resources > Private Resources, and then click +Add.
For Private Resource Name, enter a meaningful name for the resource.
For Description, we recommend that you provide information such as the purpose of the resource or the name of the resource owner.

Private Resource Address

Provide the network address information for communicating with the private resource.

Before you begin

Full Admin user role. For more information, see Manage Accounts.

Procedure

Navigate to Resources > Private Resources.
For Internally reachable address, enter an IP address, FQDN, wildcard FQDN (in the format *.example.com), Network Objects, protocol, and port or port ranges.
You do not have to provide an address that is publicly accessible from outside the network.

If you will allow browser-based access to this resource by users who do not have the Cisco Secure Client installed on their devices, the protocol you select must include HTTP/HTTPS.

Use caution when adding addresses that duplicate or overlap with addresses in other configured private resources. If you will enable browser-based zero trust access using SSH or Remote Desktop (RDP) protocols, see Allow SSH and RDP Access to Private Resources.

If you will decrypt traffic to this resource, follow these guidelines.
- In each address line, you can specify a single IP address (no address ranges) or CIDR block, or a comma-separated list of addresses or CIDR blocks, or an FQDN with or without wildcard. Add addresses and FQDNs as separate lines.
  If the address includes a wildcard FQDN, the wildcard must be the first character in the address string (*.example.com).
  Specify a single port or "Any" port; no comma-separated port numbers, no port ranges.
  If you need to decrypt traffic to multiple ports for the same address, click + IP Address/FQDN and add a separate address line for each port.
  Select a protocol that includes TCP and does not include UDP.
  
  Example configurations:
If you enter a domain and Secure Access will route traffic to this resource using network tunnels, follow these guidelines.
- Select an internal DNS server that can route traffic to the specified resource address.
  
  To configure an internal DNS server, see Add DNS Servers.

Endpoint Connection Methods

Choose the connection methods to allow communications to the private resource. For more information, see Comparison of Zero Trust Access and VPN.

Note
If you do not allow Zero Trust Access or VPN connections for the private resource, only branch connections are enabled on the private resource. Branch connections are pre-selected for a private resource. For more information, see Manage Branch Connections.

You can allow any of these connection options:

Zero-trust connections
- Client-based connection—For devices with the Cisco Secure Client or the Zero Trust Access mobile application installed.
- Browser-based connection—For devices without the Cisco Secure Client or the Zero Trust Access mobile application installed, or when you only want to allow access using a browser.
VPN connections—For devices that allow VPN connections to the private resource.

Client-Based Zero-Trust Connections

Configure Zero Trust Access (ZTA) for end users that connect to destinations using the Secure Client.

You can allow connections to a private resource from devices for contractors or vendors, or Bring-Your-Own devices. To allow the devices that your organization does not manage to connect to a private resource, you must enable browser-based access.

Note

Before you begin

Procedure

Navigate to Resources > Destinations > Private Resources.
Enter the appropriate details for a private resouce; for more informationon prerequisites and steps, see Add a Private Resource
For the Endpoint Connection Method select zelect Zero-trust connections to allow connections from devices with and without the Secure Client installed.
For Client-based connection, enter the address you want users to use in order to connect to this resource. For best security (to keep the internal IP address of this resource private), you should provide a domain rather than an IP address. Your internal DNS server must be able to route traffic to this address. For example, you can enter mail.example.com.

Note
This address can be the same as the address you entered above for Secure Access to connect to the resource.
Continue creating the private resource and complete the VPN Connections section. For steps to complete this procedure and finalize your private resource, see for more information.

Browser-Based Zero-Trust Connections

Configure Zero Trust Access (ZTA) for end users that connect to destinations using the browser.

Browser-based (clientless) Zero Trust Access offers fewer security controls on devices than client-based Zero Trust Access.

Before you begin

The Allow unauthenticated pre-flight OPTIONS request function is currently Controlled availablility and must be manually enabled through your Cisco represenative or Cisco Support. Open a ticket and request this feature to initiate the Cross-Origin Resource Sharing (CORS) request. Here is an example of a CORS prelight request:

OPTIONS /doc HTTP/1.1
Host: bar.company.com
Origin: https://foo.company.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type
<..>

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://foo.company.com
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
<..>

You must have the following prerequisites completed prior to deploying:

The primary and secondary domains must already be defined as browser-based access applications and are allows in a policy. Only the secondary domain is requied to enable the Allow unauthenticated pre-flight OPTIONS request functionality.
It is expected that the foo.company.com (origin) domain is authenticated and has a valid authentication cookie via Browser-based Access for the CORS resource (bar.company.com) OPTIONS request to be allowed unauthenticated.
You must include this HTTP header as part of the HTTP response of the resource:
```
Access-Control-Allow-Credentials: true
```
Both requests foo.company.com (primary) and bar.company.com (secondary) must originate from the same source egress (public) IP.
In the HTTP response to the CORS resource, this HTTP header must be included: Access-Control-Allow-Credentials: true. The header enables the browser to add the authentication cookie for the GET request to the CORS resource request (after the OPTIONS preflight request succeeds).

Completeing the prerequisites listed above allows the following expected functionality:

GET foo.company.com. The first request gets directed ot the IdP and then Browser Access sets a cookie for the domain company.com after the authentication.
GET foo.company.com. An authentication cookie needs to be set for the secondary domain. The second request returns a fetch API to obtain resources from the secondary domain.
OPTIONS bar.company.com. When the Allow unauthenticated pre-flight OPTIONS request option is enabled on the secondary domain, the third request forwards to the destination without an auth cookie.

Procedure

Navigate to Resources > Destinations > Private Resources.
Enter the appropriate details for a private resource; for more information on prerequisites and steps, see Add a Private Resource.
For the Endpoint Connection Method select Zero-trust connections to allow connections from devices with and without the Secure Client installed.
For Browser-based connection, configure a public URL for the resource that you will give to users. You have the option to use either a Cisco domain or a custom domain. End users can reach a resource from outside their network. Secure Access forwards authorized connections to the resource.
Note
For browser-based ZTA, you must configure the network address of the private resource with these controls:
- For Internally reachable address, you must add either a single fully qualified domain (FQDN) or one or more IP addresses.
- For Protocol, you must choose either TCP - (HTTP,HTTPS) only, TCP – SSH or TCP – RDP.
- For Port / Ranges, you must add a single port number.
For more information, see Private Resource Address.
For Use a URL in your domain, complete the configuration of the components that are required to use your own custom domain for browser-based ZTA connections.
For Use a URL in a Cisco domain, provide a URL prefix that uniquely identifies this resource.

Secure Access will join the prefix to <your organization's tenant ID>-ztna.sse.cisco.io to form the public URL address. Secure Access will route traffic using this address to the resource.

If you don't provide a URL prefix, Secure Access adds one for you based on the resource name.
Provide a full URL from your custom domain name. The URL field supports domains (example.com) and subdomains (subdomain.example.com).
For Certificate-Key Pairs, choose from the list of cryptographic certificate-key pairs or click +Add certificate and key to upload .pem files or paste new certificate and key data.
You may also browse to Secure > Certificates and click the Private resources tab to upload and manage certificates used by private resources with browser-based ZTA.

Cisco recommends using a certificate signed by a publicly recognized certificate authority (CA).

The DNS server for your domain requires an additional canonical name (CNAME) record that maps your custom URL to the Secure Access URL provided in the field Your DNS server must be able to route this traffic to this address. Format the CNAME records as follows:
- Record type: CNAME
- @: subdomain.example.com
- Value: [custom-prefix]-[org ID].ztna.sse.cisco.io
Configure the protocol, Custom host header, Server Name Indication (SNI).
For Protocol, choose HTTPS or HTTP.
Add a custom host header if your resource requires it to validate HTTP or HTTPS connections.
Custom Host Header is optional for both a Cisco domain and a custom domain.
- If Protocol is set to HTTP and the Custom host header field is left empty, the host header is the same as the Public URL for this resource.
- If Protocol is set to HTTPS and both the Custom host header and Server Name Indication (SNI) fields are left empty, the host header is the same as the Public URL for this resource.
  - If the Server Name Indication (SNI) field has a value, the host header is the SNI value.
  - If end users typically use the fully qualified domain name (FQDN) to request the private resource, enter the FQDN for the private resource in the Server Name Indication (SNI) field.
For Server Name Indication (SNI), enter the hostname.

SNI is the hostname that the browser connects with to start a TLS handshake. If this resource shares a single IP address with other resources that present different certificates, enter the SNI hostname to connect traffic to this resource.

If the internally reachable address is an fully qualified domain name (FQDN), consider using the FQDN as the SNI. If the field is left blank, the SNI will not be used.

Secure Access recommends that you add the Server Name Indication (SNI) information for the browser-based ZTA connections.
Click Validate Application Certificate.

If you enable Decrypt Traffic for the private resource, Secure Access disables this certificate validation setting.

Validate Application Certificate is enabled by default.
Click Disable range header.

When you activate the Disable range header option, Secure Access ignores the HTTP Range header in the requests on the ZTA browser-based connections. Disabling the HTTP Range header prevents the reading of partial requests and ensures that incomplete or malicious files are not downloaded by end users.
Click Enable Web Socket Support to enable real-time browser communication by allowing Web Socket connections for the resource.

To enable web socket protocols, you must have TCP - (HTTP/HTTPS) only selected as the protocol.

Web Sockets come with unique security risks. Only enable web sockets if essential.

Enable Web Socket Support is disabled by default.
(Controlled Availability. Open a ticket with Cisco Support to enable this feature.) Click Allow unauthenticated pre-flight OPTIONS request to permit unauthenticated OPTIONS HTTP requests for the resource. This option allows a web server to explicitly grant permission for resources (such as fonts, scripts, or data) to be loaded from a domain different from the one that served the original web page. Browsers enforce the Same-Origin Policy (SOP) method by default which can prevent a script on one origin (e.g., https://site-a.com) from making requests to another origin (e.g., https://api.site-b.com). Enabling this setting provides a standardized way to bypass this restriction without risking security; with pre-flight OPTIONS the browser performs a preliminary check to ensure the request is genuine and free of malicious agents before allowing the request to pass.

Note
We do not recommend using the wildcard character ( * ) for authenticated requests.
Continue creating the private resource and complete the VPN Connections section. For steps to complete this procedure and finalize your private resource, see for more information.

VPN Connections

VPN connection allow endpoints to communicate to a private resource when connected to the network using VPN.

Note
If you enable both Zero Trust connections and VPN connections, users will connect to the resource using Zero Trust.

Before you begin

Full Admin user role. For more information, see Manage Accounts.

Procedure

Navigate to Resources > Private Resources.
Select VPN connections.

Resource Connector Groups

Associate the private resource with the Resource Connector Groups.

Before you begin

Full Admin user role. For more information, see Manage Accounts.

Procedure

Navigate to Resources > Private Resources.
(Optional) For Resource Connector Groups, choose the resource connector groups that can forward traffic to this resource.

Note
Before you can choose a Resource Connector Group, you must enable Zero Trust connections for this resource. You can also choose a connector group for this resource later, or assign resources on the Connector Group page.
Choose a group or groups that have deployed connectors, which are located in the same data center, branch office, or security zone as the resource.

For more detailed guidelines, or an alternative place to associate resources with connector groups, see Assign Private Resources to a Connector Group.

Decryption

For effective inspection of encrypted traffic, enable decryption on the private resource and enable global decryption. For information about enabling global decryption, see Manage Global Settings for Access Rules: Decryption.

Before you begin

Full Admin user role. For more information, see Manage Accounts.

Procedure

Navigate to Resources > Private Resources.
Navigate to Decryption and toggle on Decrypt Traffic.

Note
If you enable decryption, Secure Access disables the option to Validate application certificate for browser-based traffic, even if you have previously enabled it. This is expected.

Decryption is required in order to inspect traffic for threats using the Data Loss Prevention (DLP) policy, Intrusion Prevention (IPS), file inspection, and file type blocking. For security reasons, you should enable this option.

You can enable this option depending on the resource address. For details, see information about the Internally Reachable Address field.
Select a certificate or upload a new certificate.

Include all intermediate certificates in the certificate chain.

Only PEM encoding is supported.

Because traffic is routed through Secure Access, Secure Access must be able to display the resource's certificate to end-user devices.
1. If you have already uploaded the certificate for the private resource, click Select to choose the certificate from the drop-down menu.
  For information about uploading certificates in Secure Access, see Manage Certificates for Private Resource Decryption.
2. Click +Add certificate and key to upload or paste the application certificate (including both the public and private keys) used by the private resource.

View Access Rules Associated with a Private Resource

After you add a private resource in Secure Access, you can view the attributes of the private resource. The attributes of the private resource include the private access rules in the Access policy associated with the private resource.

Before you begin

A minimum user role of Read only. For more information, see Manage Accounts.

Procedure

Navigate to Resources > Private Resources.
Navigate to a row in the table of private resources.
1. Click the ellipsis (...) at the end of the row, choose Edit, and then navigate to Associated Rules.
2. Click on the name of a private resource and then navigate to Associated Rules.
  
  You can view and link to the access rules that are associated with the private resource.

What's Next

Test the connection between Secure Access and your private resources. For more information, see Test Private Resource Reachability.
(Optional) If you entered a FQDN of the format *.example.com and you want to exclude subdomains from the ability to connect to this resource, add exceptions to the Traffic Steering page. For more information, see Using Wildcards to Configure Traffic Steering for Private Destinations.
(Optional) You can exclude subdomains from this Private Resource configuration and then add one or more separate Private Resources and access rules to allow different access for those subdomains.
Configure requirements that you want to apply to this resource, such as endpoint requirements (using posture profiles) and Intrusion Prevention (IPS) profiles. For more information, see Components for Private Access Rules.
After you have configured other requirements, add policy rules to access this resource.
- Add private access rules to allow users and devices to access this resource. For more information, see Get Started With Private Access Rules.
- Allow DLP real-time rules to scan for violations in upload, download, or both upload and download traffic. For more information, see Add a Real Time Rule to the Data Loss Prevention Policy.
Note
If an Access policy rule applies to traffic selected with the "Any" private destinations component, Secure Access does not evaluate the traffic using the DLP policy. Secure Access forwards the private traffic to the DLP engine only if an Access policy rule matches the traffic for the selected private resources or private resource groups.
When you are ready for end-users to access the resource and you have enabled browser-based access, give your users the dummy URL that you configured in this procedure.

Discover Private Resources

Secure Access Private Resource Discovery monitors your VPN and Zero Trust Access (ZTA) traffic to help you identify frequently accessed resources and make informed configuration decisions. Based on this traffic monitoring, the feature provides a list of suggested destinations and a workflow for defining them as private resources.

For more information, refer to:

Procedure

To access the report, navigate to Monitor > Reports > Private Resource Discovery.

The report displays destinations accessed via your VPN and ZTA traffic.

Note
Data may take up to 24 hours to appear or refresh. If there is insufficient traffic over the past 30 days to generate suggestions, no further action is required.
When sufficient usage data is available, the Private Resource Discovery page provides the following tools:
- Time filter: Filter traffic for the last 24 hours, the last 7 days, or the last 30 days (default).
- Filter tiles: Update the view based on labels applied to suggestions.
- Search: Search by host address, protocol, or label.
- Export: Download the data as a CSV file.
- Column customization: Click the gear icon in the top-right corner of the table to select which columns to display.
The Suggestions table provides details for each discovered resource.
Table columns:
- Host Address: Displays the IP address or FQDN. Expand the entry to view multiple IP addresses routing to a single FQDN.
- Port / Protocol: The port and protocol used for the connection.
- # Sources: The number of unique sources. Users connecting via VPN or ZTA are counted as individual sources; users accessing resources via network tunnel groups are counted as a single source.
- Total Hits: The total access count. Hover over the number for details.
- Existing Private Resource: The private resource currently associated with the address, if any.
- First Seen / Last Seen: The timestamp of the first and most recent access.
- Label: Current status (e.g., Not reviewed, Added as private resource, Flag for review, Ignore). Labels are for reference only and do not affect traffic or configurations.
Click the View Suggestions arrow (→) or the notepad icon to open the slide-in menu for a specific suggestion. You can perform the following actions:
- Add as new Private Resource: Redirects you to the procedure for creating a new private resource. Refer to Add a Private Resource.
- Flag as an existing private resource: Associates the address with an existing resource for future review. This does not modify the resource configuration.
- Ignore suggestion: Applies the Ignore label to the suggestion.
Select multiple suggestions to enable the Bulk Actions menu. You can add selected suggestions as new or existing private resources, update their labels, or remove them from the list.

Map a Discovered Resource to Existing Private Resources

Secure Access automatically evaluates discovered private resources against your existing private resource definitions. This feature reduces the need for manual correlation by identifying resources that are already managed. This allows you to focus on new or unmanaged assets. By correlating discovery signals with your defined resources, Secure Access helps streamline least-privilege policy cleanup and prevents the creation of duplicate resource definitions.

For a resource to be considered mapped, the discovered attributes must align with the defined private resource based on the following criteria:

IP or CDR
Exact FQDN
FQDN (Wildcard)
Port and Protocol

Procedure

Navigate to Monitor > Reports > Private Resource Discovery.
Review the list of discovered private resources and their associated Matching Private Resource.
Locate the chosen resource and click the View Suggestions arrow (→) to review the Matching private resources section to identify potential matches.
You can perform the following actions:
- Add as new Private Resource: Redirects you to the procedure for creating a new private resource.
- Ignore suggestion: Applies the Ignore label to the suggestion.
Select a Label from the drop down list.
Enter any relevant Notes to provide context for the mapping.
(Optional) If not applicable, click Ignore suggestion to dismiss the match.

Test Private Resource Reachability

Test the connection between Secure Access and your private resources. View the details of an existing private resource, then verify Secure Access can reach it.

Before you begin

Reachability testing may only be used to test private resources with the following configuration:

Under Communication with Secure Access Cloud, one or more rows must have an internally reachable address with only a single FQDN or IP address.
- Internally reachable address fields with multiple FQDNs or IP addresses are not supported by reachability testing.
- Subnets, IP address ranges, and FQDN wildcards are not supported by reachability testing.
Protocol must include TCP. Reachability testing supports the protocol options TCP - (HTTP/HTTPS) only, Any TCP, and Any TCP, Any UDP.
Port / Ranges must be configured with one and only one port.
Under Endpoint Connection Methods, reachability testing only supports Zero-trust connections.

Procedure

Navigate to Resources > Private Resources.
In the Private Resources tab, click the name of an existing private resource with a Connection Method of Client-based ZTA or Browser-based ZTA. The resource detail menu will open to the right of the resource list.
Scroll to the bottom of the detail menu and click Test Reachability.
The Testing menu will show the name of the resource and the tests performed.
- Resource tested, all addresses reachable: Secure Access can reach your new private resource.
- Resource tested, no addresses reachable: Secure Access failed to reach your private resource due to one of the following error conditions. Follow the error message instructions to troubleshoot.
  - Check Private Resource configuration: This resource will be ready to test soon. Please try again in a few minutes.
  - Check for DNS resolution: Check your DNS server connectivity and configuration. For more information, see Manage DNS Servers. Note: Secure Access tests DNS resolution for an internally reachable FQDN but skips this test for an internally reachable IP address.
  - Check TCP connection:
    - Unable to forward traffic to the resource: Check your Resource Connector Group and the connector configurations, or your network configuration and resource. For more information, see Assign Private Resources to a Connector Group.
    - '[Network Tunnel Group-name]' was unable to route traffic to this resource: Check your Network Tunnel Group and tunnel configurations to ensure that traffic from tunnels can reach the resource. For more information, see Manage Network Tunnel Groups.
    - No connectivity to this resource was found: Either associate a Resource Connector Group with this resource or configure a Network Tunnel Group that can route traffic to this resource. For more information, see Assign Private Resources to a Connector Group and Manage Network Tunnel Groups.
When you add a new private resource or edit one that satisfies the prerequisites for reachability testing, you will see the option to Save and Test or Save.

If you click Save and Test, the main Private Resources menu will display a banner when the private resource is ready to be tested. It can take two minutes before a private resource is ready to be tested.

The banner will persist until an administrator tests reachability with a result of Resource tested, all addresses reachable for all resources that are ready to be tested.

If any resources fail the reachability test, they will remain ready for testing in the banner menu.

If an administrator dismisses the banner by clicking Dismiss or X, the banner will reappear when the page is reloaded.

Add a Private Resource Group

You can create private resource groups with private resources and use these components as destinations in private access rules in your Access policy, or in real-time rules in a DLP policy. Private resource groups enable you to apply access rules consistently to all resources in the group.

Warning
If you attach an empty private resource group to a policy, the entire rule containing the empty private resource is dropped.

Configure a resource group with the private resources in your organization.

Before you begin

Full Admin user role. For more information, see Manage Accounts.

Procedure

Navigate to Resources > Private Resources.
Choose Private Resource Groups, and then click +Add.
For Private Resource Group Name, enter a meaningful name for the resource group.
For Description, we recommend that you provide information about the purpose of the resource group.

Note
The description is optional.
For Choose Resources, add the resources to the group.
1. For Copy from existing private resource group, choose a resource group name to add the resources in that group to your new resource group.
2. For Choose Private Resources, check the resources and click the arrow (greater than sign) to add the selected resources to the group.
Click Save.

Private Resource Configuration Examples

Private Resource Located in Multiple Locations

Use these examples for configuring private resources when using Resource Connector Groups to connect traffic.

Suppose you have a private resource Application1 deployed in Location1 and Location2:

If users will access using browser-based connections, create a separate private resource for each location.
If users access the resource using different IP addresses in Location1 and Location2:

Configure a separate private resource for each resource location, and associate each private resource with a resource connector group in the appropriate region.
If the private resource is defined using an FQDN that is common to Location1 and Location2:

Configure a single private resource and associate the resource with different connector groups in different regions if applicable.
If the private resource is accessed in both locations using the same IP address:

Configure a single private resource and associate the resource with different connector groups in different regions if applicable.
If the private resource is defined with multiple IP addresses, and it is accessible in any location using any of the addresses:

Configure a single private resource with multiple entries for "Internally reachable address." Associate the resource with different connector groups in different regions if applicable.

Catch-All Private Resource to Prevent Exposing Internal Networks

Connection requests by remote devices, including requests for private resources, are typically resolved using public DNS, exposing information about those requests to the public internet. Connection requests for private destinations that are enabled for client-based Zero Trust Access do not go through public DNS and thus do not expose this information.

To avoid exposing information about your network to the public internet via DNS requests:

Add a private resource for your namespace, following the model *.example.com, for Any TCP, Any UDP, for all ports, and enable client-based Zero Trust Access for this resource. This creates a traffic steering rule that routes all client-based traffic to any destination in your namespace through Zero Trust Access. You do not need to create an access rule specifically for this resource, because the default private access rule will block access unless another access rule applies.