Virtually Jason

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

I've been plugging away with vRNI and the NSX Distributed firewall a lot, but that hasn't generally leant itself well to writing blog posts... until recently!  We are working on an auditing process to help us decommission NSX firewall rules in favor of policies.  Typically, when retiring a firewall rule, you would just change its priority so that it's below the newer Allow rules but still above the Deny rules, then wait a while and see if it still gets any hits.  In this situation, we're looking to retire some manually created firewall rules in favor of our new set of policy-driven rules, and you can't put manual rules in the middle of your policy rules... so the typical firewall procedure won't work here! So, we've been working on a process to use vRNI to look at all traffic that's hitting a given firewall rule, then check on the policy-based rules and ensure that it will all be allowed by those rules.  The process itself is pretty simple, and looks ...

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

I've been working with a large customer for a while, and one of the things that we've done here is to thoroughly integrate vRealize Network Insight into their environment.  I'm not sure that I can go back to using just plain vCenter after this, because vRNI gives me such a cool perspective on the environment!  As I've worked on various situations, I've found myself using a few queries over and over again, so I figured that I'd share some of my favorites! Queries for Troubleshooting Network Communications Between VMs Flows where VM = <VM Name> Flows where Firewall Action = Deny Flows where Security Tag = <Security Tag Name> VM <VM Name> to VM <Other VM Name> These queries (and permutations thereof) are incredibly useful when troubleshooting communication issues between VMs.  Depending on how precisely the application owner can describe their issue, I might use any one (or combination) of these. For example, if an applicatio...

I've been working with one of my customers to implement the NSX Distribtued Firewall via Security Policies instead of hand-crafted rules.  For auditing and reporting purposes, we needed to be able to display all of the policies that have been created and the DFW rules within each one.  Ideally, we'd need to be able to generate this report on demand, with real-time data... and since the NSX GUI doesn't make that easily visible, I figured that I should put together a script to do it for me! Enter the summarize-NSXSecurityPolicy.ps1 script.  This script uses PowerNSX to get all of the defined Security Policies in the environment, then builds a table with one row per DFW Rule.  Each row contains several columns, including one for the policy that defines the rule, so we can easily filter the table to show what's going on with specific policies or we can easily search it to find a policy that involves specific traffic.  That later use case is almost certainly more im...