--- schema_version: "1" id: 67e670da044ac5d5a998d0d6c38ae0e795e576678bac76048495ea8b89f3a58b title: Gathering Required Setup Information collection: mulesoft version: current locale: en-us portal_url: https://docs.salesforce.com/mulesoft/current/en-us/cloudhub-2/ps-gather-setup-info.md canonical_url: https://docs.mulesoft.com/cloudhub-2/ps-gather-setup-info source_site: docs.mulesoft.com content_type: documentation content_hash: 5fa7a2f75b2f967ce8c3363951eda8251606a290c8d13ef52b1de2a0810a9b25 description: MuleSoft Documentation Site latest: true --- --- product: CloudHub 2.0 --- # Gathering Required Setup Information > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use the following sections to gather the information you’ll need to set up your private space. For information about private spaces, see [Private Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-private-space-about). You might need to collaborate with your network administrator if you don’t have access to this information. In this case, share this setup checklist with them. ## Organization Entitlements and CloudHub 2.0 Based on your organization’s entitlements, Anypoint Platform enforces limits for vCore consumption, network connections (VPNs and transit gateway attachments), and private spaces. CloudHub 1.0 and CloudHub 2.0 share entitlement quotas. If your organization uses both CloudHub 1.0 and CloudHub 2.0, you must budget your consumption with both in mind. For example, if your organization is entitled to four network connections, it can support one transit gateway connection in CloudHub 1.0, one transit gateway connection in CloudHub 2.0, and two VPNs (or some combination therein). In other words, if the network connection entitlement is four, you do not get four network connections for each version of CloudHub. To ensure your organization has sufficient entitlements to meet your needs, you must understand how resources map to entitlements: - Private cloud quotas include both VPCs (virtual private clouds) in CloudHub 1.0 and private spaces in CloudHub 2.0. - Network connection quotas include VPNs and transit gateway attachments in both CloudHub 1.0 and CloudHub 2.0. - vCore usage quotas apply to apps deployed in CloudHub 1.0 and CloudHub 2.0. Anypoint Platform prevents you from consuming resources that exceed your organization’s limits. Anypoint Platform also prevents you from modifying existing resources if you are exceeding that resource’s limit. Note that failed application deployments and unsuccessful private space creation in CloudHub 2.0 still count toward limits. ## Information Required to Set Up a Private Space The following list summarizes the information required to set up a private space. For details about each requirement, see the sections that follow. **Private Network Setup** - [Private space name](#private-space-name) - [Private network region](#private-network-region) - [CIDR block](#cidr-block) - [Internal DNS servers](#internal-dns-server) (optional) - [IP addresses](#server-ip-addresses) - [Domains](#domains) **VPN Connection Type** - [VPN name](#vpn-name) - [Remote IP](#remote-ip-address) - **[Dynamic Routing Type](#dynamic-vpn-routing)** - [Local ASN](#local-asn) - [Remote ASN](#remote-asn) - **[Static Routing Type](#static-vpn-routing)** - [Local ASN](#local-asn) (_first VPN only_) - [Static IP prefixes](#static-ip-prefixes) - **[Advanced Tunnel Configuration](#advanced-tunnel-configuration)** (_optional_) - Tunnel 1 - [Inside IP CIDRs](#inside-ip-cidrs) - [Pre-shared keys](#preshared-keys) - Tunnel 2 - [Inside IP CIDRs](#inside-ip-cidrs) - [Pre-shared keys](#preshared-keys) - [Automatic Tunnel Initiation](#auto-tunnel-initiation) (_first VPN only_) - [**Supported Gateway Devices**](#supported-gateway-devices) - Device vendor - Device platform - Device software **Redundant VPN Connection** (_optional_) - **[Dynamic Routing Type](#dynamic-vpn-routing)** - [Remote IP](#remote-ip-address) - [Remote ASN](#remote-asn) - **[Static Routing Type](#static-vpn-routing)** - [Static IP prefixes](#static-ip-prefixes) - **[Advanced Tunnel Configuration](#advanced-tunnel-configuration)** (_optional_) - Tunnel 1 - [Inside IP CIDRs](#inside-ip-cidrs) - [Pre-shared keys](#preshared-keys) - Tunnel 2 - [Inside IP CIDRs](#inside-ip-cidrs) - [Pre-shared keys](#preshared-keys) - [**Supported Gateway Devices**](#supported-gateway-devices) - Device vendor - Device platform - Device software **Transit Gateway Attachment Connection Type** - [Transit gateway name](#transit-gateway-name) - [Transit gateway region](#transit-gateway-region) - [Transit gateway routing](#transit-gateway-routing) - [MuleSoft AWS account ID](#mulesoft-aws-account-id) - [Resource share ID](#resource-share-id-owner) - [Resource share owner](#resource-share-id-owner) ## Private Network Requirements - [Private Space Name](#private-space-name) - [Private Network Region](#private-network-region) - [CIDR Block](#cidr-block) - [Connection Type](#connection-type) - [Internal DNS Servers (Optional)](#internal-dns-server) ### Private Space Name Private space names can contain between 1 and 36 alphanumeric characters (a-z, A-Z, 0-9) and hyphens (-). Runtime Manager supports Unicode characters in private space names. The private space name appears in the list when you select a deployment target for your apps. You cannot rename a private space. ### Private Network Region The _region_ is the Amazon region to deploy your apps to, such as `usa-e1`. The complete list of supported regions is: US East (Northern Virginia) US East (Ohio) US West (Northern California) US West (Oregon) Canada (Central) South America (Sao Paulo) Europe (Ireland) Europe (Frankfurt) Europe (London) Asia Pacific (Singapore) Asia Pacific (Sydney) Asia Pacific (Tokyo) #### Canada (Central) Private Space Subnet Availability Only the MuleSoft Government Cloud control plane supports three subnets in Canada (Central) for increased high availability. The Commercial control plane doesn’t support three subnets in this region. > [!IMPORTANT] Control plane discrepancy: Subnet count for a private space in Canada (Central) > depends on your control plane. MuleSoft Government Cloud supports three subnets. The Commercial > control plane provisions private spaces with only two subnets. > > Existing MuleSoft Government Cloud private spaces: Private spaces created in Canada (Central) > prior to three-subnet support don’t receive the update automatically. To get the three-subnet > architecture, recreate your private space. Recreating a private space causes downtime. Redeploy > applications and reconfigure VPN, transit gateway, DNS, and other connections in the new private > space. Plan the migration during a maintenance window. ### CIDR Block The _CIDR block_ is the range of IPv4 addresses, in CIDR (Classless Inter-Domain Routing) notation that the apps deployed in your private space use. The CIDR block defines the size of the private space. For example, to grant your private network 256 IP addresses between `10.111.0.0` and `10.111.0.255`, set the CIDR block to `10.111.0.0/24`. When you create a private space, you must specify the CIDR block. You can’t resize or change the CIDR block after you create the private space. For this reason, ensure that you correctly anticipate your requirements before configuring this parameter. We recommend a `/22` block. Because some addresses are reserved for fault tolerance, infrastructure, and zero-downtime, the allowed block size that you can assign for your Anypoint VPC is between `/16` and `/24`. Note that the size of the block does not limit the number of IPs that your apps can use. When specifying CIDR blocks, ensure that the CIDR blocks: - Are from a private IP space. - Don’t overlap with any other CIDR blocks assigned to your other private spaces. - Don’t overlap with any CIDR blocks in use in your corporate network. MuleSoft recommends using subnets from standard RFC 1918 addresses, such as `10.0.0.0/8`, `172.16.0.0/12`, and `192.168.0.0/16`. #### CIDR Block Sizing CIDR block sizing depends on several factors related to how IP addresses are allocated when you deploy applications: - Number of applications in a private space - [Replica size](https://docs.mulesoft.com/cloudhub-2/ch2-architecture#cloudhub-2-replicas) assigned to each application - [Number of replicas](https://docs.mulesoft.com/cloudhub-2/ch2-clustering#replica-scale-out) in each application, based on horizontal scaling, high availability, and fault tolerance configuration - [Rolling deployment configuration](https://docs.mulesoft.com/cloudhub-2/ch2-update-apps#rolling-update-vs-recreate-deployment-model) - [Auto-upgrades](https://docs.mulesoft.com/cloudhub-2/ch2-patch-updates) that update multiple applications simultaneously - Platform internal operations or services that require IP headroom Use this reference table to select the appropriate CIDR block size for your private space:
CIDR Block SizeMaximum vCoresMaximum Applications

