NSX

In VMware Cloud on AWS (VMC), the default behavior of the NSX-T Distributed Firewall (DFW) is to currently allow all traffic between compute workloads even across different logical networks (Segments). Today, the default behavior is currently not configurable and is something the NSX team is looking into with a few update of the VMC Service.

Having said that, it is actually pretty straight forward to create a new Deny All policy that would achieve the same desired behavior of blocking all traffic by default. Since this topic has come up a few times, I figure it would be useful to share the quick fix and big thanks to Michael Kolos, one of our VMC Customer Success Engineers who shared the original tidbit with me.

Back in November 2018, VMware Cloud on AWS (VMC) SDDC 1.5 Patch 1 was released and it was one of the most highly anticipated release by our customers. Although this was a "patch" release, it included a ton of new features and also brought the full power of the NSX-T platform to VMC as a generally available feature!

With NSX-T, customers also now have access to the highly requested Distributed Firewall (DFW) capability which enables granular control over East-West traffic between application workloads. In addition to enabling micro-segmentation in VMC, customers can now easily manage DFW rules using a number of grouping constructs (Tags, Virtual Machines & Conditional Statements) to create dynamic policies which follow their workloads.

Customers can configure DFW (as well as Edge Firewall) rules using the VMC Console UI but many of you have been asking for an automated method, especially if you need to create a large number of policies for more than a couple of workloads. After returning from the holiday, I spent the last couple of days updating my NSX-T Policy PowerShell Module which now includes basic support for managing DFW. For those of you who are new to using the NSX-T Policy API and PowerCLI, be sure to give these two articles a read here and here before proceeding further.

Earlier this week I had published an article on how to get started with the new NSX-T Policy API in VMware Cloud on AWS (VMC), if you have not read through that guide yet, I recommend you take a look at that first as this covers the prerequisites which will be required. As mentioned in that article, I planned to add a few more NSX-T Policy API examples and now the community NSX-T Policy PowerShell includes 10 additional functions which you can see the complete list below:

Connect-NSXTProxy

Get-NSXTFirewall

Get-NSXTGroup

Get-NSXTSegment

Get-NSXTService

New-NSXTFirewall

New-NSXTGroup

New-NSXTSegment

New-NSXTService

Remove-NSXTFirewall

Remove-NSXTGroup

Remove-NSXTSegment

Get-NSXTDistFirewallSection (as of 01/02/2019)

Get-NSXTDistFirewall (as of 01/02/2019)

New-NSXTDistFirewall(as of 01/03/2019)

Remove-NSXTDistFirewall (as of 01/03/2019)

Get-NSXTOverviewInfo (as of 02/02/2019)

Get-NSXTInfraScope(as of 03/14/2019)

Get-NSXTInfraGroup(as of 03/14/2019)

New-NSXTDistFirewallSection (as of 04/19/2019)

Remove-NSXTService (as of 04/19/2019)

Get-NSXTPolicyBasedVPN (as of 05/09/2019)

New-NSXTPolicyBasedVPN (as of 05/09/2019)

Remove-NSXTPolicyBasedVPN (as of 05/09/2019)

After importing the module, to see the list of all functions, you can run the following command:

