Distributed Firewall is a feature-rich firewall. But we have to be extremely careful while installing and creating rules. Gone are the days when gigantic physical firewalls were used for traffic filtering and other security measures. Applications demanded firewalls to be a little closer to them rather than running at Top of Rack (TOR). All we needed was a stateful firewall that is more application-aware. When we are inspecting the traffic at near line rate processing that too for East-West traffic which will give us better visibility over the traffic and reduces any attacking loopholes in virtualized data centers, we can call NSX DFW firewall the foundation pillar of Micro Segmentation. Worried about bottlenecks? No problem! DFW is the new kid in town. Let's have a quick look at a few key takeaways from this chapter.
DFW doesn't demand any physical network topology changes.
Make a note of all management virtual machines (VMware appliances, third-party appliances, AD, DNS and exchange, and so on) that are installed in the vSphere environment and make a decision about which should be part of DFW protection.
VSphere switch is not supported for policy enforcement; only logical switches and distributed switch port groups are supported. DFW is fully supported with IPv4 and IPv6.
Starting from NSX 6.2, DFW rules leveraging vCenter Server objects even without VMware tools are supported. NSX 6.1 and above has a new option called reject in firewall actions. This action is available in NSX Edge as well.
NSX 6.2.3 supports Trivial File Transfer Protocol (TFTP)-ALG Distributed Firewall rules.
An identity-based firewall is supported only for Windows Clients, ideal for East-West data center traffic. However, we can configure it with NSX Edge firewall and a physical firewall, which will bring end-to-end security in the overall data center.
Removing and adding vSphere virtual machines from vCenter won't delete any DFW rules. Make use of the exclusion list feature if you want to exclude a VM completely from DFW protection. I will be discussing exclusion lists in more detail in Chapter 8, NSX Troubleshooting.
If we are leveraging Identity firewall feature and for some reason there is a synchronization issue between NSX Manager and Active Directory, it will have a direct impact on DFW rules. So this is one scenario wherein Management plane (NSX Manager) outage causing a dataplane traffic issue because firewall is impacted.
If we need to identity applications and allow/block the traffic irrespective of the port and protocols information, best firewall for such use case will be to integrate New generation firewalls like palo alto along with DFW.
It is not mandatory to install the DFW feature in the vSphere management cluster; if we want to install DFW, watch out for the VCenter Server machine. Ensure that the machine is excluded from the list. If there is an other third-party management software running in the same cluster, DFW doesn't have the intelligence to exclude it from protection. I have seen this mistake back in the VCNS days: all of a sudden, VC loses access to all management components. A simple click on the Install button will cause a major production outage.