/24

Less than 100

Less than 100

/23

Less than 300

Less than 200

/22

Less than 600

Less than 500

/21

Less than 1200

Less than 1000

/20

Less than 3000

Less than 2000

> [!NOTE] These reference sizes are subject to change as the platform continues to evolve. Exceeding > the recommended thresholds for your CIDR block size can cause application deployments to fail with > errors indicating that replicas are unschedulable due to insufficient available IP addresses. #### Unusable Private Space Network CIDR You cannot use the following list of CIDR blocks: 100.64.0.0/10 198.19.0.0/16 224.0.0.0/4 169.254.0.0/16 127.0.0.0/8 172.17.0.0/16 0.0.0.0/8 #### Reserved Corporate CIDR (Optional) Optionally, when you create your private space and configure your private network, you can configure _reserved CIDR blocks_ that correspond with your reserved corporate network CIDRs. When you reserve CIDRs in a private network configuration, Anypoint Platform does not use the blocks you specify when associating IP addresses with your private space. This prevents overlap between your corporate network CIDRs and Anypoint Platform infrastructure. There are two strategies for reserving CIDRs during private space creation: 1. Provide all reserved corporate CIDRs Specify all CIDR blocks you plan to use within your corporate network. CloudHub 2.0 automatically checks for conflicts with the MuleSoft infrastructure CIDR pool and chooses options that do not overlap. This approach simplifies setup but requires providing a potentially larger list. 2. Manually identify overlapping corporate CIDRs Manually review the MuleSoft infrastructure CIDR pool. Then, specify only the CIDRs from your corporate network CIDR list that conflict with options in the MuleSoft infrastructure CIDR pool. This approach minimizes the list you provide, but you must check for overlap beforehand. Note that the MuleSoft infrastructure CIDR pool is subject to change. #### MuleSoft Infrastructure CIDR Pool Anypoint Platform has a list of CIDRs as an internal CIDR pool for provisioning private space networks. The MuleSoft infrastructure CIDR pool is subject to change. You can configure some of the following as reserved CIDR blocks, but you cannot use them as private space network CIDRs: 100.64.0.0/16 100.66.0.0/16 100.67.0.0/16 100.68.0.0/16 ### Internal DNS Servers (Optional) If your corporate network uses internal DNS servers to resolve requests to custom domains, you must configure those servers to enable apps deployed to a private space to access internal resources that are not reachable from the public internet. To configure internal DNS servers, specify the IP addresses for your internal domain servers and the domains that you want to be resolved by internal DNS. The private space resolves the domains using the specified DNS server, enabling you to use internal host names in your private network as long as your applications use the FQDN to request back-end resources. #### Server IP Addresses The _Server IP addresses_ identify the internal DNS servers that resolve requests to custom domains. To provide redundancy, you can configure multiple internal DNS servers. When configuring the IP addresses for the DNS servers, keep the following in mind: - You configure DNS servers within a private space, so the server IP addresses you configure must be reachable from the private space. If the server isn’t reachable, DNS resolution fails. - If you configure multiple servers, the private space queries any DNS server in the list for the specified domains at any time, in any order. - All name servers must present the same DNS record. - After the private space receives a valid response from any configured name server, it doesn’t retry the request. If one of the name servers doesn’t have a record for the domain, it returns the response `NXDOMAIN` (non-existent domain). Because this response is valid, the private space doesn’t send the query to the other servers. #### Domains _Domains_ identify the internal domains that must be accessible from the private space. The configured internal DNS servers resolve the specified domains, and the external DNS server resolves all other domains. To configure an internal domain, specify the IP address. The following internal private DNS domains are not supported: - `cloudhub.io` - `mulesoft.com` - `anypointdns.net` - `amazon.com` - `amazonaws.com` - `compute.internal` - `io` - `com` - `net` - `internal` - `local` - `domain.com` > [!NOTE] These restrictions also apply to the respective subdomains. You can’t add MuleSoft domains or public domains as private space internal DNS. As a workaround, create CNAME records on your own DNS servers to redirect a permitted custom domain to the restricted domain you want to add. See [Cannot add certain domains to CloudHub VPC Internal DNS](https://help.salesforce.com/s/articleView?id=001119691&type=1). > [!NOTE] Each domain can contain up to 253 characters. When configured with 10 IP addresses (IPs) > per entry, the maximum supported capacity is 1940 entries. The system supports more than 1940 > entries if you use shorter domain names or fewer IPs in entries. ### Connection Type - [Virtual Private Network (VPN)](#vpn-requirements) - [Transit Gateway Attachment](#tgw-requirements) ## VPN Requirements Review the recommendations and limitations in [Anypoint Virtual Private Network](https://docs.mulesoft.com/cloudhub-2/ps-vpn-about). - [VPN Name](#vpn-name) - [Remote IP Address](#remote-ip-address) - [Dynamic VPN Routing (BGP)](#dynamic-vpn-routing) - [Static VPN Routing](#static-vpn-routing) - [Local ASN](#local-asn) - [Remote ASN](#remote-asn) (dynamic routing only) - [Static IP Prefixes](#static-ip-prefixes) (static routing only) - [Inside IP CIDRs](#inside-ip-cidrs) (advanced tunnel configuration only) - [Pre-shared Keys](#preshared-keys) (advanced tunnel configuration only) - [Automatic Tunnel Initiation](#auto-tunnel-initiation) (advanced tunnel configuration only) - [Supported Gateway Devices](#supported-gateway-devices) > [!NOTE] Before configuring routing, consolidate networks to the fewest number possible. A maximum > of 95 route table entries is allowed per private space, regardless of the number of connections. ### VPN Name The _VPN name_ is the name of the VPN connection. ### Remote IP Address The _remote IP address_ is the public (single, static) IP address of your VPN endpoint. ### Dynamic VPN Routing (BGP) For dynamic routing, your device uses Border Gateway Protocol (BGP) to advertise routes to Anypoint VPN. If your device supports BGP, you can select dynamic routing; otherwise, select static routing. To create a dynamic VPN connection, in addition to the static VPN connection requirements, your VPN device must be able to: - Establish BGP peering - Support route-based VPNs (bind tunnels to logical interfaces) - For IPsec, enable perfect forward secrecy (PFS) with the Diffie-Hellman Phase 2 groups 2, 5, 14-24. ### Static VPN Routing If your gateway device doesn’t support BGP, you must use static routing. You might also want to use static routing if you want to provide your own secrets. Static routing requires you to specify the routes (subnets) in your network that are accessible through Anypoint VPN. To create a static VPN connection, your VPN endpoint must be able to: - Establish IKE Security Associations using a Pre-Shared Key (PSK) - Establish IPsec Security Associations in Tunnel mode - Use any combination of IPsec settings that Anypoint Platform supports - Fragment IP packets before encryption You must fragment packets that are too large to transmit. Your gateway device must be able to fragment packets before encapsulation. - Use one Security Association (SA) pair per tunnel Anypoint VPN supports one unique SA pair (one inbound and one outbound connection) per tunnel. Some policy-based devices create an SA for each ACL (access-control list) entry. In this situation, you must consolidate your rules and then filter unwanted traffic. - Use IPsec Dead Peer Detection (DPD) DPD allows devices to rapidly identify when network conditions change. You can enable DPD on the Anypoint Platform endpoint using `DPD Interval: 10` and `DPD Retries: 3`. - Allow asymmetric routing Asymmetric routing occurs when routing policies send traffic from your network to the private space through one tunnel and traffic returns from the private space through the other tunnel. The Anypoint Platform VPN endpoint selects the tunnel using an internal algorithm, making the return path dynamic. If your device uses an active/active tunnel configuration, you must allow asymmetric routing for each Anypoint VPN connection. - For IPsec, enable perfect forward secrecy (PFS) with the Diffie-Hellman Phase 2 groups 2, 5, 14-24. ### Local ASN The _local ASN_ (Autonomous System Number) specifies a private ASN (`64512–65534`) to assign to the Anypoint Platform side of the VPN. Use a private ASN that is not already assigned to your network. The default value is `64512`. > [!NOTE] You configure the local ASN for both static and dynamic routing. Although the local ASN isn’t used for static routing, you must specify this value when you create the first VPN because it is required for any future VPN connections using BGP for this private space. For subsequent VPNs that you create in the private space, the **Local ASN** option is not available for static routing. To change the local ASN after creating the VPN, you must delete all existing connections first. ### Remote ASN The _remote ASN_ specifies a private ASN that corresponds to your backend. > [!NOTE] You configure the remote ASN only for dynamic routing. Use either an existing ASN assigned to your network or a private ASN (`64512–65534`) that is not already assigned to your network. The default value is `65001`. ### Static IP Prefixes The _static IP prefixes_ are IP prefixes to advertise to your private network in Anypoint Platform, in CIDR notation. > [!NOTE] You configure the static IP prefixes only for static routing. A maximum of 95 route table entries is allowed per private network, regardless of the number of VPN connections. To avoid exceeding the limit, consolidate networks to the fewest number possible. ### Advanced Tunnel Configuration (Optional) You can customize the tunnel configuration if you want to specify custom values for inside IP CIDRs and pre-shared keys, or if you want to disable automatic tunnel initiation. Any values that you don’t specify are set to the default. #### Inside IP CIDRs The _inside IP CIDRs_ is the IP address range for the internal address of the VPN tunnel. > [!NOTE] You specify the inside IP CIDRs only for custom tunnel configuration. For automatic tunnel > configuration, these values are auto-generated. For each tunnel, enter the IP address range for the internal address of the VPN tunnel. You can specify a size /30 CIDR block from the `169.254.0.0/16` range. The CIDR block must be unique across all private network connections. You cannot use the following list of CIDR blocks: 169.254.0.0/30 169.254.1.0/30 169.254.2.0/30 169.254.3.0/30 169.254.4.0/30 169.254.5.0/30 169.254.169.252/30 #### Pre-shared Keys A _pre-shared key_ (PSK) is a shared secret that was previously shared between two ends of a connection for the VPN tunnels. > [!NOTE] You specify the PSK only for custom tunnel configuration. For automatic tunnel > configuration, these values are auto-generated. For static connections, your VPN endpoint uses pre-shared keys (PSKs) to establish IKE Security Associations. For each tunnel, enter a value of between 8-64 characters that does not begin with zero (0). Use only alphanumeric characters, periods (.), and underscores (\_). #### Automatic Tunnel Initiation By default, VPN tunnels are initiated automatically. If you deselect this option, you must generate traffic from the customer gateway to establish VPN tunnels. This setting applies to all VPNs in the connection and the option isn’t available for subsequent redundant VPNs. > [!NOTE] Modifying the tunnel initiation after VPN creation causes all VPNs in this connection to > restart. ### Supported Gateway Devices A _gateway device_ is a physical or software appliance on your organization’s side of the VPN connection. Your network administrator must configure the device to work with the Anypoint VPN connection. The following gateway network devices are known to work with Anypoint VPN. If your device does not appear in the list of tested devices, check the requirements to verify that your device is suitable for use with Anypoint VPN. See [Dynamic VPN Routing (BGP)](#dynamic-vpn-routing) and [Static VPN Routing](#static-vpn-routing).
Table 1. Supported Gateway Devices
Device VendorDevice PlatformDevice Software

