> For the complete MongoDB documentation index, see www.mongodb.com/docs/llms.txt ... comments. Available tabs: other tabs: AWS PrivateLink, Azure Private Link, GCP Private Service Connect --> # Troubleshoot Private Endpoint Connection Issues Non-port-mapped GCP private endpoints are deprecated and will be disabled on **April 30, 2027**. After this date, you will not be able to create new non-port-mapped endpoints and existing endpoints will stop working. Create new GCP endpoint services that use port-mapping architecture to reduce IP usage and improve scalability. To learn how to convert legacy endpoints to port-mapping, see [Converting Legacy Private Endpoints to use Port Mapping Architecture](https://www.mongodb.com/docs/atlas/security-private-endpoint.md#std-label-gcp-convert-legacy-to-port-mapping). **Note:** This page applies to both Atlas Infinite and Atlas Core. Review the sections on this page to diagnose and resolve common private endpoint connection issues. ## Dedicated Clusters ### AWS PrivateLink 1. Check the status of your AWS PrivateLink connections. To view the status of each private endpoint: In Atlas, go to the Database & Network Access page for your project. If it's not already displayed, select the organization that contains your project from the Organizations menu in the navigation bar. If it's not already displayed, select your project from the Projects menu in the navigation bar. In the sidebar, click Database & Network Access under the Security heading. The [Database & Network Access](https://cloud.mongodb.com/go?l=https%3A%2F%2Fcloud.mongodb.com%2Fv2%2F%3Cproject%3E%23%2Fsecurity%2Fnetwork%2FaccessList) page displays. In the sidebar, click Private Endpoint. Review the statuses. The Atlas Endpoint Service Status and Endpoint Status fields show the status of each private endpoint. Refer to the following statuses to help you determine the state of your private endpoint connections: Atlas Endpoint Service Status | Status | Description | | --- | --- | | Creating private link | Atlas is creating the network load balancer and VPC (Virtual Private Cloud) resources. | | Failed | A system failure has occurred. | | Available | The Atlas network load balancer and VPC (Virtual Private Cloud) endpoint service are created and ready to receive connection requests. | | Deleting | Atlas is deleting the private endpoint service. | Endpoint Status | Status | Description | | --- | --- | | Not configured | Atlas created the network load balancer and VPC (Virtual Private Cloud) endpoint service, but AWS (Amazon Web Services) hasn't yet created the [interface endpoint](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-interface-endpoint). Click Edit and complete the wizard to create the interface endpoint. | | Pending acceptance | AWS (Amazon Web Services) has received the connection request from your [interface endpoint](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-interface-endpoint) to the Atlas VPC (Virtual Private Cloud) endpoint service. | | Pending | AWS (Amazon Web Services) is establishing the connection between your [interface endpoint](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-interface-endpoint) and the Atlas VPC (Virtual Private Cloud) endpoint service. | | Failed / Rejected | AWS (Amazon Web Services) failed to establish a connection between Atlas VPC (Virtual Private Cloud) resources and the [interface endpoint](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-interface-endpoint) in your VPC (Virtual Private Cloud). This status may appear as Failed or Rejected depending on the failure reason. Common causes include: Missing region from the accepted endpoint regions list; Incorrect VPC Endpoint ID; Transient AWS (Amazon Web Services) issues If you have confirmed that your configuration is correct and the failure may be due to temporary AWS (Amazon Web Services) delays, you can use the Retry button in the Atlas UI to retry the connection. If the issue persists, click Edit to correct the endpoint ID, or verify that the endpoint's region is included in the accepted endpoint regions. To learn more about troubleshooting failed endpoints, see [Troubleshoot Private Endpoint Connection Issues.](https://www.mongodb.com/docs/atlas/troubleshoot-private-endpoints.md#std-label-pl-troubleshooting) IMPORTANT: If your Interface Endpoint fails, you might see the following message: `No dns entries found for endpoint vpce-, your endpoint must be provisioned in at least one subnet. Click "Edit" to fix the problem.` This message indicates that you didn't specify a subnet when you created the AWS PrivateLink connection. To resolve this error: Click Edit.Click Back.Specify at least one subnet.Follow the remaining instructions to create the AWS PrivateLink connection. | | Available | Atlas VPC (Virtual Private Cloud) resources are connected to the [interface endpoint](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-interface-endpoint) in your VPC (Virtual Private Cloud). You can connect to Atlas clusters in this region using AWS PrivateLink. | | Deleting | Atlas is removing the interface endpoint from the private endpoint service. | 2. Make sure that your security groups are configured properly. For each resource that needs to connect to your Atlas clusters using AWS PrivateLink, the resource's security group must allow outbound traffic to the [interface endpoint's](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-interface-endpoint) private IP addresses on all ports (1024-65535). See [Adding Rules to a Security Group](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html#adding-security-group-rule) for more information. Your [interface endpoint](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-interface-endpoint) security group must allow inbound traffic on all ports from each resource that needs to connect to your Atlas clusters using AWS PrivateLink. [Access List instance IP addresses or security groups](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html#adding-security-group-rule) to allow traffic from them to reach the [interface endpoint](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-interface-endpoint) security group. ### Cross-Region Private Endpoint Issues The following sections describe common issues with cross-region private endpoint connectivity and how to resolve them. #### Endpoint Submission Failure (Missing Region) If you forgot to specify the region where the consumer endpoint is located during submission, the endpoint status in Atlas transitions to Failed or Rejected because the endpoint service cannot locate and accept the connection. To resolve this issue: 1. Add the missing region to accepted endpoint regions. Add the missing region to the list of accepted endpoint regions. To learn more, see [Manage Accepted Endpoint Regions.](https://www.mongodb.com/docs/atlas/security-private-endpoint.md#std-label-manage-accepted-endpoint-regions) 2. Retry the connection. After you add the region, return to the endpoint service card and click the Retry button next to the failed endpoint entry. **Warning:** Do not delete a failed endpoint if it is the only endpoint registered with that private endpoint service. If you delete the last endpoint, the entire endpoint service is automatically deleted, and you must restart the entire configuration process. #### Endpoint Submission Failure (Incorrect Endpoint ID) If you submit an incorrect AWS (Amazon Web Services) VPC Endpoint ID (for example, a typo or an ID from a different service or VPC), the endpoint status in Atlas transitions to Failed or Rejected because the endpoint service cannot locate and accept the connection. You can resolve this issue using one of the following methods. To correct the ID on the existing endpoint entry: 1. Locate the failed endpoint. On the endpoint service card, locate the failed endpoint entry. 2. Edit the endpoint ID. Click the Edit button in the Actions column. In the modal, update the VPC Endpoint ID field with the correct ID. Click Save to update the ID. Atlas attempts to accept the correct endpoint. To replace the failed entry with a new endpoint instead: 1. Add a new endpoint with the correct ID. Add a new endpoint using the correct endpoint ID. To learn more, see [Set Up a Private Endpoint for a Dedicated Cluster.](https://www.mongodb.com/docs/atlas/security-cluster-private-endpoint.md#std-label-cluster-private-endpoint) 2. Delete the failed endpoint. After the correct endpoint is successfully accepted (status displays as Available), you can delete the failed endpoint entry. **Warning:** Do not delete a failed endpoint if it is the only endpoint registered with that private endpoint service. If you delete the last endpoint, the entire endpoint service is automatically deleted, and you must restart the entire configuration process. #### Endpoint Submission Failure (Transient or Unknown Error) If an endpoint submission fails and you have already verified that: - The necessary region is included in the accepted endpoint regions for the private endpoint service. - The submitted endpoint ID is correct and corresponds to the VPC endpoint you created in AWS (Amazon Web Services). The failure might be due to a transient AWS (Amazon Web Services) issue or an error in the initial acceptance process. **Note:** Even after the endpoint is in the Pending Acceptance state in AWS (Amazon Web Services), there might be a slight delay for all background resources to update. Cross-region endpoints, in particular, might take an additional 30 seconds to become discoverable by the Atlas endpoint service in a different region. To resolve this issue: 1. Locate the failed endpoint. On the endpoint service card, locate the failed endpoint entry (status displays as Failed or Rejected). 2. Retry the connection. Click the Retry button in the Actions column to attempt to establish the connection again. **Warning:** Do not delete a failed endpoint if it is the only endpoint registered with that private endpoint service. If you delete the last endpoint, the entire endpoint service is automatically deleted, and you must restart the entire configuration process. ### Obtain Private IPs with DNS Lookup When a client in your VPC (Virtual Private Cloud) connects to an Atlas cluster using one of these private endpoint-aware connection strings, the client attempts to establish a connection to the load balancer in the Atlas VPC (Virtual Private Cloud) through one of the [interface endpoints](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-interface-endpoint). Your client's DNS (Domain Name System) resolution mechanism handles which of the interface endpoints the hostname resolves to. If one interface endpoint is unavailable the next is used. This is opaque to the driver or other connection mechanism. The driver is only aware of the hostname in the SRV record or in the connection string. **SRV Record for DNS Seedlist Private Endpoint-Aware Connection Strings** The following example shows the SRV record for an AWS PrivateLink -enabled single-region cluster, showing three unique ports defined for `pl-0-us-east-1.k45tj.mongodb.net`: ```sh $ nslookup -type=SRV _mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net Server: 127.0.0.53 Address: 127.0.0.53#53 Non-authoritative answer: _mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net service = 0 0 1026 pl-0-us-east-1.k45tj.mongodb.net. _mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net service = 0 0 1024 pl-0-us-east-1.k45tj.mongodb.net. _mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net service = 0 0 1025 pl-0-us-east-1.k45tj.mongodb.net. ``` In the preceding example: - `_mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net` is the SRV record that the `mongodb+srv://cluster0-pl-0.k45tj.mongodb.net` connection string references. - `pl-0-us-east-1.k45tj.mongodb.net` is the hostname for each node in one Atlas cluster in one region for which you have configured AWS PrivateLink. - `1024`, `1025`, and `1026` are unique ports that Atlas assigns on the load balancer for each Atlas replica set node in the region for which you enabled AWS PrivateLink. All nodes in an Atlas replica set are accessible via the same hostname, with the load balancer resolving individual nodes by their unique port. **Hostname DNS Resolution in Private Endpoint-Aware Connection Strings and SRV Records** The hostname in the SRV record and the standard connection string is a DNS (Domain Name System) Canonical Name (`CNAME`) record that resolves to the endpoint-specific regional DNS (Domain Name System) name that AWS (Amazon Web Services) generates for the interface endpoint. A DNS (Domain Name System) `ALIAS` record exists for each subnet in your VPC (Virtual Private Cloud) that you deployed the interface endpoint to. Each `ALIAS` record contains the private IP address of the [interface endpoint](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-interface-endpoint) for that subnet. The following example shows the DNS (Domain Name System) lookup for the hostname in the SRV record and in the standard connection string, including the endpoint-specific regional DNS (Domain Name System) name for the interface endpoint and its DNS (Domain Name System) `ALIAS` records: ```sh $ nslookup pl-0-us-east-1.k45tj.mongodb.net Server: 127.0.0.53 Address: 127.0.0.53#53 Non-authoritative answer: pl-0-us-east-1.k45tj.mongodb.net canonical name = vpce-024f5b57108c8d3ed-ypwbxwll.vpce-svc-02863655456245e5c.us-east-1.vpce.amazonaws.com. Name: vpce-024f5b57108c8d3ed-ypwbxwll.vpce-svc-02863655456245e5c.us-east-1.vpce.amazonaws.com Address: 10.0.30.194 Name: vpce-024f5b57108c8d3ed-ypwbxwll.vpce-svc-02863655456245e5c.us-east-1.vpce.amazonaws.com Address: 10.0.20.54 ``` ### Connection Refused Because There are Too Many Open Connections - If your connections exceed the connection limits for your [cluster service limit](https://www.mongodb.com/docs/atlas/reference/atlas-limits/#connection-limits-and-cluster-tier), you should increase the cluster tier. - If your connection count is significantly higher than your expected connection count, see section below [Gather More Information on the Client Making the Most Connections.](https://www.mongodb.com/docs/atlas/troubleshoot-private-endpoints.md#std-label-pl-troubleshoot-gather-info) - E.g. enforcement on a sharded cluster v7.0.22 using load balanced optimized connection string. ```text $ mongosh "mongodb+srv://aws-replica-set-7-pl-0-lb.22qdu.mongodb-dev.net/" --apiVersion 1 --username sarah Enter password: ***** Current Mongosh Log ID: 68910f1754be6d9adc74e399 Connecting to: mongodb+srv://@aws-replica-set-7-pl-0-lb.22qdu.mongodb-dev.net/?appName=mongosh+2.5.6 MongoNetworkError: Client network socket disconnected before secure TLS connection was established ``` **Output:** ```text {"t":{"$date":"2025-08-04T19:48:17.649+00:00"},"s":"I", "c":"NETWORK", "id":22942, "ctx":"listener","msg":"Connection refused because there are too many open connections","attr":{"remote":"54.172.143.8:33205", "isLoadBalanced":false,"uuid":{"uuid":{"$uuid":"e52e9c14-7648-430a-bc2e-95292347b7e0"}}, "connectionId":380,"connectionCount":58}} ``` ### Viewing the Client Source IP - You can view the client source IP in the mongos logs for sharded clusters connecting via Private Endpoints. - You can view the client source IP in the mongod logs for replica sets connecting via Private Endpoints. - You can view the client source IP in the audit logs for both replica sets and sharded clusters connecting via Private Endpoints. - This functionality is supported on AWS for the following versions: - 8.1 and v8.1.0+ - 8.0 and v8.0.10+ - 7.0 and v7.0.22+ - The origin client IP address and port is indicated by the `sourceClient` field. That value is `10.50.4.23` in the above example. ```text {"t":{"$date":"2025-07-21T12:15:42.123+00:00"},"s":"I","c":"NETWORK", "id":22943,"ctx":"listener","msg":"Connection accepted","attr":{"remote":"192.168.100.55:31245", "isLoadBalanced":true,"sourceClient":"10.50.4.23:50123","uuid":{"uuid":{"$uuid":"12345678-abcd-4321-abcd-87654321abcd"}}, "connectionId":345,"connectionCount":19}} ``` ### Gather More Information on the Client Making the Most Connections Gathering these details requires using the [jq tool](https://www.mongodb.com/docs/manual/reference/log-messages/#log-parsing-examples), which can be downloaded from the [jq website.](https://jqlang.github.io/jq/) #### Connections created from the client metadata The following query provides the number of connections created from a particular client IP address. You can collect the exact source VPC Private IP address using the attribute `sourceClient`. ```text grep 'Connection accepted' mongod.log | jq -r '(.attr.sourceClient // .attr.remote)' | awk -F: '{print $1}' | sort | uniq -c | sort -rn ``` **Output:** ```text 25957 192.168.254.155 25957 192.168.253.161 25957 192.168.248.236 14420 10.70.2.254 14420 10.70.2.116 ``` #### Drivers used by the applications to connect to the cluster The following query provides the number of connections created by each driver. This is useful in scenarios where customers might use different drivers for different applications. ```text more mongodb.log| grep 'NETWORK' | jq -r '.attr.doc.driver.name' | grep -v null | sort | uniq -c | sort -rn ``` **Output:** ```text 56447 mongo-go-driver 21633 mongo-java-driver|sync 75 mongo-java-driver|sync|Airbyte 4 nodejs|Mongoose ``` For a more detailed analysis of connection counts and driver details, you can use the following Python script, which provides comprehensive information on the number of connections created and terminated, along with the driver names and version details. ```text import json import sys def process_log_file(json_file_path): # Dictionary to store the filtered data filtered_data = {} with open(json_file_path, "r") as json_file: # Read the file line by line for line in json_file: # Parse each line as a separate JSON object data = json.loads(line) if 'msg' in data and data['msg'] == 'client metadata': # Extract the relevant data from the JSON object drivername = data['attr']['doc']['driver']['name'] driverversion = data['attr']['doc']['driver']['version'] connectionid = data['ctx'] # Create a unique key for the driver based on name and version driver_key = (drivername, driverversion) # Add the connection ID to the driver's set of connections if driver_key not in filtered_data: filtered_data[driver_key] = {'connections': set(), 'opencount': 0, 'closedcount': 0} filtered_data[driver_key]['connections'].add(connectionid) filtered_data[driver_key]['opencount'] += 1 if 'msg' in data and data['msg'] == 'Connection ended': connectionid = data['ctx'] # Check if the connection ID exists in any driver's connections for driver_data in filtered_data.values(): if connectionid in driver_data['connections']: driver_data['closedcount'] += 1 driver_data['connections'].remove(connectionid) # Print the filtered data for each driver for driver_key, driver_data in filtered_data.items(): print('Driver:', driver_key) print('Connection Opened:', driver_data['opencount']) print('Connection Closed:', driver_data['closedcount']) if __name__ == '__main__': # Check if a JSON file argument is provided if len(sys.argv) < 2: print("Please provide the path to a JSON file as an argument.") sys.exit(1) # Extract the JSON file path from the command-line arguments json_file_path = sys.argv[1] # Process the log file process_log_file(json_file_path) ``` **Output:** ```text Driver: ('mongo-go-driver', 'v1.12.0-cloud') Connection Opened: 14368 Connection Closed: 14362 Driver: ('mongo-go-driver', 'v1.12.1') Connection Opened: 42056 Connection Closed: 41958 Driver: ('mongo-java-driver|sync', '4.11.1') Connection Opened: 18012 Connection Closed: 17987 Driver: ('mongo-java-driver|sync', '4.8.2') Connection Opened: 3621 Connection Closed: 3610 Driver: ('nodejs|Mongoose', '4.17.1|6.12.0') Connection Opened: 3 Connection Closed: 1 Driver: ('mongo-go-driver', 'v1.13.0') Connection Opened: 23 Connection Closed: 20 Driver: ('mongo-java-driver|sync|Airbyte', '4.11.0') Connection Opened: 75 Connection Closed: 75 Driver: ('nodejs|Mongoose', '4.17.2|6.13.0') Connection Opened: 1 Connection Closed: 0 ``` #### Application names used by client applications to connect to the cluster We can suggest that customers include the application name in the connection string to specify different applications connecting to the cluster. By using the `appName`, we can identify which application is creating many connections to the cluster in the future. See the [Miscellaneous Configuration](https://www.mongodb.com/docs/v6.2/reference/connection-string/#miscellaneous-configuration) section of our documentation for more details on using the `appName` in the connection string. Additionally, you can use the `db.currentOp().appname` command to see the current operations associated with the application name. The following query provides details of the `appName` with the number of connections created by that particular application. ```text more mongodb.log| grep 'NETWORK' | jq -r '.attr.doc.application.name' | grep -v null | sort | uniq -c | sort -rn ``` **Output:** ```text 10809 niyo-*******-api 8616 MongoDB CPS Module v13.17.2.8878 (git: 70c0b932f47f4f0b3e82a75e223f39ed9635b47f) 7203 niyo-ns***** 5752 MongoDB Automation Agent v13.17.2.8878 (git: 70c0b932f47f4f0b3e82a75e223f39ed9635b47f) 3601 *****-auth-service ``` The provided details help to pinpoint the specific factors contributing to the high number of connections. By analyzing Source Client IP, client metadata, driver usage, and application names, you can identify which elements are responsible for the increased connections and determine the necessary areas to investigate. This targeted approach allows you to disregard other less relevant factors and concentrate on addressing the issues with the highlighted information, ultimately streamlining the mitigation process and enhancing cluster performance. ### Multi-Region Private Endpoints Private endpoints are only available in multi-region clusters if there is a node within each region that the cluster spans that has a private endpoint configured. To learn more about configuring multi-region private endpoints, see [Regionalized Private Endpoints for Multi-Region Sharded Clusters.](https://www.mongodb.com/docs/atlas/security-private-endpoint.md#std-label-atlas_regionalized-pl) **Connection String Indexing for Multi-Region Clusters** After you configure a private endpoint for a new region and deploy cluster nodes to that region, you might see the following error when you use your private endpoint to connect to the cluster: ```none DNSHostNotFound: Failed to look up service "" ``` This error occurs when your connection string's index automatically changes and your client subsequently restarts, which causes an SRV DNS lookup. The private endpoint connection string for a multi-region cluster uses an index of `0`. If your connection string uses a different index, MongoDB automatically updates the connection string to use the `0` index. For example, you might configure two private endpoints for a region. If you remove the first private endpoint, your connection string uses an index of `1` and resembles the following: ```none mongodb+srv://cluster1-psc-0.4uyx2d.mongodb.net ``` Then, suppose you configure a private endpoint for a new region in your cluster and subsequently add cluster nodes to that region. Your cluster now includes multiple regions, and your connection string updates to use an index of `0`: ```none mongodb+srv://cluster1-psc-1.4uyx2d.mongodb.net ``` To avoid potential connectivity issues after your client's next restart, confirm that you are using the zero-indexed private endpoint connection string to connect to your cluster. You can access the updated private endpoint connection string from the Atlas UI or API after your cluster changes complete. ### Test Connectivity from Your Deployed Application You can use the tools `nslookup` and `telnet` to test the connectivity from your application to your Private Endpoint in Atlas. 1. Get the connection details for your Atlas cluster. Run `nslookup` with the `-type=SRV` flag to get the port numbers associated with each of the nodes in your cluster. ```bash nslookup -type=SRV _mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net ``` **Output:** ```bash Server: 127.0.0.53 Address: 127.0.0.53#53 Non-authoritative answer: _mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net service = 0 0 1026 pl-0-us-east-1.k45tj.mongodb.net. _mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net service = 0 0 1024 pl-0-us-east-1.k45tj.mongodb.net. _mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net service = 0 0 1025 pl-0-us-east-1.k45tj.mongodb.net. ``` 2. Test the connectivity. From your application environment, with one of the listed ports (for example, `1026`, `1024` or `1025` in the example output above), run the following `telnet` command to test connectivity: ```bash telnet pl-0-.mongodb.net 1024 telnet pl-0-.mongodb.net 1025 telnet pl-0-.mongodb.net 1026 ``` ### Azure Private Link To view the status of each private endpoint: 1. In Atlas, go to the Database & Network Access page for your project. If it's not already displayed, select the organization that contains your project from the Organizations menu in the navigation bar. If it's not already displayed, select your project from the Projects menu in the navigation bar. In the sidebar, click Database & Network Access under the Security heading. The [Database & Network Access](https://cloud.mongodb.com/go?l=https%3A%2F%2Fcloud.mongodb.com%2Fv2%2F%3Cproject%3E%23%2Fsecurity%2Fnetwork%2FaccessList) page displays. 2. In the sidebar, click Private Endpoint. 3. Review the statuses. The Atlas Endpoint Service Status and Endpoint Status fields show the status of each private endpoint. Refer to the following statuses to help you determine the state of your private endpoint connections: Atlas Endpoint Service Status | Status | Description | | --- | --- | | Creating private link | Atlas is creating the load balancer and VNet resources. | | Failed | A system failure has occurred. | | Available | Atlas created the load balancer and Azure Private Link Service. The Azure Private Link Service is ready to receive connection requests. | | Deleting | Atlas is deleting the Azure Private Link Service. | Endpoint Status | Status | Description | | --- | --- | | Not configured | Atlas created the load balancer and Azure Private Link Service, but you haven't created a private endpoint yet. Click Edit and complete the wizard to create the private endpoint. | | Initiating | Atlas has not yet accepted the connection to your private endpoint. | | Failed | Azure (Microsoft Azure) failed to establish a connection between Atlas VNet resources and the private endpoint in your VNet. Click Edit, verify that the information you provided is correct, and then create the private endpoint again. | | Available | Atlas VNet resources are connected to the private endpoint in your VNet. You can connect to Atlas clusters in this region using Azure Private Link. | | Deleting | Atlas is removing the private endpoint connection from the Azure Private Link Service. | **Warning:** Do not delete a failed endpoint if it is the only endpoint registered with that private endpoint service. If you delete the last endpoint, the entire endpoint service is automatically deleted, and you must restart the entire configuration process. ### Obtain Private IPs with DNS Lookup When a client in your VNet connects to an Atlas cluster using one of these private endpoint-aware connection strings, the client attempts to establish a connection to the Private Link Service in the Atlas VNet through the private endpoint's network interface. The Private Link service sends traffic through an Azure (Microsoft Azure) Standard Load Balancer to the Atlas cluster nodes that you deployed in that region. Your client's DNS (Domain Name System) resolution mechanism handles resolving the hostname to the network interface's private IP address. The driver is only aware of the hostname in the connection string, listening on one port for each node in the cluster's replica set. **SRV Record for DNS Seedlist Private Endpoint-Aware Connection Strings** The following example shows the SRV record for an Azure Private Link-enabled single-region cluster, showing three unique ports defined for `pl-0-eastus2.uzgh6.mongodb.net`: ```sh $ nslookup -type=SRV _mongodb._tcp.cluster0-pl-0.uzgh6.mongodb.net Server: 127.0.0.53 Address: 127.0.0.53#53 Non-authoritative answer: _mongodb._tcp.cluster0-pl-0.uzgh6.mongodb.net service = 0 0 1024 pl-0-eastus2.uzgh6.mongodb.net. _mongodb._tcp.cluster0-pl-0.uzgh6.mongodb.net service = 0 0 1025 pl-0-eastus2.uzgh6.mongodb.net. _mongodb._tcp.cluster0-pl-0.uzgh6.mongodb.net service = 0 0 1026 pl-0-eastus2.uzgh6.mongodb.net. ``` In the preceding example: - `_mongodb._tcp.cluster0-pl-0.uzgh6.mongodb.net` is the SRV record that the connection string references. - `pl-0-eastus2.uzgh6.mongodb.net` is the hostname for each node in one Atlas cluster in one region for which you have configured Azure Private Link. - `1024`, `1025`, and `1026` are unique ports that Atlas assigns on the load balancer for each Atlas replica set node in the region for which you enabled Azure Private Link. All nodes in an Atlas replica set are accessible via the same hostname, with the load balancer resolving individual nodes by their unique port. **Hostname DNS Resolution in Private Endpoint-Aware Connection Strings and SRV Records** The hostname in the SRV record and the standard connection string is a DNS (Domain Name System) `A` record that resolves to the private IP address of the private endpoint's network interface. The following example shows the DNS (Domain Name System) lookup for the hostname in the SRV record and in the standard connection string: ```sh $ nslookup pl-0-eastus2.uzgh6.mongodb.net Server: 127.0.0.53 Address: 127.0.0.53#53 Non-authoritative answer: Name: pl-0-eastus2.uzgh6.mongodb.net Address: 10.0.0.4 ``` ### Multi-Region Private Endpoints Private endpoints are only available in multi-region clusters if there is a node within each region that the cluster spans that has a private endpoint configured. To learn more about configuring multi-region private endpoints, see [Regionalized Private Endpoints for Multi-Region Sharded Clusters.](https://www.mongodb.com/docs/atlas/security-private-endpoint.md#std-label-atlas_regionalized-pl) **Connection String Indexing for Multi-Region Clusters** After you configure a private endpoint for a new region and deploy cluster nodes to that region, you might see the following error when you use your private endpoint to connect to the cluster: ```none DNSHostNotFound: Failed to look up service "" ``` This error occurs when your connection string's index automatically changes and your client subsequently restarts, which causes an SRV DNS lookup. The private endpoint connection string for a multi-region cluster uses an index of `0`. If your connection string uses a different index, MongoDB automatically updates the connection string to use the `0` index. For example, you might configure two private endpoints for a region. If you remove the first private endpoint, your connection string uses an index of `1` and resembles the following: ```none mongodb+srv://cluster1-psc-0.4uyx2d.mongodb.net ``` Then, suppose you configure a private endpoint for a new region in your cluster and subsequently add cluster nodes to that region. Your cluster now includes multiple regions, and your connection string updates to use an index of `0`: ```none mongodb+srv://cluster1-psc-1.4uyx2d.mongodb.net ``` To avoid potential connectivity issues after your client's next restart, confirm that you are using the zero-indexed private endpoint connection string to connect to your cluster. You can access the updated private endpoint connection string from the Atlas UI or API after your cluster changes complete. ### Test Connectivity from Your Deployed Application You can use the tools `nslookup` and `telnet` to test the connectivity from your application to your Private Endpoint in Atlas. 1. Get the connection details for your Atlas cluster. Run `nslookup` with the `-type=SRV` flag to get the port numbers associated with each of the nodes in your cluster. ```bash nslookup -type=SRV _mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net ``` **Output:** ```bash Server: 127.0.0.53 Address: 127.0.0.53#53 Non-authoritative answer: _mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net service = 0 0 1026 pl-0-us-east-1.k45tj.mongodb.net. _mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net service = 0 0 1024 pl-0-us-east-1.k45tj.mongodb.net. _mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net service = 0 0 1025 pl-0-us-east-1.k45tj.mongodb.net. ``` 2. Test the connectivity. From your application environment, with one of the listed ports (for example, `1026`, `1024` or `1025` in the example output above), run the following `telnet` command to test connectivity: ```bash telnet pl-0-.mongodb.net 1024 telnet pl-0-.mongodb.net 1025 telnet pl-0-.mongodb.net 1026 ``` ### GCP Private Service Connect To view the status of each private endpoint: 1. In Atlas, go to the Database & Network Access page for your project. If it's not already displayed, select the organization that contains your project from the Organizations menu in the navigation bar. If it's not already displayed, select your project from the Projects menu in the navigation bar. In the sidebar, click Database & Network Access under the Security heading. The [Database & Network Access](https://cloud.mongodb.com/go?l=https%3A%2F%2Fcloud.mongodb.com%2Fv2%2F%3Cproject%3E%23%2Fsecurity%2Fnetwork%2FaccessList) page displays. 2. In the sidebar, click Private Endpoint. 3. Review the statuses. The Atlas Endpoint Service Status and Endpoint Status fields show the status of each private endpoint. Refer to the following statuses to help you determine the state of your private endpoint connections: Atlas Endpoint Service Status | Status | Description | | --- | --- | | Creating private link | Atlas is creating the network load balancer and VPC (Virtual Private Cloud) resources. | | Failed | A system failure has occurred. | | Available | Atlas created the network load balancer and VPC (Virtual Private Cloud) endpoint service. The private endpoint service is ready to receive connection requests. | | Deleting | Atlas is deleting the private endpoint service. | Endpoint Status | Status | Description | | --- | --- | | Initiating | Atlas is not yet connected to your private endpoint and has not yet accepted the endpoints. | | Waiting for User | VPC (Virtual Private Cloud) resources on Atlas are ready for use. You must set up the endpoints within your VPC (Virtual Private Cloud) by running the shell script. | | Verified | Atlas verified the endpoints within your VPC (Virtual Private Cloud) but has not yet accepted the private endpoint in your Google Cloud VPC (Virtual Private Cloud). It might take several minutes for the Endpoint Status to become `Available`. | | Available | The Atlas VPC (Virtual Private Cloud) resources are connected to the private endpoint in your Google Cloud VPC (Virtual Private Cloud). Atlas has accepted the endpoints. You can connect to Atlas clusters in this region using GCP Private Service Connect. | | Active | Atlas is ready to use VPC (Virtual Private Cloud) resources. Atlas has accepted the endpoints. A VM is assigned to the private service connection. | | Failed | Google Cloud failed to establish a connection between Atlas VPC (Virtual Private Cloud) resources and the private endpoint in your Google Cloud VPC (Virtual Private Cloud). Click Edit, verify that the information you provided is correct, and then create the private endpoint again. Note: If you see the error message "The endpoint could not be found in GCP. Please verify the endpoint name is correct and is created in the correct GCP project and try again," you might have mistyped your private endpoint name, or you may still need to create it. To resolve this, click Edit and make sure the fields are accurate. | | Deleted | You manually deleted the private endpoint from a region in Atlas. You must also delete the private endpoint in Google Cloud to delete resources. Pending deletion of the region group. | 4. Make sure that your security groups are configured properly. For each resource that needs to connect to your Atlas clusters using GCP Private Service Connect, you must allow outbound traffic to the forwarding rule's private IP addresses on all ports (1024-65535). See [Managing Consumer Security For PSC](https://docs.cloud.google.com/vpc/docs/manage-security-private-service-connect-consumers#firewall-rules) for more information. ### Multi-Region Private Endpoints Private endpoints are only available in multi-region clusters if there is a node within each region that the cluster spans that has a private endpoint configured. To learn more about configuring multi-region private endpoints, see [Regionalized Private Endpoints for Multi-Region Sharded Clusters.](https://www.mongodb.com/docs/atlas/security-private-endpoint.md#std-label-atlas_regionalized-pl) **Connection String Indexing for Multi-Region Clusters** After you configure a private endpoint for a new region and deploy cluster nodes to that region, you might see the following error when you use your private endpoint to connect to the cluster: ```none DNSHostNotFound: Failed to look up service "" ``` This error occurs when your connection string's index automatically changes and your client subsequently restarts, which causes an SRV DNS lookup. The private endpoint connection string for a multi-region cluster uses an index of `0`. If your connection string uses a different index, MongoDB automatically updates the connection string to use the `0` index. For example, you might configure two private endpoints for a region. If you remove the first private endpoint, your connection string uses an index of `1` and resembles the following: ```none mongodb+srv://cluster1-psc-0.4uyx2d.mongodb.net ``` Then, suppose you configure a private endpoint for a new region in your cluster and subsequently add cluster nodes to that region. Your cluster now includes multiple regions, and your connection string updates to use an index of `0`: ```none mongodb+srv://cluster1-psc-1.4uyx2d.mongodb.net ``` To avoid potential connectivity issues after your client's next restart, confirm that you are using the zero-indexed private endpoint connection string to connect to your cluster. You can access the updated private endpoint connection string from the Atlas UI or API after your cluster changes complete. ### Test Connectivity from Your Deployed Application You can use the tools `nslookup` and `telnet` to test the connectivity from your application to your Private Endpoint in Atlas. 1. Get the connection details for your Atlas cluster. Run `nslookup` with the `-type=SRV` flag to get the port numbers associated with each of the nodes in your cluster. ```bash nslookup -debug -type=SRV _mongodb._tcp.cluster1-psc-0.j735c.mongodb.net ``` **Output:** ```bash Server: 127.0.2.2 Address: 127.0.2.2#53 ------------ QUESTIONS: _mongodb._tcp.cluster1-psc-0.j735c.mongodb.net, type = SRV, class = IN ANSWERS: -> _mongodb._tcp.cluster1-psc-0.j735c.mongodb.net service = 0 0 1024 pl-0-us-central1-gcp.j735c.mongodb.net. ttl = 60 -> _mongodb._tcp.cluster1-psc-0.j735c.mongodb.net service = 0 0 1025 pl-0-us-central1-gcp.j735c.mongodb.net. ttl = 60 -> _mongodb._tcp.cluster1-psc-0.j735c.mongodb.net service = 0 0 1026 pl-0-us-central1-gcp.j735c.mongodb.net. ttl = 60 AUTHORITY RECORDS: ADDITIONAL RECORDS: ------------ Non-authoritative answer: _mongodb._tcp.cluster1-psc-0.j735c.mongodb.net service = 0 0 1024 pl-0-us-central1-gcp.j735c.mongodb.net. _mongodb._tcp.cluster1-psc-0.j735c.mongodb.net service = 0 0 1025 pl-0-us-central1-gcp.j735c.mongodb.net. _mongodb._tcp.cluster1-psc-0.j735c.mongodb.net service = 0 0 1026 pl-0-us-central1-gcp.j735c.mongodb.net. Authoritative answers can be found from: telnet pl-0-us-central1-gcp.j735c.mongodb.net 1024 ``` 2. Test the connectivity. From your application environment, with one of the listed ports (for example, `27017` in the example output above), run the following `telnet` command to test connectivity: ```bash telnet pl-0-.mongodb.net 27017 ```