Virtually Jason

I've had the chance to work on some NSX-T scripting lately, as we work to integrate some other solutions with the tool.  I don't have a ton of experience with API access, but I have been slowly learning... and one of the big hurdles that I had to overcome was just figuring out how to authenticate with the system!  So, that's where I'm going to start here. First, let's talk about the basics of how authentication works when accessing the API.  To use Basic authentication, you need to put together your credentials in the format of "username:password" and pass them to NSX-T.  Since this is being passed through a web request and special characters could mess everything up, so you need to Base64 encode that authentication string.  Once you've got it encoded, you need to put that into the Headers of your requests so that NSX-T will know who you are.  So, let's look at how to actually do that process! First, I'm going to prepare two variables.  One wil...

I've been writing some PowerShell scripts to automate NSX-T configuration lately, so I figured that I should put together a primer with notes about how to get started!  Firstly, if you're working with the API, you're going to want to be able to reference the official documentation .  There's a lot that can be done via the API, and that guide will tell you what calls to make to do most of it!  If you're like me and haven't spent a lot of time working with APIs before, that document will present a pretty steep learning curve... so I'm writing out my notes here, to make it easier for people to get started! At its most basic, using the API is just sending a web request to the NSX-T manager and then reading the response.  Since this is potentially sensitive information, you're going to have to authenticate with the server though, so you'll need to include a Header with that login information.  If you want to change anything, you're also going to need ...

One of my customers wanted an easy way to generate a report of all of their NSX Firewall rules as a CSV.  So, simply use get-nsxfirewallrule | export-csv and call it a day, right?  Unfortunately, the NSX Firewall Rule objects are a bit too complex to directly export as a CSV, so I put together a short script to unpack them.  Nothing's too complex here, but sometimes it's nice to have an easy script that just gives you the information that you need! Check out the script on Github !

As you've seen from my recent blog posts, I've been doing a lot of NSX work recently.  One of my customers has been working on a distributed firewall redesign and, as part of this effort, we determined that we needed to change the "AppliedTo" field for all of their existing firewall rules.  Because they have hundreds of rules, we knew that we'd need some sort of automated solution, lest we introduce unknown errors through our attempts at making these changes by hand.  Given my past experiences with PowerNSX (and the fact that it's my primary NSX management interface), I figured that this would be super easy, barely an inconvenience.  Whoops! PowerNSX is great, but it's a community tool at its core.  This means that the feature set that it has is limited to the intersection of features that the community has needed and those that the community has spent the time developing.  So, 99.999% of what I need is already there and I usually don't even need to ...

We've been doing a lot of work with the NSX Firewall recently.  Log Insight has become our go-to tool for troubleshooting to get real-time information about what the firewall is doing.  By far, the most common query that I run in Log Insight will be for all entries that have a vmw_nsx_firewall_src or vmw_nsx_firewall_dst of the IP Address that I'm interested in, and I'll often throw a vmw_nsx_firewall_dst_port or a vmw_nsx_firewall_action  into the mix to further refine my results. Unfortunately, these queries can be pretty slow.  They're great if you're looking at the last 5 minutes worth of data, and they're pretty good going back to the past hour... but when we went beyond a 1 hour window, we found ourselves needing to wait.  If we wanted to go all the way out to a 24 hour window, we'd need to go get lunch while the query ran.  That seemed unreasonable to us, so we opened a support ticket and the VMware engineer made some tweaks that absolutely hel...

Last month, I wrote about the progressive microsegmentation model that we've been using lately for our distributed NSX firewall.  Now, I want write about how we can figure out its implementation in a brown field environment! To do this, we heavily relied on vRealize Network Insight .  In short, vRNI creates a big index of all of the objects in your vCenter and on your network, including how they communicate together (all the way down to the specific route between any two devices!).  You can then execute queries against this giant index to pull out the data that you need.  In our case, we request all network flows for a given application, then analyze those flows to create an appropriate set of policies to apply to that application. Our first step was to identify the application.  This customer was fairly disciplined during the VM creation process in that they generally created a VM folder for each application that was being deployed and put the appropriate ...

