Secure your data and integrations with Salesforce with Private Connect

Michael McDonnell
Another Integration Blog
9 min readJul 6, 2023

Co-Author — https://medium.com/@ruebenjimenez

Keeping data private is an essential part of a Zero-Trust Architecture in the modern era. Information is a commodity that needs to be kept private to protect customers, partners, your own company, and employees. MuleSoft’s integrations with AWS and Salesforce make it easy to secure your traffic in transit and prevent publicly exposed communication over the internet.

Connecting to Salesforce from MuleSoft is a well-defined process these days. MuleSoft’s suite of Salesforce Connectors allows you to leverage Salesforce to solve your business needs without focusing on your underlying technology implementation.

Salesforce Private Connect is a feature that allows customers to establish a private and secure network connection between their network and Salesforce’s cloud-based services. It is a private tunnel that connects your network directly to your Salesforce applications. Instead of using the internet to access Salesforce’s services, you can establish a direct connection through a private network link.

In this article, we will specifically focus on setting up an Inbound Connection to Salesforce from MuleSoft’s CloudHub 2.0.

This example will specifically be utilizing AWS Route 53 for DNS management and traffic routing.

Architecture

We will start with the following architecture:

Assumptions (configuration)

  • You have a MuleSoft Private Space in US-East-1 with CIDR 172.16.0.0/24
  • You have an AWS VPC in US-East-1 with CIDR 172.31.0.0/24
  • You have attached both the Private Space and the VPC to a common Transit Gateway
  • You have validated routes in both directions.
  • You have Salesforce and a Salesforce API in your Private Space

Our goal is to have a final architecture and network flow to avoid the internet when connecting to Salesforce:

Private Connect Inbound Setup

Start within your Salesforce Setup and search for Private Connect in the Quick Find box and expand the AWS Regions section. Copy the Service Name for your region (US-East-1) and set it to the side for the moment.

In AWS, go to the VPC Endpoints page and click Create Endpoint

In the Endpoint Creation Wizard give your new endpoint a descriptive name; I used private-connect-demo-vpce. Select PrivateLink Ready partner services, and paste in the Service Name from the Private Connect Inbound Setup above. Click Verify Service to move on to the next step.

After you have verified your Service name, next select the VPC and Subnets you’d like to make sure that your Private Connect link will be established. It’s recommended to have at least 2 subnets for failover purposes. In this example, I created 3 subnets that only support IPv4.

Finally, establish your security group to be used between your VPC and Salesforce. In this example I used the default group as all of my communication will be exclusively for Private Connect and the security rules are simpler. Your mileage will vary in your implementation. Click Create Endpoint to create your VPC Endpoint for Private Connect.

The next screen will show you your VPC Endpoint ID with a Status Pending. Copy the Endpoint ID and set it to the side for the moment.

Go back to your Salesforce Setup for Private Connect and click on Create Inbound Connection.

If it’s not already selected; Select the AWS PrivateLink option and click Next

On the second page of the wizard, you will configure your Connection Name, give a Description, apply the previously saved VPC Endpoint ID and fill in your Region. In this example, I named my connection name private_connect_demo_inbound and connected it to my US-East-1 region. Make sure “Yes, I would like to provision my connection now.” is selected and click Save.

As soon as you’re done creating the Inbound Connection — click the down arrow under Actions and click Sync.

When you go back to AWS to review your VPC Endpoint a refresh will show you its Status is now changed from Pending to Available.

Congratulations! At this point, you have successfully configured your Private Connect Inbound Connection! Next, let’s make it usable!

DNS Configuration in Route 53

In this section, our goal will be to set up a CNAME for our VPC Endpoint and configure our CloudHub Private Space to point to our Route 53 Resolver.

On the right-hand side of the VPC Endpoint details screen you will see I have 4 DNS names for my VPC Endpoint. The top endpoint is the primary record for the VPC endpoint. Each successive record is for a given subnet. Be sure to take that top DNS names record and copy it. Set it aside for the time being.

We can validate that the top record is the primary by performing a nslookup on the top record and seeing all 3 subnet IPs returned.

To configure your Private Hosted Zone in Route 53, start by clicking Create Hosted Zone on the Route 53 Hosted Zone page.

Give your hosted zone the Domain name: my.salesforce.com and be sure to set your Type to Private hosted zone. Failure to set your Type to Private may result in problems for your deployment.

