Search
  • Mike Ghazaleh

What is NSX Service-Defined Firewall?

If you are managing a virtual environment, you likely have the same challenge many customers have - lots of east/west traffic between hosts, or even within a vSphere host, and no way to firewall that traffic. If that sounds anything like you, keep reading!


What is NSX Service-Defined Firewall?

The easiest way to describe the Service-Defined Firewall, or SDFW, is that it is a licensing method for using only the security pieces inside of NSX-T. Yes, that means that NSX Service-Defined Firewall IS NSX-T - you're just not licensed to use the network virtualization pieces of NSX-T. The installation is nearly identical.


So what exactly is included with the NSX SDFW SKU?


  • Stateful L4-L7 firewall for east/west traffic - implemented at the vNIC of each VM

  • A "gateway firewall" which allows NSX to act as the L3 gateway for non-Virtualized workloads - and the ability to firewall that traffic

  • Distributed IDS/IPS*

  • Malware Prevention, Network Traffic Analysis, Network Detection & Response, and NSX Intelligence - all of these functionalities are under the "Advanced Threat Prevention" package, or ATP*


*NOTE: Distributed IDS/IPS and all of the ATP features require a separate license to function. As of this writing, ATP functionality requires the NSX application platform to be deployed, which requires kubernetes to be pre-installed in your environment.


NSX SDFW Implementation Overview

One of the big reasons a lot of customers choose the SDFW, is because of how easy it is to implement. You can keep your existing perimeter firewalls - infact, you won't even have to change them. You also don't need to re-IP any VMs, or even make any network changes. Jumbo MTU is not required.


So what do you have to do to deploy NSX SDFW?

  • Deploy the NSX-T Manager (3x OVAs)

  • Integrate with your existing vCenters

  • Push the VMware Installation Bundles (VIBs) to your vSphere hosts

  • Begin writing firewall rules* (we'll talk about this later)

It's probably worth mentioning that to simplify deployment, you should already be on the VDS. If you're not, you'll need to migrate to the VDS for all of this to work seamlessly. The reason is that NSX will "piggyback" on your existing VDS port groups, but it won't on standard switch (VSS) port groups.


How do I plan for microsegmentation?

OK, so you want to use SDFW to segment something in your environment - maybe tenants, business units, or even true microsegmentation, where we have an app, database, and web tier. Whatever your goal is - the first thing you should ask yourself is: "How do I see traffic in my vmware environment?"


Fortunately, VMware thought of that, and the answer is vRealize Network Insight, also known as vRNI. I'm including a screenshot below, but in a nutshell, Network Insight is a tool that allows you to discover applications, and their associated dependencies. You can then take this data, and using a script, import it into NSX. This ensures that when you implement your policy, you're not breaking anything.



If you want to learn more about Network Insight, I actually created a full course on it which you can access here.


Want to learn more?

This is the really cool thing - if you already know NSX-T very well, then you pretty much know the SDFW! If, however, you are new to NSX-T, here's some awesome resources that I've curated specifically for you to learn these technologies with.


A few great resources for learning SDFW/NSX-T:
23 views

Recent Posts

See All