VMware NSX Security

VMware NSX DFW microsegmentation and security — 20 MCP tools for distributed firewall, security groups, VM tags, Traceflow, and IDPS.

Domain-focused security skill for NSX-T / NSX 4.x Policy API.
Companion skills: vmware-nsx (networking), vmware-aiops (VM lifecycle), vmware-monitor (read-only monitoring), vmware-avi (AVI/ALB/AKO).
| vmware-pilot (workflow orchestration) | vmware-policy (audit/policy)

What This Skill Does

Category	Tools	Count
DFW Policy	list, get, create, update, delete, list rules	6
DFW Rules

create, update, delete, get stats | 4 | | Security Groups | list, get, create, delete | 4 | | VM Tags | list VM tags, apply tag | 2 | | Traceflow | run trace, get result | 2 | | IDPS | list profiles, get status | 2 |

Total: 20 tools (10 read-only + 10 write)

Quick Install

CODEBLOCK0

When to Use This Skill

• - List, create, or modify DFW security policies and rules
• Create security groups based on VM tags, IP ranges, or segment membership
• Apply or list NSX tags on virtual machines
• Run Traceflow to trace a packet path and diagnose drop reasons
• Check IDPS profile configuration and engine status
• Implement zero-trust microsegmentation between application tiers

Use companion skills for:

• - NSX segments, gateways, NAT, routing, IPAM → INLINECODE0
• VM lifecycle, deployment, guest ops → INLINECODE1
• vSphere inventory, health, alarms, events → INLINECODE2
• Storage: iSCSI, vSAN, datastores → INLINECODE3
• Tanzu Kubernetes → INLINECODE4
• Load balancing, AVI/ALB, AKO, Ingress → INLINECODE5

Related Skills — Skill Routing

User Intent	Recommended Skill
NSX security: DFW rules, security groups, IDS/IPS	vmware-nsx-security ← this skill
NSX networking: segments, gateways, NAT, routing

vmware-nsx | | Read-only vSphere monitoring, alarms, events | vmware-monitor | | VM lifecycle, deployment, guest ops | vmware-aiops | | Storage: iSCSI, vSAN, datastores | vmware-storage | | Tanzu Kubernetes | vmware-vks | | Multi-step workflows with approval | vmware-pilot | | Load balancer, AVI, ALB, AKO, Ingress | vmware-avi (uv tool install vmware-avi) | | Audit log query | vmware-policy (vmware-audit CLI) |

Common Workflows

Implement App-Tier Microsegmentation

1. 1. Create a security group for web VMs based on NSX tag:

   vmware-nsx-security group create web-vms --name "Web Tier VMs" --tag-scope tier --tag-value web
   

1. 2. Create a security group for app VMs:

   vmware-nsx-security group create app-vms --name "App Tier VMs" --tag-scope tier --tag-value app
   

1. 3. Create a DFW policy:

   vmware-nsx-security policy create app-microseg --name "App Microsegmentation" --category Application
   

1. 4. List rules to verify (empty initially):

CODEBLOCK4

Apply NSX Tags to VMs

1. 1. Find VM and its tags:

   vmware-nsx-security tag list my-web-vm-01
   

1. 2. Get the VM external ID from the output, then apply tag:

CODEBLOCK6

Trace a Packet with Traceflow

1. 1. Get source VM's logical port ID (from vmware-nsx troubleshoot vm-segment):

   vmware-nsx-security traceflow run <lport-id> --src-ip &lt;src-ip&gt; --dst-ip &lt;dst-ip&gt; --proto TCP --dst-port 443
   

1. 2. Check for DFW hits and drop reasons in the output.

Check DFW Policy Hit Counts

CODEBLOCK8

Multi-Target Operations

All commands accept --target <name> to operate against a specific NSX Manager:

CODEBLOCK9

Usage Mode

Scenario	Recommended	Why
Local/small models (Ollama, Qwen)	CLI	~2K tokens vs ~8K for MCP
Cloud models (Claude, GPT-4o)

Either | MCP gives structured JSON I/O | | Automated pipelines | MCP | Type-safe parameters, structured output |

MCP Tools (20 — 10 read, 10 write)

All MCP tools accept an optional target parameter.

Category	Tool	Type	Description
DFW Policy	INLINECODE11	Read	List all DFW security policies with category, sequence, and rule count

