Virtually Jason

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

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

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