Set the Region and VPC ID to associate with your hosted zone to be the same Region and VPC as the VPC you configured for your VPC Endpoint for Private Connect and click Create hosted zone.

Next, we need to create a custom record to point to our private entry into our Salesforce Instance. Click into your my.salesforce.com private hosted zone and click Create Record.

If you do not know your specific my.salesforce.com domain — you can go to Salesforce Setup and search for My Domain in the Quick Find box.

Take your Domain Name from Salesforce and place it as the Record name in Route 53. Set the Record type to CNAME. Set the Value of the record to the primary record of the VPC Endpoint we set aside earlier, set the TTL to something lower like 60 seconds, and click Create records.

Now that we have a private zone, we need to make it accessible to CloudHub. So we can use Route 53 Inbound DNS Resolvers that will expose our Private Hosted Zone configuration via a DNS Server IP address. Click on the Inbound endpoints page in Route 53, select Inbound Only, and click Next.

Set an Endpoint name for your inbound endpoint, select the same VPC you set up your VPC Endpoint for Private Connect in, and set your Security group appropriately. Note: You will need the ability for your CloudHub Private Space to be able to communicate with your Private Connect VPC on port 53 TCP and UDP. You can see that I set my Endpoint name to private-connect-demo-r53r, my VPC to private-connect-demo-vpc, and left my Endpoint Type at IPv4.

By default Route 53 will ask you to place its resolver in 2 Availability Zones. This will allow for high availability in an outage event. Below you will see I set up my resolver in each availability zone I had configured for my VPC. I set IP address #1 to us-east-1a and its corresponding VPC subnet, and IP address #2 was set to us-east-1b and its corresponding VPC subnet. I also used an automatically selected IPv4 address — your organization may find it fit to use specified addresses.

To flesh out all of the availability zones I had in my VPC — I added a third IP address utilizing us-east-1c and the corresponding VPC subnet. Finally — click Next.

Finally — I will not be creating any Outbound endpoints or rules. Simply click Submit.

Once the resolver is created and Operational you can click into it by clicking on the ID hyperlink on the left-hand side of the Inbound endpoints screen.

In the Inbound endpoint details, we are looking for the IP addresses of the Resolver. You can see my 3 private resolver IPs below. Copy each of them down and save them for later.

Next, you need to log into Anypoint and click into your Private Space in the Runtime Manager section. Once you can see your Private network of your Private Space, click on the Configure link next to your Internal DNS servers section.

Here you need to take the IPs you got from the Inbound endpoint from Route 53 and put them in the Server IP Addresses in a comma-separated format with no spaces. Set your Domains to my.salesforce.com and click Save.

Congratulations! Assuming all of your firewalls and routes are set up correctly, you now have a fully working Private Connect and CloudHub connectivity plane established!

Modify your Mule APIs

Modifying your Salesforce Mule application to utilize the appropriate path to get to Salesforce via Private Connect is easy. You should only have to change a single field in your Salesforce configuration because we made the adjustments to DNS that only apply to your CloudHub Private Space and Private Connect VPC. We simply adjusted the default Token Endpoint from login.salesforce.com to our my.salesforce.com-specific domain.

One thing to note: In my example app I am using OAuth JWT as my Authentication mechanism. Due to the way, TLS works under the covers: you will need to use an OAuth mechanism rather than Basic Authentication.

Conclusion

Through the course of this article, you were able to learn how to build and configure Inbound Connectivity using Private Connect between AWS and Salesforce. We then were able to extend that connectivity into MuleSoft CloudHub 2.0 using Route 53 Private Zones and Resolvers. Our new architecture looks like this:

You’ll notice immediately that the Salesforce API is now communicating through the Transit Gateway directly into the VPC Endpoint all established because we pointed our CloudHub Private Space to our Route 53 Resolver. This provides a completely private channel for communication between Salesforce and any other point of integration you may need.

Hopefully, this has shown you how easy it is to set up Private Connect Inbound connectivity with Mulesoft. There are some moving parts, but with AWS everything is built in, and HA is right out of the box! If you’re interested in more architectural patterns — please be sure to check out my other content: Global Load Balancing and Resilience for MuleSoft Private Spaces in CloudHub 2.0 utilizing Amazon Networking Services.

--

--

Michael McDonnell
Another Integration Blog

Michael McDonnell is a Principal Platform Solutions Engineer at MuleSoft, working with customers to drive innovation in their integrations.