get_dfw_policy | Read | Get policy details: category, stateful, locked, scope, tags |
| | create_dfw_policy | Write | Create a new DFW policy with category and sequence number |
| | update_dfw_policy | Write | Partial update: displayname, description, sequencenumber, stateful |
| | delete_dfw_policy | Write | Delete policy — refuses if active rules exist |
| | list_dfw_rules | Read | List rules in a policy: action, sources, destinations, services |
| DFW Rules | create_dfw_rule | Write | Create rule with sources/destinations/services/action/scope |
| | update_dfw_rule | Write | Partial update rule fields |
| | delete_dfw_rule | Write | Delete a rule from a policy |
| | get_dfw_rule_stats | Read | Get packet/byte hit counts for a rule |
| Security Groups | list_groups | Read | List all security groups with expression count |
| | get_group | Read | Get group details: expression criteria + up to 50 effective VM members |
| | create_group | Write | Create group with tag/IP/segment membership criteria |
| | delete_group | Write | Delete group — refuses if referenced by DFW rules |
| VM Tags | list_vm_tags | Read | List NSX tags on a VM by display name |
| | apply_vm_tag | Write | Apply a scope/value tag to a VM (additive, preserves existing tags) |
| Traceflow | run_traceflow | Write | Inject probe packet and return hop-by-hop observations |
| | get_traceflow_result | Read | Check status/observations of an existing traceflow |
| IDPS | list_idps_profiles | Read | List IDPS profiles with severity and criteria |
| | get_idps_status | Read | Get IDPS engine status: enabled/disabled, signature version, per-node counts |

CLI Quick Reference

CODEBLOCK10

Troubleshooting

"Cannot delete policy — active rules exist"

INLINECODE31 checks for active rules before deleting. Use vmware-nsx-security rule list <policy-id> to see which rules need to be removed first. Then delete each rule individually before retrying the policy deletion.

"Cannot delete group — referenced by DFW rules"

INLINECODE33 scans all policies for rules that reference the group in sourcegroups or destinationgroups. Remove the group from those rules first (via update_dfw_rule replacing the group path with 'ANY' or another group), then retry.

"No virtual machine found with display_name"

INLINECODE35 looks up VMs by display name via the NSX fabric API. Common causes:

1. 1. Display name mismatch — the name in NSX Manager may differ from vCenter. Check vmware-monitor vm list for the exact NSX fabric display name.
2. VM not registered — newly deployed VMs may take a minute to appear in the NSX fabric.
3. Multiple VMs with the same name — use apply_vm_tag with the specific external_id.

Traceflow returns empty observations

1. 1. Verify the src_lport_id is the correct logical port attachment UUID — not the segment port path. Get it from vmware-nsx troubleshoot vm-segment <vm>.
2. The source VM must be powered on and connected to an NSX overlay segment.
3. If the VM is on a VLAN-backed segment, Traceflow is not supported.
4. NSX Manager requires the transport node hosting the source VM to be reachable. Check vmware-nsx health transport-nodes.

DFW rule stats show zero hits

A newly created rule will have zero hit counts until traffic matches it. If expected traffic still shows zero:

1. 1. Confirm the rule is not disabled (disabled: false in list_dfw_rules output).
2. Check that source/destination group membership is correct using get_group.
3. Verify rule sequence number — a lower-sequence rule with ALLOW/DROP may be matching first.

"Password not found" error

Password variable convention: VMWARE_NSX_SECURITY_<TARGET_UPPER>_PASSWORD
where hyphens are replaced by underscores. For target nsx-prod:
VMWARE_NSX_SECURITY_NSX_PROD_PASSWORD. Check ~/.vmware-nsx-security/.env.

Safety

• - Audit logging: All write operations logged to ~/.vmware/audit.db (SQLite WAL, via vmware-policy) with timestamp, user, target, operation, parameters, and result
• Dependency checks: delete_dfw_policy checks for active rules; delete_group checks for DFW rule references — prevents accidental cascade failures
• Input validation: All IDs validated against safe character set (alphanumerics, hyphens, underscores, dots); all text fields sanitized to strip control characters
• Dry-run mode: CLI write commands support --dry-run to preview API calls without executing
• Double confirmation: CLI destructive operations (delete) require two separate confirmation prompts
• Credential safety: Passwords loaded only from environment variables (.env file), never from INLINECODE53
• No networking changes: Cannot modify segments, gateways, NAT, or routing — that scope belongs to INLINECODE54
• Prompt injection defense: All API-sourced strings passed through _sanitize() before inclusion in tool output

Setup

CODEBLOCK11

All tools are automatically audited via vmware-policy. Audit logs: INLINECODE56

Full setup guide: see INLINECODE57

Architecture

CODEBLOCK12

The MCP server uses stdio transport (local only, no network listener). All connections to NSX Manager use HTTPS on port 443.

Audit & Safety

All operations are automatically audited via vmware-policy (@vmware_tool decorator):

• - Every tool call logged to ~/.vmware/audit.db (SQLite, framework-agnostic)
• Policy rules enforced via ~/.vmware/rules.yaml (deny rules, maintenance windows, risk levels)
• Risk classification: each tool tagged as low/medium/high/critical
• View recent operations: INLINECODE61
• View denied operations: INLINECODE62

vmware-policy is automatically installed as a dependency — no manual setup needed.

License

MIT — github.com/zw008/VMware-NSX-Security