This article discusses important considerations if you want to connect vRealize Automation (vRA) directly to the internet. The article doesn’t discuss if you should do or want to do this, this all depends on your specific requirements.
Let’s first take a look at the different components vRA consists of:
- Identity appliance – Responsible for authentication/authorization of users who want to access the vRealize Automation portal;
- vRealize Automation Appliance – The appliance is the central part of vRA. It’s responsible for catalog administration, the advanced service designer and the approval process. The appliance also serves as a webserver and hosts the portal. The appliance requires a vPostgres database.
- The IaaS server is a Windows server and specifically responsible for virtual machine deployment. The IaaS server requires a MS SQL database.
- vRealize Orchestrator is required for the Advanced Service Designer and for integration with 3rd party components when deploying virtual machines.
Okay, let’s take a look at some of the tips when you want to connect vRA directly to the internet.
Use vRA 6.1 or newer
A first important finding is that there is a difference between vCAC/vRA 6.0, and vCAC/vRA 6.1/6.2. In vRA 6.0 the identity appliance, vRA appliance and IaaS server all need to be accessible for the client workstation. Since vRA 6.1 only access to the identity appliance and vRA appliance is required. In case of an internet facing vRA setup, I would always advice to use vRA 6.1 or newer so you don’t have to connect IaaS server directly to the internet.
Firewall configuration
Because only the identity appliance and vRA appliance need to be internet facing, only these servers should be placed in the DMZ. I would choose to place the IaaS server behind a second firewall (not in DMZ), as well as the orchestrator server and IaaS MS SQL database server. Depending on you specific setup you can also choose to move the vRA appliance database out of the DMZ. In this case you will be running a separate vRA vPostgress database.
Use an enterprise level firewall and only allow access to the required ports on the identity appliance and vRA appliance:
- The identity appliance should only be accessible on port 7444 from the internet. Block port 5480 (management interface) and port 22 (SSH) for internet acces and only allow local access to these ports.
- The vRA appliance should only be accessible on port 443 (https) and 80 for redirection (if required). Block all the other ports, such as 5480 (management interface) and port 22 (SSH).
I would also suggest to block access to the general management URL, and the URL for access to the vsphere.local tenant:
- https://<vra-url.domain.tld>/ (general management URL)
- https://<vra-url.domain.tld>/vcac/ (access to vsphere.local tenant)
Only allow access to required ports for servers that are not running in the DMZ. An overview of all ports is published here.
Limit virtual machine console connectivity
Connecting to a virtual machine console is not something you want to do in an internet facing vRA setup. As a matter a fact, VMware completely removed the “connect to VMRC” option from vRA due to security concerns, so this option isn’t available anymore.
Small addition here:
@viktoriousss FYI, vRA 6.2.1 adds VMRC console proxy, making it a feasible option again for internet-facing deployments.
— Jad El-Zein (@virtualjad) March 10, 2015
Virtual machines that are deployed through vRA will probably not have an internet connection available, so the option to connect to RDP or SSH in vRA is not very valuable in the setup.
Configure the correct hostnames
Configure the internet hostname for both the identity appliance (sso->host settings) and the vRA appliance (vRA settings->host settings). The used hostnames should be resolvable on the internet and the internal network. On the internal network you will need to configure an internal DNS server that is resolving these public URL’s to the internal IP address(es) of the servers. This prevents that internal components (for exmaple the IaaS Server) are connecting to the public addresses of the identity appliance and vRA appliance. For an overview of all connections take a look at the vRA 6.1 reference guide. Don’t use the vRA 6.x reference guide because this version is only applicable for vRA 6.0.
Use certificates issued by an internet facing CA
You will need to configure signed certificates for at least the identity appliance and the vRA appliance. These certificates should be issued by an internet CA so you don’t get any certificate errors.
Read this KB to learn on which certificate formats are supported by vRealize Automation. Very important: follow the guidelines in the vRA 6.1 reference guide for correct usage of the Subject Alternative Name (SAN) and Common Name (CN) in your certificates.
I hope this is helpful. If you have any additions to this article or just an interesting remark, please feel free to leave a comment below.
7 Comments
Daniel
Please is it possible to have a public DNS with the domain danit.local. and over the internet, we have a public domain name of danit.com
Daniel
Made a mistake on the first post.
Please is it possible to have a local DNS with the domain danit.local, and users can access vra using vra.danit.local locally and also have users access vra over the internet via a public domain vra.danit.com
viktorious
This is not possible because vRA will redirect you to the URL configured in the management interface. This is just one URL, this URL will point the internal or external address of your installation.
Daniel
Will this work if I create two zones on my internal DNS server.
Dan
Will a one to one NAT work for VRA 7. I. e mapping a public IP to vRA private IP
viktorious
I guess this will work, I think the internal and external DNS names should identical.
jonkensy
I have my vRA 7.2 accessible from the internet, but after logging in the Catalog/Design/etc. tabs just show blank white content. What am I missing? Thanks!