Internet access required for CPM operations

Internet access required for CPM operations

CPM Server:

All outbound CPM communication is to the 443 port (https)
For ongoing operations for a production CPM server it needs to access AWS endpoints to use AWS APIs.

You can decide to expose only relevant regions.
AWS endpoint information can be found here:
You should keep the EC2, EBS, RDS, VPC, KMS, IAM, STS, SNS &  Redshift services available.

During the trial and an initial registration of the purchased instance, CPM needs to access our licensing service to get the license, so you need to keep port 443 open from the CPM instance to the Internet.
After you have purchased a non-BYOL edition and registered your CPM instance, you may delete this rule, leaving only communications to the AWS endpoints.
BYOL edition requires to keep port 443 open from the CPM instance to the Internet after the purchase.

CPM v2.3 and newer has NTP daemon installed (please upgrade if you are using an older version).
In order for NTP to function, you must enable in your firewall full unrestricted access to UDP port 123 in both directions between the CPM instance and Amazon's NTP servers:

If CPM's time will go out of sync with AWS, it won't be able to perform any backups, or send notifications about failures.

Troubleshooting CPM Server's connectivity:

To test connectivity outside of the CPM application itself, please connect to the instance using SSH (username: cpmuser and your assigned private key) and try this command:

See what it returns - there must be a failure with either resolving the URL or connecting to it.
If you don't see HTTP response 200 "OK" like in the screenshot below,  there is a problem with either DNS resolution or a proxy refusing connections.

If CPM has a problem accessing specific endpoints, try using them instead of "".

CPM Agent:

CPM Agent needs to be able to connect to the CPM Server over port 443.
To verify that it can do that, you can open CPM's GUI in a browser on the Agent's instance.
If the browser can connect, so can the Agent.

File Level Restore Workers:

File Level Restore Worker needs to be able to connect to the CPM Server over ports 443 and 22.
You can test connectivity from the Worker by connecting to the worker over SSH and running these commands:
For port 22: ssh cpmserveripaddress
The result should be "cpmuser@cpmserveripaddress: Permission denied (publickey)."
If connection is blocked, you will receive (after a delay) "ssh: connect to host cpmserveripaddress port 22: Connection timed out"
For port 443: wget --no-check-certificate https://cpmserveripaddress/
This command should result in status 302 (redirecting to "/signin/") followed by status 200

Important: In order to be able to login to the worker instance over SSH (using "ubuntu" username) you have to make sure that you have configured the workers to use a key pair:

**If CPM is using http proxy, you need to make sure that it is configured to pass ssh communication also

S3 Workers:
S3 worker needs the same access as File Level Restore Worker, plus access to the AWS S3 public gateway IPs, same region as the S3 bucket
If using an ACL, please make sure the proper ports are open for bi-directional communication between the worker and S3:

The worker will connect to S3 via internet, even if the CPM server and S3 bucket are in the same region.
The worker must have a public IP assigned by the subnet; -or- the subnet must be configured with a NAT gateway, for the worker to communicate with S3.
Only if the EBS backups and S3 bucket are in the same region, this can be worked around by configuring an S3 endpoint as shown here:

The worker must be able to resolve the DNS name of the region with your S3 bucket. (e.g. Please ensure the worker will be able to resolve DNS names of S3 endpoints.

If an HTTP proxy is necessary to access public IPs, ensure this is properly configured in the worker settings and not blocking the transfer to s3. It may be advisable to test by opening internet to the worker without a proxy in some cases to be sure the proxy is not causing an issue.

Version 3.1:
in version 3.1 we started using EBS direct API for S3 operation, this API enable lets us read the blocks from the snapshots.
This means that in addition to the above, you also need to make sure that communication is opened to the relevant EBS endpoints:
If your worker is in a private VPC, then you need to enable communication to this endpoint via your proxy or using VPC endpoints