Browse Author

Erik Hinderer

Deploying VMware NSX-T Identity Firewall on VLAN-backed Networking without an Overlay

VMware NSX-T Identity Firewall in provides even greater capabilities than it’s predecessor in NSX-v. NSX-T 2.4 is capable of supporting up to 16 vCenter Servers and 1,024 hosts, which provides clients with the ability to achieve multi-vCenter Identity Firewall security policies, simplifying deployment and reducing overall administration.

In the first part of this three-in-one blog series, we’ll cover deploying the VMware NSX-T Unified Appliance and configuring a 3-node Management Cluster. The next part will cover adding a compute manager (adding a vCenter Server), creating a Transport Zone and Transport Nodes (configuring TEPs on ESXi hosts), creating Logical Switches / Ports and then re-configuring VM port groups from VDS to N-VDS backed Logical Switches. Then we’ll wrap up the three-in-one series with enabling Identity Firewall, configuring Active Directory integration, creating security groups with AD-based user mappings and firewall rules to demonstrate AD-based firewall rule security.

(*All steps have been recorded to my YouTube channel in a playlist at the end of this post – but please read the post for insight before watching the recordings)

Part 1 – Deploying NSX Manager and Configuration of the 3-node Management Cluster

Before starting the deployment of NSX-T 2.4, ensure that you have three(3) available hosts that have been patched to ESXi 6.5u2 P03 / 6.7 u1 EP06 or greater. You should always check the interoperability of VMware products in the VMware Product Interoperability Matrices before performing upgrades or deploying new solutions. You can upgrade VMware vSphere hosts by attaching and remediating the default Critical Update baseline in VMware Update Manager, as shown in the video or in the VMware Update Manager Documentation.

Once vCenter and vSphere hosts are patched to the required version, the installation of NSX-T Manager 2.4 is performed by deploying the NSX Unified Appliance via vCenter to the first of the 3-nodes in our vSphere cluster. An anti-affinity separation rule should be created to ensure NSX Manager appliance VMs are separated from each other within the cluster, unless there is a host outage or related cluster failure. The NSX-T Manager appliance requirements for a small instance are 2 vCPUs, 16GB RAM, 200GB storage. Check NSX-T sizing guidelines and system requirements in the NSX Manager VM System Requirements before deploying.

After the OVF has been deployed, we start configuring our NSX Manager 3-node cluster by logging into NSX Manager and adding a Compute Manager (vCenter Server). The NSX-T 2.4 UI now starts with a new wizard (until opted out or the system is configured). While having a wizard added to the new version is a very compelling new feature, it does provide a link to click for Advanced Configuration that ends the wizard and returns you to the UI. We’ll use the advanced configuration for our purposes and it’s advisable for anyone who knows the requirements for their design and how to configure them.

Part 2 – Adding a Compute Manager – Configuring a 3-node Management Cluster – Creating a Transport Zone and Transport Nodes

Add your vCenter Server as a Compute Manager, by clicking on Fabric and then Compute Managers. Add any vCenter Servers with vSphere clusters that you’ll be hosting workloads on. Once you’ve got a Compute Manager added, we’ll move on to the next step of adding two additional NSX Manager nodes, to our 3-node management cluster.

To add nodes to a new NSX-T 2.4 deployment, click on Overview and then Add Nodes in the Management Cluster. You’ll need to deploy two(2) additional nodes to the primary node that was deployed by OVF, in order to have a 3-node, highly-available NSX-T Management Cluster. The NSX-T Management Cluster – Add Node wizard will prompt you to specify a Compute Manager (vCenter w/ the 3-node cluster), credentials, the size or form factor, a node name, cluster, host, datastore, network (Port Group) and IP address information for the management interface. As a special note, the node name will be used for the VM name of the NSX-T Manager VM deployed by this process. After a Management Cluster node, is added, vCenter deploys a new NSX-T Manager VM to the node or resource pool specified, assigns them a secondary role and synchronizes them to the primary NSX-T Manager node.

*Adding more than two secondary Management Cluster nodes will not affect or improve availability, as NSX-T 2.4 will only utilize a 3-node cluster for NSX Manager roles and Repository synchronization. The capability to add additional nodes, is designed to assist with NSX-T host migration, NSX upgrades and or infrastructure replacement, before removing an active node.


