Quest has a new Dashboard portal (Data Protection Portal – DPP) for their Rapid Recovery product, found here: https://dataprotection.quest.com
This gives a very nice overview of your environment including Cores, Machines, and Repositories, along with some level of control. Having recently been exposed to the AppAssure/Rapid Recovery product, this is a very welcome addition because the existing tools like the Central Console are very lacking in central management capabilities. I’ll do a write-up of the capabilities of this Dashboard at a later date.
The DPP requires a plugin to be installed on each Core, which will then communicate with Quest. However, I’ve got Cores in an environment with restricted Internet connectivity. Previously firewall rules were enabled to provide connectivity to the Quest License Portal over HTTP/S, but these are not sufficient for access to the new DPP.
When you try to install the plugin on a Core with limited connectivity, you’ll receive this error before the install wizard appears:
Unfortunately, Quest has very little detail on what ports are required, feedback which I’ve already passed along. Their Default Ports page lists connectivity requirements for various functions but not the DPP. In addition, it doesn’t list the destination names or IP in order to isolate outbound HTTP/S even further.
To begin resolving this, I installed WireShark on my Core, began a session, and then attempted to install the Plugin again. Right before the error appeared, I saw DNS request for “s3.amazonaws.com”, and then repeated attempts to an IP over HTTP. I knew I was on the right track because when you download the plugin from the DPP, the link directs to S3:
I added the FQDN “s3.amazonaws.com” as an address object permitted for outbound HTTP/s access, and attempted to install the plugin again. This time I received a successful prompt to begin the install wizard.
When I run WireShark now, I can see the DNS query, requests for a manifest, and then further on a switch to HTTPs communication (rather than port 80 that it starts with):
I’d really love to restrict this rule down further than the FQDN of S3, so I’ve opened a case with Quest and will update this post if I get a better option.
Now that the install is done, I went looking at the DPP to ensure my Core was communicating, and found that it was not.
Back to WireShark, I started another session and saw a different set of traffic:
A DNS request for “api.licenseportal.com” is completed, and then HTTPs communication that is pretty clearly traffic to the DPP. If one does a reverse DNS lookup on “dataprotection.quest.com” you get an Azure-bound IP address (related to the CNAME resolution in the screenshot above), and if you hit the resolved IP in a browser, you get a certificate warning with a wildcard cert for *.licenseportal.com which is a known Quest domain name.
I added this as an additional FQDN object, and now the Core is displaying data within the DPP. I have now removed the S3.amazonaws.com permission as it is only apparently necessary for the installation.
