This blog post will provide a deep dive on the distributed firewall (DFW) on VMware Cloud on AWS (VMC on AWS). Let’s start with the basic concepts of a distributed firewall:

Distributed Firewall Concepts

The distributed firewall is an essential feature of NSX Data Center and essentially provides the ability to wrap virtual machines around a virtual firewall.

The virtual firewall is a stateful Layer 4 (L4) firewall – it’s capable of inspecting the traffic up to the Layer 4 of the OSI model: in simple terms, it means they look at IP addresses (source and destination) and transmission control protocol (TCP) / user datagram protocol (UDP) ports and filter the traffic based upon these criteria.

What’s unique about our firewall is that it has contextual view of the virtual data center – this means our distributed firewall can secure workloads based on virtual machine (VM) criteria instead of just source and destination IP addresses.

Traditional firewalling is based on source and destination IPs – constructs that have no business logic or context into applications. Our distributed firewall can secure workloads based on smarter criteria such as the name of the virtual machine or metadata such as tags.

This enables us to build security rules based on business logic (using tags or naming convention (which, if well-built, could specify physical location, business application, whether a workload is test, dev or prod, etc…)).

Using our distributed firewall, we can offer east-west firewalling within the data center and achieve micro-segmentation and ultimately reduce the impact of a potential security breach and achieve compliance targets. If you want to learn more about this concept, read the Micro-Segmentation for Dummies book.

By North-South, we mean traffic coming to and from the Internet to the VMware Cloud on AWS. By East-West, we refer to traffic within the Data Center/Cloud.

Now let’s focus on using the DFW on VMware Cloud on AWS.

Distributed Firewall on VMware Cloud on AWS

Without the distributed firewall, VMware Cloud is essentially one flat zone.

  • All VMs on a logical segment can talk to each other.
  • A VM on a logical segment can talk to a VM on a different logical segment.
  • There is no East-West security.

It might be acceptable for customers using VMware Cloud to host a specific application or for more test/dev workloads but as customers evacuate entire DCs towards VMC on AWS or want to run a demilitarized zone (DMZ) within VMC, they often require some level of segmentation.

Once you open the VMC Cloud Console, you will find the following menu:

Remember that you don’t have direct access to the NSX Manager on VMware Cloud on AWS and all networking and security configuration is built either via the VMware Cloud console or via the APIs.

Distributed Firewall Sections

There are several four higher-level sections of rules to break down security requirements.

These higher-level sections are simply a way to build your security logic. You don’t have to create your security rules to fit this model. You might want to define all rules one of these pre-set sections if you find it easier to organize your security rules that way.

The four higher-level sections include:

Emergency Rules: applies to temporary rules needed in emergency situations.

For example, imagine that one of your VMs has been compromised: you might want to create a rule to block traffic to/from it.

Infrastructure Rules: Applies to infrastructure rules only.

Infrastructure rules are global rules that define communications between your workloads and core/common services. For example: All Applications need to talk to the set of active directory (AD) and domain name system (DNS) Servers.

Environment Rules: Applies to broad groups to separate zones.

Such as, setting rules so that the production environment cannot reach the test environment.

Application Rules: Applies to specific application rules.

Such as allow ‘app-1’ talk to ‘app-2’ or block traffic between ‘app-3’ and ‘app-4’.

Default Rules   The default rules allows all traffic.

Traffic is treated by the emergency rules first, then by the infrastructure rules, the environment rules, the applications and finally by the default rule.

The last rule allows all traffic. Today, we cannot change the default rule from ‘allow’ to ‘deny’. With an ‘allow all traffic’ rule at the end, it means we are ‘denylisting’ traffic before that (previous rules specify which traffic cannot be allowed).

If we want to ‘allowlist’ (specify which traffic is allowed to transit and block everything else), we need to add a manual rule at the bottom of the rules in the “application rules” category to deny all the traffic.

Sections and rules

Within the distributed firewall portal, you can then create sub-sections and then creates rules within each section.

Each rule is a standard firewall rule:

It’s nothing out of the ordinary – each firewall rule has a name, a source (a group called “Nico’s VM”), a destination (“any”), services (typically TCP/UDP with a port number or internet control message protocol (ICMP)) and an action (Allow, Drop or Reject) and whether we want to log into VMware Log Intelligence (our Cloud Log Platform).

Inventory, Grouping and Tagging

Above, you saw I had created a group named “Nico’s VM”.

The concept of grouping is to enable us to create a group of objects based on criteria and apply a security policy to this group.

Tagging allows a user to assign tags to virtual machines. These tagged virtual machines can be automatically made part of a group that is used for firewall policies.

We can create grouping objects based on different criteria such as:

  • IP Address
  • VM Instance
  • Matching criteria of VM Name
  • Matching Criteria of Security Tag

Let’s try these out:

Groups based on IP address:

Group based on a single IP address or a classless inter-domain routing (CIDR) range or both. For example, I created a group of 10.10.0.0/16 and the unique IP 10.20.34.56.

Groups based on VM instance

Group based on manually selected VMs. It has limited value as only 5 VMs can be added to this group. For example, I created a group with a single VM called “WindowsM” (yes, that VM was supposed to called “WindowsVM” but my fat fingers let me down).

Groups based on name

Groups based upon the names of the VMs. If you build a consistent naming convention (for example, COUNTRY-CITY-DC-PROD-APP-NUMBER), your VM (for example, UK-LONDON-DC-TEST-SQL-01A) could automatically, at creation, be attached to a security group and be assigned a number of security policy.

As its name includes TEST, there might be a rule specified in the Environment Section that this group cannot talk to PRODUCTION.

Ai its name contains SQL, there might be a rule specified in the Application Section that only port 1433 for SQL is allowed to that VM.

There are multiple advantage of building policies like this is that: 1) from day 1, the VM is protected, 2) you have security consistency and 3) your security rule reads more like a business logic (instead of trying to work out what IP addresses represent).

In the example below, I have built a group called “webSG”. If a VM has “web” in its name, it will automatically become part of the group and only 443 or 80 traffic will be allowed.

All these VMs below were automatically added to the group. Actually WebServer-4 was created after I had created the group and was added to this group automatically and secured at birth.

Groups based on tags

Tags have become very popular in the Cloud era and have been especially useful in the AWS world to operate a cloud platform at scale. Tags can be used to identify cloud entities and to verify costs and charges based up on these tags. Tags can be represent business units, tenants, countries, environments (test, dev, prod), etc….

In the lab I shared with the other Cloud Solution Architects, I decided to tag my VMs with my name (nico).

As soon as the group is created, I can immediately see which members are part of the group and if it’s used anywhere (View References will tell me if it’s used by any firewall rule).

 

In practical terms, this helps users greatly simplify their security policies and use metadata to build security policy instead of leveraging IP addresses like in ‘traditional’ firewalls.

VMware Cloud on AWS Resources

Check out my personal blog #RunVMC for more on VMC on AWS. Here are a few deep dive posts:

Hands-on Lab (HOL): Test drive for free, no installation required!