We've been hard at work lately doing a large NSX Firewall migration, which hasn't lent itself particularly well to blog posts (since all of the scripts that we've created have been so customer-environment specific).  I've realized that the high-level process that we've created could be helpful for other people doing similar migrations though, so I figured that I'd go ahead and write about it! This migration has specifically been from a set of standard NSX firewall rules to a set of NSX policies.  Our goal with the creation of these policies has not been to recreate the existing rule structure, but rather to create a new policy structure that keeps everything running and really emphasizes manageability and progressive microsegmentation. First, I need to explain our concept of progressive micosegmentation.  Microsegmentation is basically the practice of creating policies to allow only the minimally required traffic into and out of each VM.  This is a very diff...

As you can tell by the kinds of posts that I've been making recently, I've had the chance to do a fair amount of work with NSX!  Within NSX, you can define IPSets to allow you to control the way non-NSX objects (such as physical devices) can interact with your VMs.  If you need to figure out which existing IPSet contains a given IP Address, you can run an easy VRNI query (ipset where ip address = <IP Address>)... but you don't always have access to VRNI!  So, I put together a PowerNSX script to check on it for me! Using this script is pretty simple: get-appliedNSXIPsets -ipAddr <IP Address in Question>.  It will return a table with three columns (NSXSecurityGroup, NSXIPSet, and IPAddress) and one row per unique Security Group / IPSet combination.  The script understands IPSets that list multiple objects, but only if they are whole subnets (defined with CIDR notation) or individual IP Addresses.  The script does not support ranges of IP Ad...

As I've been doing more NSX Distributed Firewall work, one of my customers came to me with an interesting challenge.  They had a fairly complicated application that they wanted to move into a microsegmented security model, but they only had a diagram from when the application was initially deployed and were confident that it didn't show everything that the application did or even all of the VMs that were part of the application.  It was an interesting problem, and since they had vRealize Network Insight deployed, the answer was fairly straight-forward! VRNI captures network traffic information from just about any device that can forward netflow data.  It uses that data to figure out which devices are communicating to each other, as well as highlighting all sorts of network issues like dropped packets or asymmetric routes.  In this case, I just used it as a giant repository of glorious 5-tuple data! I started by registering the application in VRNI.  I went t...

I've written before about creating NSX Distributed Firewall Rules  following a model that uses rules that will specifically hit traffic based on if it's Inbound or Outbound.  That model is also useful for creating NSX Security Policies, as there's no negative logic (NOT applied to object) in the rule set.  While that model works great, it can be a bit difficult to wrap your head around.  In turn, that can make it difficult to hand off to a customer... so we've been working on an alternate model. Unfortunately, this model does not work with Service Composer Policies, but it's flexible enough that it doesn't really need them.  It's based on a set of generic Security Tags (with corresponding Security Groups), that interact to create a dynamic micro-segmentation solution.  This model is based on defining a set of DFW Sections, each of which serves a very specific purpose in blocking or allowing traffic.  When creating new firewall rules, the administrato...

Well, that title sure is a mouthful!  But, it's also what this post is all about, so let's get to it!  One of my customers was experiencing an issue where it was taking longer than expected for an NSX firewall rule publish to propagate to all of their ESXi hosts. While troubleshooting the core issue, they needed a way to get better visibility into the process so that they'd know when their publishes had succeeded.  That data was not available in the GUI, but after asking a few friends at VMware, we learned that we could get to it through the API by a simple command: GET /api/4.0/firewall/globalroot-0/status .  Those are the facts that we collected, so here's what we did with them! First, I knew that one of my customers had done some work with the NSX API, so I asked him for some advice.  He pointed me at one of Mark Wahl's articles  and gave me an excellent framework to build on. I used that NSX API framework to send the GET command that we'd collected,...

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...

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: Source Destination Action Applied To Any InfraServices Allow DFW Client Devices Web Allow Web DB, App Web Deny Web Web App Allow App DB App Deny App App DB Allow DB Web DB Deny DB SolutionA SolutionA Allow SolutionA SolutionB SolutionB Allow SolutionB SolutionA Any Deny SolutionA SolutionB Any Deny SolutionB These rules will allow default 3 Tier Application communications (Web can talk to App, App can talk to DB) while blocking nonstandard communication within the solution and blocking all...