Posts

Using PowerNSX to Build NSX Distributed Firewall Rules

I've been helping one of my customers set up a proof of concept NSX implementation, which has involved configuring and then destroying several firewall designs.  In order to speed up this process, we've had to get pretty good at using PowerNSX to script out the creation of those NSX firewall rules (and other security objects).

First, how do you get PowerNSX?  Just like PowerCLI!  Open up your PowerShell window, then use this command: Install-Module PowerNSX

Now that you've got PowerNSX installed, take a moment to look at what it does for you.  Look at all of the available cmdlets by using: get-command -module PowerNSX

There's a lot going on there!  In general, the PowerNSX cmdlets use the normal PowerShell verbs: get, set, add, remove, and new, and the nouns are prefixed with NSX.  So, if you're using tab completion to figure out what command you're doing, <verb>-nsx... is usually a pretty safe place to start.  For example, if I want to get my security ta…

Finding Servers Created within the Last Year

One of my customers recently asked me to generate a report showing all of the VMs that they had created within the last 12 months (ideally, broken down by OS), and then another showing the same for 24-12 months ago.  I did a bunch of digging around and couldn't find any attribute on the VMs that showed their creation date.  Some research revealed that the standard solution to this problem is to get-vievents for all of the VMs, then look at the date of the first event.

Unfortunately, this customer had performed a vCenter migration about a year ago, so our logs weren't intact for this purpose.  I was stumped, but one of the other admins came up with a good idea: look at the AD objects instead of the VM objects.  AD objects actually have a .whenCreated attribute, so we just need to grab them all and then find the ones for our desired timeframes.

Of course, that approach grabs all AD computers, including desktops.  We just needed a list of servers (we knew that all servers would b…

Getting a list of All ESXi Hosts and their WWNs

One of my customers was doing some work on their storage network and so wanted a list of all ESXi hosts and their WWNs.  This struck me as another excellent scripting opportunity, so I pulled out my old Brocade 1:1 Zoning script and went to work.  I really only needed a one-liner for this situation, so I extracted my needed syntax from that script and quickly put it together.  Here's the (admittedly, ugly) command that I came up with:

get-vmhost | select name,@{N="WWNs";E={($_.ExtensionData.config.storagedevice.hostbusadapter.PortWorldWideName | % {("{0:X}"-f$_ -split '(..)' | ? {$_}) -join ':'}) -join ", "}}

That'll spit out a list with two columns, ESXi host names in one, and a comma separated list of WWNs in the other.  So, what's that ugly expression in that select statement doing?  Well, it's collecting all of the port WWNs on that ESXi host, then converting each one from decimal into hexadecimal (the "{0:X}"…

Using Mandatory Profiles to Speed Up Logons for RDSH Servers

I was building a VDI solution for one of my customers that leveraged App Volumes to build RDSH servers, which in turn presented applications via Horizon (is it still fair to call it a VDI solution if there's no desktop OS involved?).  We were managing the user experience persistence via User Environment Manager, so the RDSH servers were stateless and no unique data would ever live on any of them.  It's a really cool solution, but we ran into that classic VDI issue: slow logons.

Fortunately, since that is such a classic issue, there's a huge list of things to do to alleviate it.  In this case, since the user's profile lives independently of the server to which they've logged on, we have a really powerful tool available to us: the Mandatory Profile.

Windows does a lot of profile customization when a user logs in for the first time, which is great on a persistent desktop!  In a nonpersistent environment (which, for all intents and purposes, any RDSH solution is, becau…

Running App Volumes with a SQL Always On Cluster

One of my customers has been deploying App Volumes, using their SQL Always On availability group for the database.  They pointed at the listener and everything looked good... until they initiated a failover.  Fortunately, the fix was really simple, although two part.

First, we noticed that the ODBC connections were using the default "SQL Server" driver.  That immediately stood out to us as a problem, as that driver can't handle AO failovers (exactly what we saw).  So, we switched it over to the Microsoft ODBC Driver 13 for SQL Server driver and figured that we'd be good to go.  Almost.

When we attempted to connect to the App Volumes Manager, we received a DB access error.  We saw that it was using the correct driver (yay!), but it was getting a credentials error because it was trying to use the server's computer account.  Some quick google searching pointed me at an article about changing database credentials in App Volumes, but that was for a fairly old version …

NSX Security Groups and Firewall Rules

As a next-gen firewall, NSX allows us to get very dynamic with our firewall rules and create complex behaviors out of comparably very few rules.  Let's look at the same example 3 Tier Application rule set that I wrote about in my post about the Direction and Applied To fields in NSX Firewall rules post, and look at how these groups could be configured and then we can look at how these rules could be made even more secure.  First though, here's the example rule set:

SourceDestinationActionApplied ToAnyInfraServicesAllowDFWClient DevicesWebAllowWebDB, AppWebDenyWebWebAppAllowAppDB

Direction and Applied To for NSX Firewall Rules

I've had the chance to learn about NSX lately, which has included really diving in to how the firewall behaves.  While it can certainly be used very much like a traditional firewall, you're not doing yourself any favors by doing so.  Remember, this is a policy-based firewall, so our goal is to define as many general behaviors as possible and then have them apply intelligently to the correct VMs based on attributes such as Security Tags.

There's a lot to dig into on this topic, but for now I want to focus on two attributes of a firewall rule: Direction and Applied To.  These two settings can be used to dramatically simplify a firewall configuration and can lead to some unexpected results if not used correctly (also, they took me quite a while to wrap my head around).

The most important thing to remember is that, like all firewalls, NSX eventually boils down to a sequential list of rules.  NSX will do whatever action is specified in the first rule to match a given flow.  Whe…