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

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

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