Lab: Create DFW Security Policy with Tags

VCF 9.0Intermediatevcp-foundation⏱ 120 min

NSX 9.0.x (feature set inherited from the NSX 4.2 line; NSX 4.2 docs remain a valid technical reference) Distributed Firewall — tag-based micro-segmentation, rule categories, Applied-To optimization

Objectives

Create NSX tags and security groups for dynamic workload classification
Build a DFW security policy with tiered rules using correct rule categories
Understand rule processing order: Emergency → Infrastructure → Environment → Application → Default
Apply and publish DFW policy, then validate enforcement at the kernel level
Use Applied-To scope to optimize rule distribution across hosts
Monitor rule hit counts and flow logs for troubleshooting

Prerequisites

VCF 9.0 with NSX Manager, overlay segments created with VMs deployed (Labs net-virt-01 and net-virt-02 completed), minimum 3 test VMs representing web, app, and db tiers

Prior labs: net-virt-01, net-virt-02

Required skills:

Firewall rule concepts (source/destination/service/action)
NSX tag taxonomy
Basic micro-segmentation principles

Lab Environment

3 test VMs on overlay segments: test-web-01 (seg-web, 10.10.1.11), test-app-01 (seg-app, 10.10.2.11), test-db-01 (seg-db, 10.10.3.11). NSX DFW enabled on all transport nodes.

Tasks

Task 1 Tag-Based Micro-Segmentation with DFW

Production DFW designs should use a tag taxonomy with consistent scope/tag naming (e.g., scope='tier', tag='web'). Never use IP-based rules for dynamic workloads — IPs change; tags follow the VM. Use Applied-To to limit rule scope: a rule with Applied-To='Web-Tier' only pushes to hosts running web VMs, reducing the rule table size on other hosts by up to 90% in large environments.

Implement a production-grade micro-segmentation policy using NSX tags for dynamic workload grouping, demonstrating the correct approach to zero-trust east-west security. Validate enforcement at both the NSX Manager level and the ESXi kernel level (VSIP filter).

Step 1

Create tag taxonomy. NSX Manager → Inventory → Tags → Add Tag. Create tags with consistent scope naming: scope='tier', tag='web' | scope='tier', tag='app' | scope='tier', tag='db' | scope='env', tag='production'. Also create scope='compliance', tag='pci' for later use. This taxonomy enables multi-dimensional grouping (a VM can be tier=web AND env=production AND compliance=pci).

Step 2

Apply tags to VMs. Inventory → Virtual Machines → select test-web-01 → Tags → Add: scope='tier', tag='web' AND scope='env', tag='production'. Repeat for test-app-01 (tier=app, env=production) and test-db-01 (tier=db, env=production). Tags can also be applied via vSphere Client or API. In production, use vRealize Automation / VCF Automation to auto-tag VMs at deployment time.

Step 3

Create security groups (dynamic membership). Inventory → Groups → Add Group. Create: Name='SG-Web-Tier', Membership Criteria → Add Criteria → 'Virtual Machine Tag Equals tier|web'. Create 'SG-App-Tier' (tag=tier|app), 'SG-DB-Tier' (tag=tier|db), 'SG-Production' (tag=env|production). Verify member count matches expected VMs under each group's Members tab.

Step 4

Create Infrastructure-category policy. Security → Distributed Firewall → Infrastructure Category → Add Policy. Name='Infra-Services'. Add Rule: Name='Allow-DNS', Source=SG-Production, Dest=Any, Service=DNS (UDP 53), Action=Allow. Add Rule: Name='Allow-NTP', Source=SG-Production, Dest=Any, Service=NTP (UDP 123), Action=Allow. Applied-To=SG-Production. These rules ensure all production VMs can reach infrastructure services regardless of application-tier rules.

Step 5

Create Application-category policy. Security → Distributed Firewall → Application Category → Add Policy. Name='3-Tier-App-Policy'. Add rules in order: (1) 'Web-to-App': Source=SG-Web-Tier, Dest=SG-App-Tier, Service=HTTPS(443), Action=Allow; (2) 'App-to-DB': Source=SG-App-Tier, Dest=SG-DB-Tier, Service=MySQL(3306), Action=Allow; (3) 'DB-Backup': Source=SG-DB-Tier, Dest=<backup-IP>, Service=Custom(NFS 2049), Action=Allow. Applied-To=DFW (or narrow to the 3 groups for optimization).