Check Point

Security Gateway

R77.10 or later

Cisco

ASA

ASA 8.2 or later

IOS

Cisco IOS 12.4 or later

Dell

SonicWALL

SonicOS 5.9 or later

Fortinet

Fortigate 40+ Series

FortiOS 4.0 or later

Juniper

J-Series Service Router

JunOS 9.5 or later

SRX-Series Services Gateway

JunOS 11.0 or later

SSG

ScreenOS 6.1 or 6.2 or later

ISG

ScreenOS 6.1 or 6.2 or later

Netgate

pfSense

OS 2.2.5 or later

Palo Alto Networks

PANOS 4.1.2 or later

Yamaha

RT107e

RTX1200

RTX1210

RTX1500

RTX3000

SRT100

Microsoft

Windows Server

2008 R2 or later

2012 R2 or later

Zyxel

Zywall Series

4.20 or later for statically routed Anypoint VPN connections

4.30 or later for dynamically routed Anypoint VPN connections

## Redundant VPN The default value for **Remote ASN** is inherited from the first VPN. You can change this value. ## Transit Gateway Attachment Requirements - [Transit Gateway Name](#transit-gateway-name) - [Transit Gateway Region](#transit-gateway-region) - [Transit Gateway Routing](#transit-gateway-routing) > [!NOTE] Before configuring routing, consolidate networks to the fewest number possible. A maximum > of 95 route table entries is allowed per private space, regardless of the number of connections. ### Before You Begin Before you can add a transit gateway to CloudHub: - Create a transit gateway on your corporate AWS account. See [Getting started with transit gateways](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-getting-started.html) in the AWS documentation for information about creating a transit gateway on AWS. One transit gateway can support up to 10 VPC attachments. - Purchase a Private Space offering with AWS Transit Gateway entitlements. The **Transit Gateways** page is visible in Runtime Manager to Anypoint organizations that have an Anypoint VPC and VPN license. Attaching one Anypoint VPC to an AWS Transit Gateway uses one Anypoint VPN license. - Sign in to an Anypoint Platform account with either the CloudHub 2.0 Network Administrator or the CloudHub 2.0 Network Viewer user permission. See [Grant Permissions and Roles to Users](https://docs.mulesoft.com/access-management/users#grant-user-permissions). - Identify the subnets in your network (in CIDR notation) that you want to make accessible through the transit gateway. ### Transit Gateway Name Transit gateway attachment names can contain up to 255 alphanumeric characters (a-z, A-Z, 0-9) and hyphens (-). Runtime Manager supports Unicode characters in private space names. Use the same name for your transit gateway in AWS. You can change this name later. ### Transit Gateway Region The region corresponds to the location of your AWS Transit Gateway. Your private space and AWS Transit Gateway must be in the same region. ### Transit Gateway Routing A maximum of 95 route table entries is permitted per VPC, regardless of the number of transit gateway attachments. Consolidate networks to the fewest number possible to avoid exceeding the limit. ### MuleSoft AWS Account ID The MuleSoft AWS account ID varies depending on your control plane, for example, US Cloud or EU Cloud, and appears in **Add transit gateway** page when you select to create the transit gateway connection. When you create a resource share in AWS, you specify this ID to allow Anypoint Platform to access the resource share. If another team performs AWS configuration, share this MuleSoft AWS account ID with them. ### Resource Share ID and Owner The resource share ID and owner appear on the **Create a resource share** page on AWS. You use these values to verify the resource share in Anypoint Platform. - The resource share **ID** field contains alphanumeric characters (a-z, A-Z, 0-9) and hyphens (-). - The resource share **Owner** field contains only numbers. ## See Also - [Private Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-private-space-about) - [Anypoint Virtual Private Network](https://docs.mulesoft.com/cloudhub-2/ps-vpn-about)