Now that we’ve established a 3-node Management Cluster, we’re ready to configure a VIP (virtual IP) for the Management Cluster. You can still access the primary NSX Manager node via it’s IP address, but the Management Cluster VIP should be used for NSX Management and Operations.

Since we have a new NSX Management Cluster VIP, we’ll open a new browser window to configure the rest of the environment from the VIP we created.

Before we begin configuring networking for the NSX-T let’s try to level set and understand what we’re really doing. Deploying NSX-T without an overlay and routing components requires that we have hosts connected to VDSs that we can VLAN bridge to N-DVS Logical Switches. To establish redundant connectivity on ESXi hosts with VLAN bridging in NSX-T, each host will need two network interfaces on a VDS and two interfaces on a N-VDS. The host network interfaces on the VDS should be configured to deliver any and or all VLANs that you intend to serve from the NSX-T environment.

With that said, we now need to check each ESXi host to determine what interfaces are not in use and which we’ll use for our Transport Nodes. Only hosts with VM workloads that you wish to protect with Identity Firewall or the DFW need to be Transport Nodes. Hosts with NSX managers or NSX components do not need to be configured at Transport Nodes.

In my lab, vmnic0 and vmnic1 are on a VDS served by the vCenter and vmnic2 and vmnic3 are not in use and what I’ll use to configure my Transport Nodes.

To configure Transport Nodes, you can choose to do this individually or per vSphere Cluster. I prefer to deploy by vSphere Cluster when possible, so we’ll select the cluster for Skunkworks-Compute, where my lab VM workloads are hosted and click Configure NSX.

Clicking Configure NSX starts the Configure NSX wizard and will prompt you to select a Transport Node Profile. As we have not created a Transport Node Profile, we click on Create New Transport Node Profile, name it and then click the Create New Transport Zone link located just below the Transport Zone selection.

Name the Transport Zone something logical like tz-vlan-backed, enter a name for the N-VDS and select your Host Membership Criteria and select VLAN as the Traffic Type. After filling out the first tab for General, click the N-VDS tab, select the N-VDS from the dropdown that you created, select the default NIOC profile, and under the Uplink Profile dropdown, click Create Uplink Profile. In the Uplink Profile form, enter a name for the Uplink Profile and under Teamings, select the default teaming, set the Teaming Policy to Load Balance Source and type your vmnic names in the Active Uplinks field. In my lab, I’m adding vmnic2 and vmnic3 as previously referenced. Set the Transport VLAN to 0-4094 to allow all VLANs or enter the VLAN ID that you want to use. Enter the MTU that you have configured across your network or leave it blank to set it to the default of 1600. Select LLDP, Send Packet Enabled from the LLDP dropdown and enter the names of the Physical NICs and choose which profile vmnic you want to bind it to. In my lab, once again, I bind physical NIC vmnic2 to profile vmnic2 and physical NIC vmnic3 to profile vmnic3. The IP Assignment field is greyed out as I’m leveraging DHCP in my lab for Transport Nodes. An IP Pool or static IP can be set, but from my experience, it’s far easier to set reservations and manage those, versus the other options, as the use of DHCP is beneficial to extending addressing as you grow. At this point, we’ve filled in the Add Transport Node Profile form and we’ll click Add to complete it. Completing the Transport Node Profile wizard returns you to the Configure NSX wizard, where you left off, to select a Transport Node Profile. Select the Transport Node Profile that you created in the wizard and click Save.

After clicking Save on the Configure NSX wizard for our compute cluster, the Configuration State of the hosts will show “NSX Install In Progress” and change to “NSX Installed” with a Node Status of “Up” once completed. The Configure NSX function is installing the NSX-T VIBs (VMware Installation Bundles) on the hosts, starting their services and establishing communications. As an estimate, configuring NSX on a Host Transport Node, through to communications being established and the Node Status showing “Up”, will take about 5-10 minutes per host in most environments.

Part 3 – Create Logical Switches and Change VM port groups from VDS to N-VDS Logical Switches / Configure Active Directory / Enable IDFW and Create Active Directory based NSGroups and firewall rules