Step 6

Create Default-category deny rule. Security → Distributed Firewall → Default Category. Edit the existing default rule: Action=Drop (not Reject — Drop is silent, Reject sends ICMP/RST which leaks network topology). Enable Logging. This is the zero-trust foundation — anything not explicitly allowed is denied. Note: Default Layer 3 rule applies to all VMs; Default Layer 2 rule should remain Allow (blocking L2 breaks ARP/DHCP).

Step 7

Publish all policies. Click 'Publish' in the DFW UI. This pushes all policies to the Central Control Plane (CCP), which distributes them to all transport nodes. Monitor: System → Fabric → Transport Nodes → select a host → click 'Realized Entities' → filter on 'FirewallRule' to verify rules are realized on each host.

Step 8

Validate at the kernel level. SSH to the ESXi host running test-web-01. Run: nsxcli → get firewall <VM-vNIC-UUID> ruleset rules. This shows the exact rules programmed into the VSIP filter for that vNIC. Verify: Infrastructure rules appear first (DNS, NTP), then Application rules (Web-to-App), then Default Deny. The order matches the category hierarchy. Also run: get firewall <VM-vNIC-UUID> connection-table to see active connections.

Step 9

Test enforcement. From test-web-01: (a) ping test-app-01 on port 443 — should succeed (Web-to-App rule); (b) ping test-db-01 on port 3306 — should FAIL (no direct Web-to-DB rule); (c) nslookup google.com — should succeed (DNS Infra rule). From test-app-01: (d) connect to test-db-01:3306 — should succeed (App-to-DB rule); (e) connect to test-web-01:443 — should FAIL (no App-to-Web rule; zero-trust means no implicit reverse path). Document each test result.

Step 10

Monitor rule hits and logging. Security → Distributed Firewall → Statistics column shows per-rule hit counts. For the Default Deny rule, hits indicate blocked traffic that may need a new explicit allow rule. Enable logging on key rules: edit rule → Enable Logging → Publish. Logs appear in syslog at the host level: /var/log/dfwpktlogs.log. Format: <timestamp> <ruleid> <action> <src> <dst> <proto> <sport> <dport>. In production, forward to a SIEM (Splunk/Aria Operations for Logs).

Step 11

Applied-To optimization demo. Edit the '3-Tier-App-Policy' → change Applied-To from 'DFW' (all hosts) to 'SG-Web-Tier, SG-App-Tier, SG-DB-Tier'. Publish. Now SSH to a host that has NO tagged VMs and run: nsxcli → get firewall rules — the 3-Tier-App-Policy rules should NOT appear on this host. This optimization reduces rule table size dramatically in large environments (1000+ VMs with many policies).

Validation Gate

Check: Full DFW micro-segmentation policy operational with kernel-level verification

Expected: Tags applied to all VMs, security groups dynamically populated, DFW policies published and realized on all hosts, traffic allowed/denied per policy, rule hit counts incrementing, Applied-To optimization verified

Common Errors

Security group shows 0 members after tag assignment

Fix: Tag scope/value is case-sensitive. Verify the tag on the VM exactly matches the group membership criteria. Also check: the VM must be discovered by NSX (Inventory → Virtual Machines should list it). If VM was deployed before NSX, it may need a resync.

Default deny rule blocks all traffic including management

Fix: Ensure management traffic rules (vCenter, ESXi management, NSX Manager) are in the Infrastructure category ABOVE the default deny. VCF pre-creates these exclusions, but manually created DFW policies can override them. Add exclusion list entries for management VMs if needed.

DFW rules not appearing on host after publish

Fix: Check transport node connection state. If 'Degraded', the CCP cannot push rules. Also verify: nsxcli → get firewall status — should show 'enabled'. If DFW is disabled on the host, rules won't realize.

