The VMware Cloud on AWS (VMC) SDDC 1.5 Patch 1 included a range of new features and brought the full power of the NSX-T platform to VMC as a generally available feature. In this blog post, we discuss the new Distributed Firewall capability which enables granular control over East-West traffic between application workloads.
.terminal {
border: 1px grey dashed;
padding: 10px;
background-color: whiteSmoke;
color: black;
font-family: “Lucida Console”, Monaco, monospace;
font-size: small;
line-height: 1.5;
}
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.
Before we jump straight into the PowerShell functions that I have built which consumes the NSX-T Policy REST API, I thought it would be useful to share some basics on how the DFW API works for those that may want to consume the REST API using another language other than PowerShell. When you navigate to the Distributed Firewall UI in the VMC Console (shown above), you will notice there are four pre-defined categories(non-editable) of rules: Emergency, Infrastructure, Environment and Application.
- To be able to query or create new DFW rules, you will first need to know the ID of the specific category where you wish to create or query the DFW rules. To do so perform a GET on /policy/api/v1/infra/domains/cgw/communication-maps
- Once you have the specific category ID, you then need to retrieve the ID of the Firewall Section which is a way to logically group a set of DFW rules. To do so, perform a GET on /policy/api/v1/infra/domains/cgw/communication-maps/[communicationMapId]/communication-entries
- Once you have both the Category and Section IDs, we can then list all DFW rules by iterating through each entry using a GET on /policy/api/v1/infra/domains/cgw/communication-maps/[communicationMapId]/communication-entries/[communicationEntryId]
- To create or update a DFW, it is simply performing a PUT on /policy/api/v1/infra/domains/cgw/communication-maps/[communicationMapId]/communication-entries/[communicationEntryId]
In summary, DFW rules are located within the Communication Entry (Firewall Section) which is then part of a Communication Map (Firewall Category) API. I can not speak to the naming of the API, but I definitely would have liked to see the NSX-T Policy API map closer to what customers see in the NSX-T UI in VMC.
Now that we have some background on where and how to manage DFW rules using the NSX-T Policy API, let’s now take a look at the four new PowerShell functions that I have created to make consuming DFW rules easier.
Note: At this point, I will assume you have already familiarize yourself with my NSX-T Policy PowerShell Module, if not, please take a look at these two articles here and here before proceeding further.
The first is Get-NSXTDistFirewallSection function which as the name suggests, lists all Firewall Sections for all categories (e.g. Emergency, Infrastructure, Environment and Application). This is needed if you do not know the specific Firewall Section you wish to work with (as mentioned earlier).
Get-NSXTDistFirewallSection
We also can filter by a specific Firewall Category by simply using the -Category parameter which will auto-complete the four pre-defined categories as shown in the screenshot below or you can filter for a specific name using the -Name property.
Get-NSXTDistFirewallSection -Category Application
If you recall from the VMC Console UI screenshot earlier, we have a few DFW rules that have already been defined in the “Application” category under the “App Section 1” Firewall Section. Let’s take a look at how we can retrieve the DFW rules using the Get-NSXTDistFirewall function which requires passing in -SectionName which we have from the previous step.
Get-NSXTDistFirewall -SectionName “App Section 1” | ft
The output is simliar to that of the VMC Console UI, but you also get additional details such as the specific sequence number for a given DFW rule which can be helpful for how you wish to order your rules.
Before we can create a new DFW rule, we need to make sure that our desired Source, Destination and Service groups exists. For example, the DFW rule which has “App Server 2” as the Source is simply an NSX-T group that I had already defined to match a specific criteria, in this case an IP Address but you can use NSX-T Tag(s), VM(s) or Conditional Statement(s). To create a new NSX-T Group, you can use the New-NSXTGroup and to view existing groups, you can use Get-NSXTGroup and specify the -GatewayType to be CGW as that is where the DFW rules will live for our workloads.
To create a DFW, we will use the New-NSXTDistFirewall function which accepts a number of arguments which you can see below:
New-NSXTDistFirewall -Name “App1 to App2” -Section “App Section 1”
-SourceGroup “App Server 1”
-DestinationGroup “App Server 2”
-Service SSH -Logged $true
-SequenceNumber 5 `
-Action ALLOW
SourceGroup, DestinationGroup and Service accepts the “friendly” display name and the PowerShell function automatically translates them to their respective paths which is what the underlying NSX-T Policy API expects when creating a new DFW rule. If we now re-run our Get-NSXTDistFirewall function, we should now see our new DFW rule which you can also confirm by looking at the VMC Console UI.
To remove a DFW rule, we will use the Remove-NSXTDistFirewall function which requires both the Id of the DFW rule along with the section name as that is required for us to locate the specific DFW rule to remove.
Remove-NSXTDistFirewall -Id 9ce50869-50b0-4dd5-8854-5dd8b9c976aa -Section “App Section 1”
Hopefully these PowerShell functions will make managing large number of DFW rules much easier in VMC and if you have any feedback, feel free to leave a comment or if you wish to contribute, drop me a pull requests with your enhancements!
Finally, I know a few of you have been asking about exporting the DFW rules into other formats such as a JSON or CSV file. The former is actually quite easy, simply take the output of the Get-NSXTDisFirewall and pipe that to the ConvertTo-Json cmdlet as shown below.
Get-NSXTDistFirewall -SectionName “App Section 1” | ConvertTo-Json
For CSV, you will need write your own logic to perform the conversion because the ConvertTo-Csv cmdlet does not support nested objects which DFW rules will contain. Although you can easily export the DFW rules as I have shown, the next question that I usually get asked is how to re-import them. This is the actual challenge and although the output looks like a “string” or “IP Address”, the actual entry is an NSX-T object which may have been defined as a string or some other criteria, so it is not as simple as just re-creating the DFW rule with this output. I know having the ability to easily export/import Firewall rules into VMC is highly sought after, especially with similiar functions I had built for NSX-V based SDDC. For now, you can at least export all rules for archival and change management purposes in case you need to re-create them in the future.
