Karl Erik Filip Modén
Guides 4 min read

NSX for Dummies, Part 4: vDefend and the Security Layer Inside NSX

How vDefend uses NSX groups, distributed firewall policy, and inspection to protect workloads without putting a firewall appliance between every pair of VMs.

NSX gives you the network constructs. vDefend is the security family that uses that NSX foundation to protect the workloads attached to it. The important idea is simple: security policy is attached to the workload context NSX already knows - VM, tag, group, segment, identity, and service - rather than being bolted onto a VLAN boundary.

The integration in one picture

vCenter inventory and VM tags
             |
             v
        NSX groups
             |
             v
    vDefend / NSX policy
             |
             v
DFW enforcement at every protected VM vNIC
             |
             +--> selected allowed flows can be inspected by IDS/IPS

The Distributed Firewall (DFW) is enforced in the ESXi hypervisor close to the VM’s virtual NIC. That is why it can control traffic between two workloads on the same subnet, even when no physical firewall would normally see that traffic.

vDefend uses the same NSX groups and policy model. A group such as grp-prod-web can be defined by tags, VM names, IP criteria, or other NSX-supported membership. When a VM is deployed with the right tag, it becomes subject to policy without someone adding its IP address to a spreadsheet rule.

Start with microsegmentation, not signatures

The most valuable first vDefend outcome is usually not IDS/IPS. It is a small, readable allow-list for application communication:

allow  web tier  -> application tier : TCP 8443
allow  application tier -> database tier : TCP 5432
allow  operations group -> servers : approved administration ports
drop   everything else between those tiers, with logging while you learn

This does two useful things before advanced inspection is even involved:

  1. It reduces lateral movement paths.
  2. It reduces the amount of traffic that needs deeper inspection.

Do not begin with a global drop rule and optimism. Begin in monitor-friendly phases: inventory workloads, define groups, learn expected flows, write narrow allows, enable logging on candidate drops, and promote enforcement in measured slices.

Where IDS and IPS fit

IDS detects suspicious traffic and alerts. IPS adds the ability to prevent matching traffic according to the configured policy and profile. In the distributed model, the inspection point is logically at protected VM vNICs.

The ordering is worth understanding: vDefend distributed IDS/IPS inspects traffic that the distributed firewall allows and that an IDS/IPS policy sends to the inspection engine. In practical terms, this means firewall policy is still your first control. Do not use IDS/IPS as a reason to allow a broad “any-to-any” rule and hope signatures catch the rest.

Traffic matches DFW policy
  |
  +-- dropped -> stopped by firewall
  |
  +-- allowed and selected for IDPS -> inspected against the configured profile
                                  -> alert (IDS) or block/prevent (IPS), as configured

This model scales better when you are selective. Start with high-value targets such as internet-facing application tiers, identity services, and sensitive databases. Decide the direction deliberately - inbound, outbound, or both - and tune profiles around the services the target actually provides.

What else the vDefend family adds

Exact capabilities depend on the vDefend edition, entitlement, and release, but the portfolio can add capabilities beyond basic distributed firewalling, including advanced threat prevention services such as distributed IDS/IPS, malware prevention, and threat intelligence-driven controls. Gateway security controls protect traffic at the north-south boundary, while distributed controls remain close to east-west workload traffic.

The clean division is:

NeedBest starting point
Stop an unnecessary workload-to-workload connectionDistributed Firewall policy
Inspect allowed traffic to a sensitive workloadDistributed IDS/IPS policy and profile
Control traffic leaving or entering the NSX domainGateway security policy
Investigate why a workload is blockedDFW logs, rule hit counts, and flow evidence

A realistic first vDefend rollout

Pick one three-tier application and treat it as a product, not as a pile of rules.

  1. Tag the web, app, database, and administration workloads.
  2. Build NSX groups from those tags.
  3. Write only the application dependencies that the owner can confirm.
  4. Turn on logging for the planned drop rule and compare it with real traffic.
  5. Enforce for this application only.
  6. Add IDS/IPS inspection only to the flows and targets where it delivers a useful signal.
  7. Review alerts, false positives, rule hits, and performance before expanding.

That is how vDefend integrates with NSX in practice: NSX supplies workload context and enforcement points; vDefend turns them into layered security controls. The technology is distributed, but the rollout should be deliberately small.

Official references