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 help

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 VMs into that folder

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 Addresses (like 192.168.

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 important,

I often find myself working with large collections of objects, and one challenge that frequently comes up is to distill that collection to a set of unique items.  For example, I'm working on a project that involves analyzing a lot of network flow data that I receive with parameters for Source, Destination, Protocol, and Port.  For a part of this project, I need to create a bunch of computer objects, with parameters for InboundTCPPorts, InboundUDPPorts, InboundOtherPorts, OutboundTCPPorts, OutboundUDPPorts, and OutboundOtherPorts.  To make these computer objects, I need to start by getting all of the unique computers from my input data's Source and Destination fields.  That's pretty simple.  I start by combining the source and destination fields into a single array: $computers = $data.source + $data.destination That gives me a single list of all computers that are involved in these network flows, but that list is going to have a ton of duplication in it (since each com

Due to some strict security requirements, I often find myself working inside of an RDP session that's nested inside of another RDP session (that is occasionally nested inside of a Virtual Desktop).  Generally speaking, this works really well... except for when I need to change my password.  When you're buried that deeply in nested RDP sessions, neither ctrl-alt-del nor ctrl-alt-end are going to do the trick for you.  Fortunately, Serge Pavlov, deep in the comments of a technet article , had the solution!  I'm mostly writing about it here to make it easier for me to find it again when I need to go through this process 30 days from now ;) In a PowerShell window, run this command: (New-Object -COM Shell.Application).WindowsSecurity() That'll open the Windows Security Center (the same thing that pops up when you hit ctrl-alt-del normally).  From there, you can just click "change password" and be on your merry way!  I like this because, since it's ini

Hey everyone - I've been helping a customer implement their NSX Distributed Firewall recently.  I'm not a big fan of the GUI, but I can do just about everything that I need to do through PowerNSX, which I've found much faster and easier to manage... until I started working with Security Group membership exclusions. NSX follows a fairly sophisticated process for determining what objects are members of a given Security Group.  First, it checks the rules in that Security Group's Dynamic Membership section and adds all of the specified objects to the list (this can be a computationally expensive process, so you probably don't want to use a lot of dynamic membership rules).  Next, it checks the list in that Security Group's Static Include section and adds all of the specified objects to the list (this is a cheaper operation and should be the go-to group membership method).  Finally, it checks the list in the Exclude section and removes those objects from the list. 

One of my customers wants to use VRNI to better understand their environment.  They've been fairly disciplined about putting VMs into folders based on the application that the VM serves.  Unfortunately, they've been a little too good about putting the VMs in folders, as each application is broken up into several subfolders.  This causes a bit of a problem when we want to use VRNI to analyze an application's traffic, as the query flows where folder like *application*  certainly works based on the VM folder... but it only looks at the immediate folder for the VM, rather than the whole path.  Since we had everything broken up into subfolders, that query doesn't do us much good here. So, I put together a quick script that can scrape a vCenter inventory to register VRNI applications for each folder that it finds.  Those applications are named based on the absolute path of the VM folder, so that you can run queries like flows where application like *application*  to find al