Legitimate traffic blocked by default deny

Fix: Enable logging on the default deny rule and check /var/log/dfwpktlogs.log. The log shows src/dst/port/proto for every dropped packet — use this to identify the missing allow rule. Add the rule in the correct category, then re-test.

Final Validation

Tag-based micro-segmentation policy operational with zero-trust enforcement

✓ Tags applied correctly → All 3 VMs have tier and env tags, visible in Inventory → Virtual Machines

✓ Security groups populated → Each SG shows correct member count matching tagged VMs

✓ DFW rules realized on hosts → nsxcli shows rules in correct category order on all relevant hosts

✓ Allowed traffic flows → Web→App:443 ✓, App→DB:3306 ✓, All→DNS:53 ✓

✓ Denied traffic blocked → Web→DB:3306 ✗, App→Web:443 ✗, Any→Any (default) ✗

✓ Applied-To optimization → Rules absent from hosts with no matching Applied-To group members

Cleanup / Restore

• Revert Default Category rule to Allow (prevents accidental lockout)

• Delete Application-category policy '3-Tier-App-Policy'

• Delete Infrastructure-category policy 'Infra-Services'

• Remove tags from VMs (Inventory → VM → Tags → Remove)

• Delete security groups and tags

• Publish all changes to push cleanup to hosts

Design Reflection (VCDX)

DFW design is a VCDX defense staple. Key design decisions: (1) Tag taxonomy — use scopes consistently (tier, env, compliance, app) to enable multi-dimensional policy. (2) Rule category placement — Infrastructure for shared services, Application for app-specific micro-seg, Environment for broad zone policies. (3) Applied-To optimization — critical for environments with >500 VMs to avoid pushing all rules to all hosts. (4) Default deny position — must be last, must log, must exclude management plane.

Requirements

Zero-trust east-west segmentation for 3-tier application
Dynamic workload grouping that survives IP changes and vMotion
Minimal rule footprint on hosts not running relevant workloads

Constraints

DFW processes rules sequentially — excessive rules increase per-packet latency
Connection table default is 512K entries per host — high-throughput VMs may need tuning
Applied-To optimization requires consistent tagging — untagged VMs fall through to default

Assumptions

All workloads are tagged at deployment time via automation
Management plane VMs are excluded from DFW or have Infrastructure-category allow rules
Logging is forwarded to a central SIEM for operational visibility

Risks

Untagged VM gets default deny — causes outage if tagging automation fails
Overly broad Applied-To (DFW) pushes all rules to all hosts, consuming memory and CPU
Rule sprawl over time degrades performance — implement quarterly rule review process

Self-Assessment Discussion Prompts

How do you prevent a DFW misconfiguration from locking out vCenter or NSX Manager?
What is the performance impact of 10,000 DFW rules on a host with 100 VMs?
How would you implement emergency rule insertion during a security incident?
Compare tag-based grouping vs. IP-based grouping for micro-segmentation — when would you use each?

Extensions

Implement the DFW 1-2-3-4 workflow using VCF Operations for Networks to auto-generate rules from observed traffic

Create a context-aware rule using Identity Firewall (IDFW) — tie DFW rules to Active Directory user identity

Build a time-based rule that allows DB maintenance access only during a specific maintenance window

Configure DFW Flood Protection profiles (SYN flood, ICMP flood) for the web tier

⚠ Known Pitfalls (from Community KB)

Placing application rules in the wrong category — Infrastructure rules always process before Application rules regardless of UI position

Using Reject instead of Drop for default deny — Reject sends ICMP unreachable or TCP RST, revealing network topology to attackers

Forgetting to publish after rule changes — rules stay in 'draft' state and are not pushed to hosts until Publish is clicked

Blocking Layer 2 in the default rule — this breaks ARP, DHCP, and GARP; always keep Default L2 rule as Allow

References

NSX 4.2 Administration Guide — Distributed Firewall: techdocs.broadcom.com
NSX 4.2 Security Design Guide — Micro-Segmentation Best Practices: techdocs.broadcom.com
KB 91447 — DFW Rule Processing Order and Troubleshooting

Mark complete