Now that we’ve connected our NSX-T hosts / Transport Nodes to our VLAN backed Transport Zone and N-VDS, we need to create Logical Switches for our workload VMs.

To create a NSX-T Logical Switch, click Advanced Networking & Security in the top toolbar, click Switching on the left navigation pane and then click Add under the Switches tab. Name the Logical Switch, select the Transport Zone you created from the dropdown, use the default Uplink Teaming Policy, ensure Admin Status is set to Up and enter the VLAN ID you wish to host on the Logical Switch. Use the defaults on the Switching Profiles tab and click Add.

At this point, we’re ready to change VM NIC Portgroups from VDS to the NSX Logical Switch. Move the required VMs from VDS to NSX Logical Switch by editing the VM and changing the Port Group of the Network Adapter to the NSX Logical Switch created for it.

Now that we’ve migrated VMs to NSX Logical Switches, we’ll now configure Active Directory and enable IDFW.

To configure Active Directory integration in NSX-T, navigate to System and Active Directory. Click Add Active Directory and you’ll be prompted to enter the FQDN (domain name), the Netbios Name, the Base Distinguished Name (Base DN) and specify a LDAP synchronization interval. Next, click on LDAP and enter the LDAP server IP/FQDN, port and an AD account with permissions to query the entire directory tree.

At this point, you’re now ready to create NSX Security Groups (NSGroups) and map Active Directory groups to them.

To create a NSX-T NSGroup for an Active Directory User Group, click on Advanced Networking and Security, then Inventory, then Groups. Click Add, name the group and then select Members from the Members tab with the object type, AD Group as shown below. The search field in the available groups helps to filter large lists of groups, so make good use of that. Select and move the AD Group desired to the Selected field and click Add.

Now create NSGroups for your VM workloads. In my lab, we’re going to demonstrate implementing a simple prod / non-prod security policy with NSX Security Tags. We add a new NSGroup, name it prod and then on the Membership Criteria tab, choose Virtual Machine – Tag – Equals – prod – Scope – Equals – (blank or create a scope). After that, we do the same and create a NSGroup for nonprod.

We’re closing in to the final step of configuring Identity Firewall rules for our prod and non-prod applications based on our Active Directory mapped NSX Security Groups.

For the lab, we create a rule to grant NetAdmin group users access to any systems, a rule for production access and a rule for non-production access. Then we create two app to app traffic rules to allow prod to prod and non-prod to non-prod. We follow that up with a implicit deny in the App to App firewall rule section to block any traffic not allowed and we’re off and running with our lab setup.

As you can see from the Identity Firewall example in my lab, controlling access based on Active Directory user groups and NSX VM security tags, enables security teams with a easy to use, uniform firewall solution for the data center, cloud and PaaS environments alike. As always, if you’ve got questions or something that you’d like to see demonstrated, hit me up here at, on Twitter or on LinkedIn. Until the next post, enjoy Active Directory integration with NSX-T and #runNSX!

YouTube video recording playlist: Deploying VMware NSX-T Identity Firewall on VLAN-backed Networking without an Overlay

How To Export VMware Licensing From vCenter Server

Here’s a helpful script to Export VMware Licensing From vCenter Server, which I wrote this back a bit ago and many of my VMware peers have found quite useful in the field. I finally got asked again by someone, so I decided to post it, instead of trying to email zipped code through antivirus systems. Enjoy! Happy licensing!


Disclaimer: ensure a semi-current Powershell / PowerCLI installation

Using the VMware Log Insight – Cisco ASA Content Pack to gain visibility and alerting

For those unaware, VMware Log Insight, is VMware’s syslog monitoring and alerting platform. It collects and automatically identifies structure in all types of machine-generated log data (application logs, network traces, configuration files, messages, performance data, system state dumps, etc.) to build a high performance index for performing analytics, so you can find pertinent information quickly.

With that being said, I do a lot of Log Insight use and am a big fan of the Content Packs that provide 3rd party integration. After showing this to clients for the last few months and having them rave about the dashboards and alerting in Log Insight, I decided to dedicate a post to configuring and using the Cisco ASA Content Pack for Log Insight.