For those of you who have attempted a vMotion (whether that is within a vCenter Server or between different vCenter Servers (including across SSO Domains), if the VM is running on a Distributed Virtual Switch (VDS) and the version of the VDS is not the same between the source and destination (VDS 6.5 to VDS 6.7), the operation will fail with the following error message (UI and API):

Currently connected network interface 'Network adapter 1' cannot use network 'DVPG-VM-Network (VDS-67)', because the destination distributed switch has a different version or vendor than the source distributed switch.

This behavior is no different on VMware Cloud on AWS (VMC) or at least, I thought it was, until I recently learned about a really neat feature that was introduced in the VMC 1.4p2 release, here is a snippet from the release notes:

Cross VDS version vMotion Compatibility
With this advanced configuration option enabled, bi-directional vMotion between on-premises and VMware Cloud on AWS can be achieved across different virtual distributed switch (VDS) versions (greater than or equal to version 6.0). This must be enabled on the on-premises vCenter.

It turns out there is actually a way to allow vMotions across different VDS versions, this is important for VMC because the software stack will always be using a newer version than what we ship to our onPrem customers. However, due to this limitation, we could not benefit from the latest VDS version but had to default it to VDS 6.0 to ensure that customers could migrate their workloads. The advanced setting mentioned in the release notes allows us to disable the strict compatibility check which is performed on the destination vCenter Server when a vMotion is initiated, this setting is now enabled by default on the VMC vCenter Server which is why you can perform migration across different VDS without having to do anything special on your onPrem vCenter Server.

UPDATE (10/16/18) - With the release of vSphere 6.7 Update 1, customers can now also vMotion VMs from on-prem running on a VDS to VMC with NSX-T N-VDS.

Today, when you deploy a new SDDC on VMware Cloud on AWS (VMC), NSX-T is now the default networking stack and NSX-V is no longer used for net new deployments. In fact, we are about to start migrating existing VMC customers who have an NSX-V SDDC and converting them to an NSX-T SDDC. Humair Ahmed who works over in our Networking & Security Business Unit has an excellent blog post here that goes into more details on what NSX-T brings to VMC.

Upon first glance, you might think that this is the exact same version of NSX-T that we have been shipping to our on-premises customers but in fact, it is actually a brand new and improved version. Similar to vSphere (vCenter and ESXi) and VSAN, VMC is always running a newer version of our software than our on-prem customers. One immediate difference that you should be aware of when using NSX-T in VMC is that the current NSX-T API is not available and instead a new NSX-T Policy API has been introduced to help simplify the consumption of NSX-T. All functionality in the current on-prem NSX-T API can be consumed using the new Policy API.

At VMworld, I spoke to a number of current and upcoming customers with NSX-T based SDDCs and they were really interested in using the new NSX-T Policy API and as the title of this blog post suggests, this will be a quick primer on how to do that. Before we get started, confirm that you have an NSX-T based SDDC deployed. If you are not sure, there are a few ways to determine this using either the VMC Console UI or API, instructions can be found here and here.

Certificate lifecycle management is not something anyone looks forward to, it is time consuming and usually not automated. However, it is a necessity for many of our customers. The process gets even more challenging when needing replace certificates across multiple VMware products, not only careful orchestration but also properly reestablishing trust between product just adds another layer of operational complexity. Within the Integrated System Business Unit (ISBU) at VMware, which produces both the VMware Validated Design (VVD) and VMware Cloud Foundation (VCF), the team has been working on a way to simplify certificate management, not only for individual products (working with product teams) but also holistically at the VMware SDDC level.

This initially started with the development of a tool called Certificate Generation Utility (CertGen), which helps customers generate new certificates for various products within the VMware SDDC. Although it was developed for the VVD, any VMware customer who consumed products within the VVD, could also leverage this tool. We all know certificate generation can be a pain, but it is not as challenging or as complex as the actual certificate replacement process itself which is also fully documented by the VVD team here.

This is where the new Fling comes in, the SDDC Certificate Tool, which automates the manual steps outlined by the VVD and helps customers easily replace certificates that they have created (CertGen or another process) and automatically orchestrates this across the different products within the SDDC. The tool is command-line driven and uses a JSON configuration file which can contain all or a subset of the VMware SDDC products, which is great for supporting different environments and allows for easy source control. Extensive pre-checks are also built into the tool to validate the certificates themselves (e.g. expiry, chain validation, etc) also also preventing miss-match of information (e.g. SAN entries, number of nodes, etc) which then get compared against your actual environment before any changes are applied. The JSON also contains a section referred to as Service Accounts, which is merely other VMware product accounts that the tool supports to reestablish trust after replacing the certificate for given product.

Primary Sidebar

Search this website

Author

William Lam is a Staff Solutions Architect working in the VMware Cloud on AWS team within the Cloud Platform Business Unit (CPBU) at VMware. He focuses on Automation, Integration and Operation of the VMware Software Defined Datacenter (SDDC).