If you’re getting started with VMware Cloud on AWS then you should be aware of all the points in which you can block traffic with a firewall. Or, if you look at it another way, the places where you might need to create allow rules for traffic to traverse your cloud. This post is used to show where those choke points live both within your VMware Cloud on AWS SDDC, as well as the Amazon VPC in which your SDDC lives.
The diagram below shows each of the firewalls that might live between a virtual machine within your VMware Cloud on AWS environment and an Amazon EC2 instance in a subnet within the same VPC.
Lets take a look at each of the items to discuss what they are and where they are configured.
1. VMC – Distributed Firewall
The first firewall is within the VMware Cloud on AWS environment and is the distributed firewall provided by NSX-T. Much like NSX on premises, you can create firewall rules at the NIC level of the virtual machines in the VMware environment. This firewall is optional and doesn’t need to be configured to allow traffic by default. It also requires that you have the NSX Advanced Add-On feature for your VMware Cloud on AWS environment. Again this firewall is optional.
2. VMC – Gateway Firewall
The second firewall we’ll discuss is the gateway firewall. This is like a perimeter firewall for your VMware Cloud on AWS environment. If you want to be able to access your vCenter and your workloads, this firewall will need to be configured. The gateway firewall consists of two parts, a management gateway firewall and the compute gateway firewall. The rules created for vCenter, SRM, and any of the components that VMware manages for you in the cloud are built in the management gateway firewall. Any of your workloads that would get deployed in the VMC would be done in the compute gateway firewall.
Each of these are configured in the SDDC console.
3. AWS – Elastic Network Interface for VMC Security Group
VMware Cloud on AWS lives within an AWS Virtual Private Cloud (VPC). The gateway we discussed in the previous section is connected to the AWS VPC with an elastic network interface. Think of this as a VM’s network adapter that lives in AWS. This is the network bridge between your VMware environment and your AWS environment. We discussed that we need to create firewall rules in the gateway, but we also need to create the security group rules on the network interface on the AWS side.
This is configured in the AWS console under the EC2 screen. It should also be noted that the VMC may create several of these ENIs when its first built, so you’ll need a security group attached to all of them with your configured rules. By default, VMware creates the rules for you but it uses a default security group from AWS. Be aware of this because many customers don’t want to use a default security group and want to create their own.
4. AWS – Network Access Control Lists
This item is another optional component. An AWS Network Access Control List (NACL) is a stateless firewall that is applied at the subnet level of an AWS VPC. These NACLs provide an extra level of protection within a VPC to block traffic for resources within the entire subnet.
AWS NACLs are configured in the AWS Console under the VPC screen.
5. AWS – EC2 Workloads
The last one is an example of a resource in AWS that is trying to communicate to VMC resources. AWS requires that a security group (even an allow all group) be assigned to each EC2 instance that is deployed. In fact as of the time of this post, you can add five security groups to an EC2 instance at a time. This is the same type of security group that was applied earlier to the ENI for the VMware Cloud Gateway. This firewall rule is optional unless you want your EC2 instances to be able to communicate with your VMC environment. If you require VM to EC2 instance connectivity it must be configured.
Again security groups can be added in the AWS console under the EC2 screen.
Summary and Final Thoughts
Hopefully this post gave you a good idea of the different firewalls that might be in place in your VMware Cloud on AWS environment and AWS VPC. My suggestion would be to carefully plan out if you need all of these firewalls including the optional ones and then afterwards decide if you need granular rules in each choke point or if you will just allow all traffic through some. For instance maybe your compute gateway firewall allows all traffic by default and you leave the firewall responsibilities to the distributed firewall. That may be an extreme case, but it is likely that some of these firewalls will have more open rules than others.
Oh, if your having connection issues still even after reading this post, don’t forget about your client firewalls as well. A Windows firewall can ruin your whole day sometimes… or so I’ve heard.