In the beginning of 2022, I attended the “VMware Cloud Director: Advanced Networking with NSX-T Data Center” training for VCD 10.2. The training touched on a couple of topics, that are blog worthy. Let’s start with the third one in this latest Cloud Director series. Previous ones in this series are:
- Cloud Director tidbits: DHCP Modes with NSX-T
- Cloud Director: Comparing Data Center Group network features
Since Cloud Director (VCD) 10.2, one or more NSX-T backed Virtual Datacenters (VDC’s) belonging to the same tenant can be grouped together in so called Data Center Groups (DCG) up to a maximum of 16 VDC’s in single DCG. It’s primary function is to provide cross-VDC network features, like:
- Centralized networking administration
- Centralized egress point
- East-west traffic between VDC’s in the Data Center Group
- Distributed firewalling (DFW) applied across a Data Center Group
Distributed firewall history
Let’s talk a bit more on the Distributed firewall (DFW) feature. It’s a feature released in vCloud Director 8.20 (Feb 2017) and enhanced with Security Groups in 9.0. Both were the first features available in the HTML5 interface and based on NSX-v. The feature is available via the “Security” section of an Organizational VDC (Org VDC), but must be enabled by the service provider first.
In the NSX-v era, the DFW was displayed in a separate browser frame as shown below.
Distributed firewall nowadays
As mentioned in the introduction of this post, the Distributed Firewall (DFW) is now part of the Data Center Group (DCG) feature when NSX-T backed pVDC’s are used. In practice it means that the DFW feature is moved from the Org VDC context (when using NSX-v), to the DCG.
Since VCD 10.3, Dynamic Groups are added are to the DFW feature set, which makes it much more usable because VM names and Security Tags can now be used in rules, instead of only Static Groups and IP Sets. A second advantage of Dynamic Groups is that they are shared between DFW and Edge gateway rules, which prevents configuring separate rules.
Compared to NSX-v, the Distributed Firewall in now fully embedded in the DCG section of the VCD UI.
Enable the Distributed Firewall
Step 1: Modify the Rights Bundle
Before tenants can use the DFW feature, the “write” permission to “Configure VDC Group” must be added by the provider to the “Default Rights Bundle” or assigned to a new one. Only after the modified rights bundle is published to tentants, the feature will be available to an Org Admin.
Step 2: Create a Data Center Group
Secondly a Data Center Group must be created from within the Networking top menu by the tenant.
Step 3: Activate the Distributed Firewall
The third action is to activate the DFW in a Data Center Group. By default, only the provider can activate DFW. When tenants should be able to do so, change the default rights bundle or modify the newly created one in the previous step and enable for the “Enable / Disable Distributed Firewall” permission in the Networking section. If activated, additional charges may apply for the tenant when using the DFW feature.
Step 4: Add networks
The last step before the DFW feature can be used is to add networks to the DCG. The DCG in this case acts as the boundary and the added networks determine the scope (or reach) of the DFW rules. So in short, if a VM is attached to a network that is not added to the DCG, the DFW rules will not apply to those VM’s.
Using the UI, a tenant can added network to the DCG by creating a new network or import an existing network Org VDC. In my example I have added 3 networks to the DCG of which the “Seg-isolated-1” network has a VM attached to it.
Using the Distributed Firewall
Now all prerequisites are done, the DFW can be configured. Before creating the actual rules, groups or IP Sets need to be created, because DFW rules are based on them.
Distributed Firewall grouping
Using VCD, grouping can be done in 3 ways:
- Based on Static Groups
- Based on Dynamic Groups
- Using Security Tags
- Using VM names
- Based on IP Sets
Option 1: Based on Static Groups
When using a static groups, a group is created to which one or more networks are added. When using the static group in a DFW rule, the rule applies to all VM’s that are attached to the networks in the group.
By using the “Accociated VMs” menu option, it can be checked which VM’s are connected to the networks in the static group.
Option 2: Dynamic Groups
Dynamic groups are used to group VM based on VM Name, Security Tag or both. When creating a Dynamic Group, by default it has single criteria and rule. When needed it can be extended up to 3 criteria, with 4 rules each.
Multiple criteria act as OR operator, multiple rules within a single criteria act as AND operator. Every rule can be based on a Security Tags or VM Name.
The Security Tags need to be configured in their respective section next to the Dynamic Groups section. Within this menu, the Tags itself is defined as well as the VM’s it’s attached to.
Option 3: IP Sets
IP Sets are often used to group resources outside of the VCD Organization, like the Internet of comapny WAN. In that case IP addresses or subnets are the only way to group them.
Distributed Firewall rules
When actions the previous steps are in place, it’s time to create the rules. In the “Distributed Firewall” section of the DCG. Via the “Edit Rules” option new rules can be created and existing ones can be modified. The rules themselves are based on:
- Application
- Context
- Source
- Destination
- Action
- State
To conclude
Since the introduction of NSX-T based Data Center Groups and Dynamic Groups in recent VCD versions, they make a good combination to implement the Distributed Firewall feature by providing centralized networking administration. For example creating DFW rules across multiple Org VDC’s (which can span multiple regions and even availability zones). A good second is that Dynamic Groups are shared between the DFW and Edge Firewall, which eases managing the environment.
Remember that by default the DFW feature cannot be enabled and used by tenant. It requires a change to the assigned Rights Bundles by the provider. This is probably done because the DFW feature raises the licensing cost for providers who use rental licenses as part of the VMware VCPP program. Providers often will charge their customers for using this additional feature.
Useful links
New Networking Features in VMware Cloud Director 10.2
New Networking Features in VMware Cloud Director 10.3
Managing Data Center Group Networking with NSX-T Data Center
0 Comments