The VMware Log Insight – Cisco ASA Content Pack provides new visibility, insight and alerting capabilities into firewall events, successful and denied connections, top source and destination dashboards for websites, bandwidth consumers, mail, chat, streaming, VPN connections and more. For a full overview of VMware Log Insight capabilities, check out the technical marketing material on the product site at

To configure your Cisco ASA for use with VMware Log Insight:

  1. Log into the Cisco ASA and enter configuration mode

  2. Configure the logging host

  3. Configure the logging trap level

  4. Configure the logging facility level

  5. Save the configuration

#logging host inside ip.of.log.insight
#logging trap informational
#logging facility 20


After configuring your ASA for use with Log Insight, you need to install the Cisco ASA Content Pack for Log Insight by clicking on the menu, which is the icon with three lines to the right of the username in the upper-right, then click Content Packs and then click on the Marketplace navigation on the upper-left of the screen as shown below. Find the Cisco ASA icon in the Log Insight Content Pack Marketplace and click it to install it.



After you’ve installed the Content Pack, log out of Log Insight and log back in. Navigate to the Content Pack Dashboards and click on the Cisco ASA Overview link.

The Cisco ASA Overview dashboard provides you with dashboards of All ASA Events over time with a histogram, a breakdown of events grouped by device, events by class and severity level, as well as, top destinations and sources. From here you can click on any graph and click Interactive Analytics to see a filtered view of the actual log events.



As you can see in the Interactive Analytics view of ASA events grouped by severity level, the Cisco ASA firewall is denying connection attempts for telnet to the outside interface of the firewall. The next thought is, “…geez, VMware, I wish I could easily setup an email alert for this filtered event on my Cisco ASA”. Well, I’m happy to add that WE CAN SETUP ALERTS IN LOG INSIGHT! YES!


Let’s take a look at how we setup a Log Insight alert for an event from our Cisco ASA.
To add an alert for Severity 3 events, go into the Interactive Analytics view for ASA events grouped by severity 3.



Click on Alerts, which is the red bell icon to the upper-right and then click on Create Alert from Query.



Fill in the New Alert form providing the name, description and recommendation, an email address or alias and then the criteria for the alert. You can match on any instance of an event, when an event is seen for the first time in the last x hours, or by how many occurrences happen in a given period and by group if desired. In any case, for this alert, I’d like to know anytime it’s more than one occurrence in five minutes.



Now that we’ve set an alert in Log Insight for our Cisco ASA, let’s take a look at some of the dashboards and information that the Content Pack provides visibility into.


Navigate to Denied Connections under the Cisco ASA Content Pack and you’re greeted by a dashboard of Top Denied Destinations, Top Denied Sources, Top Denied Protocol Groups and Top Denied Websites. Each of these can be drilled down into by right-clicking on a graph section and clicking Interactive Analytics to see the data. The Top Denied Sources is quite useful to determine where attacks are originating and can quickly provide you with a list of sources to take action on.


The Successful Connections Dashboard shows some really useful views of Top Accessed Destinations, Top Websites, a list of Latest Successful Connections and a graph of Reasons for successful TCP teardowns.


Besides looking to see that Facebook, Hulu or Youtube is probably the top accessed website from your firewall, the Latest Successful Connections is a great way to see if a new firewall rule or configuration change is working for clients accessing a new site or the like.



Clicking on the Traffic Overview dashboard reveals a fantastic histogram graph of bandwidth usage, which can be useful for forecasting and planning. The middle of the screen shows a graph of Top Connections With High Bandwidth Usage, to see who the big consumers are. Once again, you can drill down on any of those users to see what was being used. The user in this graph is my son’s Chromebook and I’m sure the bandwidth usage is from Youtube, no doubt. …was there any doubt? /grin


Lastly, the VPN Activity dashboard is great for analyzing past and for alerting on current VPN events. You can setup alerts for failed VPN connection attempts, which is always something to keep an eye on.



Wrapping it up, there’s quite a bit that VMware Log Insight can do for Cisco ASA users. The alerting capabilities for ASA events make Log Insight a great solution for environments where it’s deployed, as the Content Pack is free of charge, easily deployed and provides new visibility and “insights” into what’s happening on your ASA. …with or without you knowing. /grin