VMware NSX-T KB — Phase 9: Advanced Security

NSX Distributed IDS/IPS — Signature Updates & False Positives

IDS/IPS not detecting threats, excessive false positives, or signature update failures blocking legitimate traffic

CriticalIDS/IPSSignaturesSecurity

⚠Impact: NSX Distributed IDS/IPS runs in-kernel on every hypervisor, inspecting east-west traffic. Misconfigured signatures or failed updates leave the environment blind to lateral movement attacks or block production traffic.

Symptoms

IDS events tab shows no alerts despite known malicious traffic
Signature auto-update shows "Failed" status in NSX Manager
False positive alerts flooding — legitimate application traffic flagged
IPS in "Detect & Prevent" mode dropping valid connections

Root Cause Analysis

Common Causes

NSX Manager cannot reach cloud signature service (internet access)
IDS profile not applied to correct groups/segments
Signature set too broad — detecting non-applicable protocols
IPS action set to DROP without proper tuning period

Resolution Approach

Verify outbound HTTPS from manager to NSX Threat Intelligence Cloud
Start with DETECT mode, tune for 2-4 weeks before enabling PREVENT
Create custom IDS profiles targeting specific application tiers
Use exclusion lists for known-good traffic patterns

Resolution Steps

Check IDS signature update status and connectivity

# Check IDS service status on NSX Manager:
GET https://<nsx-manager>/policy/api/v1/infra/settings/firewall/security/intrusion-services

# Check signature version and last update:
GET https://<nsx-manager>/policy/api/v1/infra/settings/firewall/security/intrusion-services/signatures

# Verify internet connectivity from manager for signature downloads:
# NSX Manager must reach: nsx.licensing.broadcom.com (port 443)
# Proxy configuration in /etc/environment if behind proxy

# Force manual signature update:
POST https://<nsx-manager>/policy/api/v1/infra/settings/firewall/security/intrusion-services/signatures?action=update_signatures

Configure IDS profiles with targeted scope

# Best practice: Create application-specific IDS profiles
# Example: Web-tier profile (only HTTP/TLS signatures)
{
  "display_name": "Web-Tier-IDS-Profile",
  "ids_signatures": {
    "severity": ["CRITICAL", "HIGH"],
    "product_affected": ["Web_Server", "Web_Application"],
    "attack_types": ["SQL_Injection", "XSS", "Remote_Code_Execution"]
  },
  "overridden_signatures": [
    {
      "signature_id": "2024897",
      "action": "ALERT"  // Override specific noisy sig to alert-only
    }
  ]
}

# Apply to web-tier group only:
PUT https://<nsx-manager>/policy/api/v1/infra/domains/default/intrusion-service-policies/web-tier-policy/rules/rule-1
{
  "action": "DETECT",
  "ids_profiles": ["/infra/settings/firewall/security/intrusion-services/profiles/Web-Tier-IDS-Profile"],
  "source_groups": ["ANY"],
  "destination_groups": ["/infra/domains/default/groups/web-servers"],
  "scope": ["/infra/domains/default/groups/web-servers"]
}

Tune false positives and transition to prevent mode

# 1. Export current IDS events for analysis:
GET https://<nsx-manager>/policy/api/v1/infra/settings/firewall/security/intrusion-services/affected-vms

# 2. Review top triggered signatures:
GET https://<nsx-manager>/policy/api/v1/infra/settings/firewall/security/intrusion-services/stats

# 3. For confirmed false positives — add to exclusion:
# Option A: Suppress specific signature for specific VMs
# Option B: Change signature action to ALERT (not DROP)
# Option C: Add source IP to IDS exclusion list

# 4. After tuning (2-4 weeks with zero false positives):
# Change rule action from DETECT to DETECT_PREVENT
PUT .../rules/rule-1
{
  "action": "DETECT_PREVENT"
}

# Monitor for 48 hours after enabling prevent mode

NSX Distributed Malware Prevention — Cloud Connector & File Inspection

Malware Prevention service not scanning files, cloud analysis failing, or excessive latency on file transfers

CriticalMalware PreventionATPCloud Connector

⚠Impact: NSX Distributed Malware Prevention inspects files in east-west traffic via the NSX Application Platform. When the cloud connector fails, zero-day malware traverses the network undetected or file transfers stall waiting for verdicts.

Symptoms

Malware Prevention dashboard shows "Service Degraded" or no file events
Cloud analysis connector status: DISCONNECTED
File transfers between VMs experiencing 5-30 second delays
NSX Application Platform pods in CrashLoopBackOff

Root Cause Analysis

Common Causes

NSX Application Platform (NAPP) not deployed or unhealthy
Cloud connector cannot reach Lastline/VMware cloud sandbox
File size exceeds inspection threshold (default 64MB)
Insufficient resources on K8s cluster running NAPP

Prerequisites

NSX 3.2+ with NSX Application Platform deployed
Internet access to cloud analysis service (port 443)
Minimum 4-node K8s cluster for NAPP (16 vCPU, 64GB RAM per node)
Malware Prevention license (NSX Firewall with ATP add-on)

Resolution Steps

Verify NSX Application Platform health

# Check NAPP deployment status:
GET https://<nsx-manager>/napp/api/v1/platform/monitor/category/health

# Check individual pods (SSH to NAPP K8s cluster):
kubectl get pods -n nsxi-platform
kubectl get pods -n vmware-system-nsx

# Look for pods not in Running state:
kubectl describe pod <unhealthy-pod> -n nsxi-platform
# Common: ImagePullBackOff (registry access), OOMKilled (resource limits)

# Verify cloud connector specifically:
kubectl logs -n nsxi-platform -l app=cloud-connector --tail=100
# Look for: "connection refused", "TLS handshake failed", "timeout"

Configure malware prevention policy

# Create malware prevention profile:
PUT https://<nsx-manager>/policy/api/v1/infra/malware-prevention-profiles/prod-mp-profile
{
  "display_name": "Production-Malware-Prevention",
  "file_types_to_analyze": ["PE", "PDF", "OFFICE", "SCRIPT", "ARCHIVE"],
  "cloud_file_analysis": true,
  "local_file_analysis": true,
  "file_size_limit_mb": 64
}

# Apply to security policy:
# scope to workload groups — do NOT apply to infrastructure VMs
PUT .../security-policies/mp-policy/rules/rule-1
{
  "action": "DETECT",
  "direction": "IN_OUT",
  "source_groups": ["ANY"],
  "destination_groups": ["/infra/domains/default/groups/production-workloads"],
  "scope": ["/infra/domains/default/groups/production-workloads"],
  "profiles": ["/infra/malware-prevention-profiles/prod-mp-profile"]
}

# Monitor file analysis results:
GET https://<nsx-manager>/policy/api/v1/infra/sha-256-indicators
# Returns list of known malicious file hashes detected

URL Analysis & FQDN Filtering — L7 Context-Aware Rules

Configure FQDN-based DFW rules, URL category filtering, and TLS inspection for east-west web traffic control

HighURL FilteringFQDNL7TLS Inspection

🛈Context: NSX URL Analysis provides category-based URL filtering and FQDN allowlisting in DFW rules. This enables policy decisions based on domain names rather than IP addresses — critical for cloud-native workloads accessing SaaS services.

Use Cases

FQDN allowlist: Allow workloads to reach only approved external services (e.g., *.azure.com, api.github.com)
Category blocking: Block access to malware, phishing, gambling, or social media categories
TLS inspection: Decrypt and inspect encrypted east-west traffic for threats
Compliance: Enforce data exfiltration prevention by blocking unauthorized cloud storage domains

Configuration

Configure FQDN-based DFW rules

# Step 1: Enable DNS Snooping on the relevant segments
# NSX uses DNS snooping to map FQDNs to IPs in real-time
# Ensure DNS traffic (port 53) flows through NSX-managed segments

# Step 2: Create FQDN context profile:
PUT https://<nsx-manager>/policy/api/v1/infra/context-profiles/approved-saas
{
  "display_name": "Approved-SaaS-Endpoints",
  "attributes": [
    {
      "key": "DOMAIN_NAME",
      "attribute_type": "FQDN",
      "value": [
        "*.microsoft.com",
        "*.azure.com",
        "login.microsoftonline.com",
        "api.github.com",
        "*.amazonaws.com"
      ]
    }
  ]
}

# Step 3: Create DFW rule using context profile:
PUT .../security-policies/fqdn-policy/rules/allow-saas
{
  "action": "ALLOW",
  "source_groups": ["/infra/domains/default/groups/app-tier"],
  "destination_groups": ["ANY"],
  "profiles": ["/infra/context-profiles/approved-saas"],
  "services": ["/infra/services/HTTPS"],
  "logged": true
}

# Step 4: Default deny for non-approved FQDNs:
PUT .../security-policies/fqdn-policy/rules/deny-other
{
  "action": "DROP",
  "source_groups": ["/infra/domains/default/groups/app-tier"],
  "destination_groups": ["ANY"],
  "services": ["/infra/services/HTTPS"],
  "logged": true
}

URL category filtering

# Enable URL Analysis (requires NSX Application Platform):
# Categories available: Malware, Phishing, Botnet, Gambling,
# Social Media, Streaming, Cloud Storage, Uncategorized, etc.

# Create URL category context profile:
PUT https://<nsx-manager>/policy/api/v1/infra/context-profiles/block-risky-categories
{
  "display_name": "Block-Risky-URL-Categories",
  "attributes": [
    {
      "key": "URL_CATEGORY",
      "attribute_type": "URL_CATEGORY",
      "value": [
        "MALWARE",
        "PHISHING",
        "BOTNET_COMMAND_AND_CONTROL",
        "SPAM",
        "UNAUTHORIZED_CLOUD_STORAGE"
      ]
    }
  ]
}

# Apply in DFW rule — blocks access to risky URL categories:
PUT .../rules/block-risky-urls
{
  "action": "REJECT",
  "source_groups": ["/infra/domains/default/groups/all-workloads"],
  "destination_groups": ["ANY"],
  "profiles": ["/infra/context-profiles/block-risky-categories"],
  "logged": true
}

# Key limitation: URL categorization requires the first DNS
# query to be visible to NSX. Encrypted DNS (DoH) bypasses this.

Service Insertion & Guest Introspection — Partner SVM Integration

Third-party security SVMs not receiving traffic, Guest Introspection agent communication failure, or service chain broken

CriticalService InsertionGuest IntrospectionPartner SVM

⚠Impact: Service Insertion redirects east-west traffic to third-party security appliances (e.g., Palo Alto, Check Point, Trend Micro SVMs) for deep inspection. When the service chain breaks, traffic is either blackholed or bypasses inspection entirely.

Symptoms

Partner SVM shows "DOWN" in Service Deployments
Guest Introspection (GI) agent not communicating — thin agent on VM shows disconnected
Traffic not being redirected to service chain — bypassing inspection
Service VM health check failing repeatedly
VMs protected by GI losing anti-malware real-time protection

Resolution Steps

Verify Service Deployment and SVM health

# Check Service Deployment status:
GET https://<nsx-manager>/policy/api/v1/infra/service-references
GET https://<nsx-manager>/api/v1/serviceinsertion/services

# Check individual SVM instance health:
GET https://<nsx-manager>/api/v1/serviceinsertion/services/<service-id>/service-instances

# On ESXi host — verify Guest Introspection components:
/etc/init.d/vShield-Endpoint-Mux status
# Should return: "running"

# Check MUX connectivity to NSX Manager:
esxcli network ip connection list | grep 1235
# Should see ESTABLISHED connections to all 3 manager IPs

# Verify GI thin agent inside the guest VM (Windows):
sc query vsepflt    # vShield Endpoint filter driver
sc query MfEEPTSvc  # Example: Trend Micro, McAfee, etc.
# Both should show "RUNNING"

# Linux VMs:
systemctl status vmware-tools-vgauth
ls /var/run/vmware/guestIntro*

Fix broken service chain

# If SVM is DOWN — redeploy:
# 1. In NSX Manager UI: System > Service Deployments
# 2. Select failed deployment > Actions > Retry/Redeploy

# If GI MUX is down on host:
/etc/init.d/vShield-Endpoint-Mux restart

# Verify service chain redirect rules on host:
nsxcli -c "get service-insertion rules"
# Should show redirect rules for the configured service chain

# If traffic bypassing — check service chain failover action:
GET .../service-chains/<chain-id>
# "failure_policy": "ALLOW" = bypass on SVM failure (unsafe)
# "failure_policy": "BLOCK" = drop traffic on SVM failure (safer)

# Recommended for production: BLOCK with HA SVM pair
# to prevent unprotected traffic during SVM maintenance

NSX Network Detection & Response (NDR) — Threat Campaign Correlation

Configure NDR for multi-signal threat detection, campaign correlation, and automated response across IDS/IPS, malware, and anomaly signals

HighNDRThreat IntelligenceCampaign Detection

🛈Context: NSX NDR correlates signals from IDS/IPS, Malware Prevention, and network anomaly detection into unified threat campaigns. It provides kill-chain visualization and automated containment recommendations.

Architecture

Signal Sources: Distributed IDS/IPS, Malware Prevention, Network Traffic Analysis (NTA)
Correlation Engine: Runs on NSX Application Platform (NAPP)
Output: Campaigns with MITRE ATT&CK mapping, confidence scores, affected VMs
Response: Manual quarantine or integration with vSphere/DFW for automated isolation

Configuration

Enable NDR and configure signal sources

# Prerequisites:
# 1. NSX Application Platform (NAPP) deployed and healthy
# 2. NSX IDS/IPS enabled (KB #81)
# 3. NSX Malware Prevention enabled (KB #82)
# 4. NSX Intelligence data collection active

# Enable NDR via API:
PUT https://<nsx-manager>/policy/api/v1/infra/settings/firewall/security/intrusion-services/ids-settings
{
  "ids_enabled": true,
  "ndr_enabled": true,
  "auto_update": true
}

# Verify NDR correlation engine status:
GET https://<nsx-manager>/napp/api/v1/platform/monitor/feature/ndr
# Expected: "status": "ACTIVE"

# View detected campaigns:
GET https://<nsx-manager>/policy/api/v1/infra/settings/firewall/security/intrusion-services/campaigns
# Returns: campaign list with severity, affected VMs, kill-chain stage

# Each campaign includes:
# - Intrusion events (IDS alerts)
# - Malware file detections
# - Anomalous lateral movement patterns
# - MITRE ATT&CK technique mapping
# - Confidence score (0-100)

Automated quarantine response

# When NDR detects a high-confidence campaign:
# Option 1: Manual quarantine via DFW tag
# Apply "QUARANTINE" tag to affected VM:
PUT https://<nsx-manager>/policy/api/v1/infra/tags
{
  "tags": [{"tag": "QUARANTINE", "scope": "security-action"}]
}
# Pre-configured DFW rule blocks all traffic for QUARANTINE-tagged VMs

# Option 2: Automated response (NSX 4.1+)
# Configure auto-quarantine policy for high-severity campaigns:
PUT .../intrusion-services/ids-settings/auto-response
{
  "enabled": true,
  "min_campaign_severity": "HIGH",
  "action": "QUARANTINE",
  "quarantine_group": "/infra/domains/default/groups/quarantined-vms",
  "notification_email": "soc@company.com"
}

# DFW quarantine rule (should already exist):
# Source: quarantined-vms | Dest: ANY | Action: DROP
# Source: ANY | Dest: quarantined-vms | Action: DROP
# Exception: Allow SOC forensic subnet for investigation

TLS Inspection — East-West Encrypted Traffic Decryption

TLS decryption breaking applications, certificate trust failures, or incomplete traffic visibility for encrypted east-west flows

HighTLS InspectionDecryptionCertificate

⚠Caution: TLS Inspection decrypts encrypted east-west traffic for IDS/IPS and malware inspection. Improper configuration causes application failures, certificate validation errors, and potential compliance issues with certificate pinning.

Symptoms

Applications failing with TLS handshake errors after enabling inspection
Certificate pinned applications (mutual TLS) completely broken
IDS/IPS still not seeing content of encrypted sessions
Performance degradation due to decryption overhead

Resolution Steps

Configure TLS Inspection with proper CA and bypass rules

# Step 1: Generate internal CA for TLS inspection
# NSX will re-sign decrypted traffic with this CA
# Import the CA into all workload VM trust stores

# Upload CA certificate to NSX:
POST https://<nsx-manager>/policy/api/v1/infra/tls-inspection-ca-certificates
{
  "display_name": "NSX-TLS-Inspection-CA",
  "pem_encoded": "<base64-CA-cert>",
  "private_key": "<base64-private-key>"
}

# Step 2: Create TLS inspection profile:
PUT https://<nsx-manager>/policy/api/v1/infra/tls-inspection-profiles/east-west-inspect
{
  "display_name": "East-West-TLS-Inspection",
  "ca_certificate": "/infra/tls-inspection-ca-certificates/NSX-TLS-Inspection-CA",
  "tls_protocols": ["TLS_V1_2", "TLS_V1_3"],
  "failure_action": "BYPASS",  // Don't break traffic if decryption fails
  "crl_check": false           // Disable CRL for internal traffic
}

# Step 3: CRITICAL — Create bypass rules FIRST:
# Bypass certificate-pinned apps, health checks, infrastructure
PUT .../tls-inspection-policies/bypass-rules/rules/bypass-pinned
{
  "action": "BYPASS",
  "destination_groups": ["/infra/domains/default/groups/cert-pinned-apps"],
  "notes": "mTLS apps, health monitors, infrastructure services"
}

# Step 4: Apply inspection to target segments:
PUT .../tls-inspection-policies/inspect-east-west/rules/inspect-all
{
  "action": "DECRYPT",
  "source_groups": ["/infra/domains/default/groups/standard-workloads"],
  "destination_groups": ["/infra/domains/default/groups/standard-workloads"],
  "tls_inspection_profile": "/infra/tls-inspection-profiles/east-west-inspect"
}

# Applications that MUST be bypassed:
# - Mutual TLS / certificate-pinned services
# - Financial/healthcare data with compliance requirements
# - Infrastructure: vCenter, NSX Manager, AD/LDAP, backup agents

NSX Intelligence — Advanced Flow Analysis & Rule Recommendations

Leverage NSX Intelligence for traffic flow visualization, automated microsegmentation rule recommendations, and compliance posture analysis

HighNSX IntelligenceFlow AnalysisAutomation

🛈Context: NSX Intelligence collects and analyzes all east-west traffic flows, providing visual topology maps, automated DFW rule recommendations, and security posture scoring. This is the foundation for data-driven microsegmentation.

Capabilities

Flow Visualization: See all VM-to-VM communication flows in real-time topology
Rule Recommendations: AI-generated DFW rules based on observed traffic patterns
Suspicious Flow Detection: Identify unusual lateral movement or data exfiltration
Compliance Mapping: PCI-DSS, HIPAA scope identification via traffic analysis

Configuration

Enable and configure NSX Intelligence data collection

# NSX Intelligence runs on NSX Application Platform (NAPP)
# Verify Intelligence feature activation:
GET https://<nsx-manager>/napp/api/v1/platform/monitor/feature/intelligence
# Expected: "status": "ACTIVE"

# Configure flow data collection scope:
PUT https://<nsx-manager>/policy/api/v1/infra/settings/intelligence
{
  "data_collection_enabled": true,
  "flow_data_collection": {
    "enabled": true,
    "scope": "ALL_TRANSPORT_NODES",   // or specific TN groups
    "retention_days": 30              // How long to keep flow data
  }
}

# After 24-48 hours of collection, view flow topology:
# NSX Manager UI > Plan & Troubleshoot > Discover & Take Action

# Generate microsegmentation recommendations:
POST https://<nsx-manager>/policy/api/v1/infra/settings/intelligence/recommendations
{
  "scope_group": "/infra/domains/default/groups/app-tier-vms",
  "recommendation_type": "MICROSEGMENTATION",
  "observation_period_days": 14
}

# Review and apply recommended rules:
GET .../recommendations/<recommendation-id>/rules
# Returns suggested DFW rules based on observed flows
# Review each rule before applying — verify no missed flows

Identify unprotected flows and compliance gaps

# Query for flows NOT covered by any DFW rule:
GET https://<nsx-manager>/policy/api/v1/infra/settings/intelligence/unprotected-flows
{
  "group": "/infra/domains/default/groups/pci-scope",
  "time_range": "LAST_7_DAYS"
}

# Returns: list of VM pairs communicating without DFW enforcement
# Priority: flows crossing security zones (e.g., PCI to non-PCI)

# Suspicious flow detection — anomaly baseline:
GET .../intelligence/suspicious-traffic
# Flags:
# - New flows never seen before (potential lateral movement)
# - Unusual ports (non-standard application behavior)
# - High-volume transfers (potential exfiltration)
# - Connections to known-bad IPs (threat intelligence match)

# Export flow data for SIEM integration:
# Configure syslog export of Intelligence events to Splunk/QRadar
PUT .../intelligence/export-config
{
  "syslog_server": "siem.company.com",
  "port": 6514,
  "protocol": "TLS"
}

NSX Guest Introspection — Agentless Endpoint Protection

Guest Introspection framework failures causing loss of agentless antivirus, file integrity monitoring, or vulnerability scanning on VMs

HighGuest IntrospectionEndpoint ProtectionAgentless

⚠Impact: Guest Introspection (GI) enables agentless security — antivirus, file integrity, and vulnerability scanning run on a dedicated SVM per host rather than agents inside every VM. When GI breaks, all VMs on that host lose protection silently.

Symptoms

GI SVM shows "Not Running" in Service Deployments
VM security status shows "Unprotected" in partner console (Trend Micro, McAfee, etc.)
vShield Endpoint MUX service down on ESXi host
Guest VM thin agent (vsepflt) driver not loaded
High latency on file I/O when GI SVM is overloaded

Resolution Steps

Diagnose Guest Introspection framework health

# On ESXi host — check GI MUX service:
/etc/init.d/vShield-Endpoint-Mux status
# If stopped:
/etc/init.d/vShield-Endpoint-Mux start

# Check MUX logs for errors:
cat /var/log/vShield-Endpoint-Mux.log | tail -50
# Common errors:
# "Failed to connect to Context MUX" — network issue to SVM
# "EPSec registration timeout" — SVM not responding

# Verify GI SVM is powered on and on correct port group:
# In vSphere: Check service VM (e.g., Trend Micro DSVA) is running
# SVM must be on the same host as the VMs it protects

# Check SVM health from NSX Manager:
GET https://<nsx-manager>/api/v1/serviceinsertion/services/<svc-id>/service-instances/<instance-id>/status

# Inside guest VM (Windows) — check thin agent:
fltmc | findstr vsepflt
# Should show: vsepflt - loaded
# If not loaded:
fltmc load vsepflt

# Verify VMware Tools GI component:
# Control Panel > Programs > VMware Tools > Modify
# Ensure "Guest Introspection" component is installed

Recover and validate GI service

# If SVM crashed — redeploy from NSX Manager:
# System > Service Deployments > Select partner service
# Actions > Redeploy on affected host

# Performance tuning for GI SVM:
# - Allocate minimum 4 vCPU, 8GB RAM per SVM
# - Use SSD-backed datastore for scan cache
# - Configure scan exclusions for known-good files:
#   *.vmdk, *.log, database data files, backup files

# Validate protection after recovery:
# 1. Check NSX Manager: Inventory > Groups > Security status
# 2. Check partner console: All VMs showing "Protected"
# 3. Test: Create EICAR test file on a VM
#    Download: https://www.eicar.org/download-anti-malware-testfile/
#    If GI working: file should be quarantined immediately

# High availability design:
# - GI SVM is per-host (auto-deployed via service deployment)
# - If SVM fails, configure "failure_policy": "BLOCK" for security
# - Monitor SVM health with vRealize/Aria Operations alerts
# - DRS anti-affinity: SVM must follow protected VMs

NSX+ (SaaS) — Cloud-Managed NSX Operations

Configure NSX+ cloud service for centralized multi-site management, SaaS-based policy, and compliance posture reporting

MediumNSX+SaaSCloud Management

🛈Context: NSX+ is VMware's SaaS offering for centralized NSX management across multiple on-premises sites. It provides cloud-based policy management, security posture dashboards, and simplified multi-site networking without deploying Global Manager on-prem.

Capabilities

Centralized Policy: Manage DFW, routing, and segments across all sites from one cloud console
Security Posture: Compliance scoring, drift detection, and remediation recommendations
Multi-Site Networking: Stretch networks across sites without on-prem Global Manager
Intelligence-as-a-Service: Flow analytics and recommendations without NAPP deployment

Configuration

Connect on-prem NSX to NSX+ cloud service

# Prerequisites:
# - NSX 4.0+ on-premises deployment
# - VMware Cloud Services Portal (CSP) organization
# - Outbound HTTPS (443) from NSX Manager to VMware cloud

# Step 1: Register NSX Manager with CSP
# In NSX Manager UI: System > NSX+ > Connect to Cloud
# Enter CSP organization ID and API token

# Step 2: Verify connectivity:
GET https://<nsx-manager>/api/v1/nsx-plus/status
# Expected: "connection_status": "CONNECTED"
# "sync_status": "IN_SYNC"

# Step 3: Access NSX+ console:
# URL: https://nsx.cloud.vmware.com
# Login with CSP credentials
# All connected sites appear in unified dashboard

# Data synced to cloud:
# - Inventory (VMs, segments, groups, policies)
# - Security rules and posture metrics
# - Flow metadata (no payload data leaves on-prem)
# - Alarms and health status

# Data that stays on-prem:
# - Actual packet data and workload traffic
# - Credentials and certificates
# - Full API access remains local

Security posture and compliance reporting

# NSX+ provides automated security posture scoring:
# Factors:
# - % of workloads covered by DFW rules
# - % of segments with microsegmentation
# - IDS/IPS coverage percentage
# - Certificate expiration status
# - Unprotected east-west flows count

# Access posture dashboard:
# NSX+ Console > Security > Posture
# Score: 0-100 (higher = more secure)

# Drift detection:
# NSX+ compares current config against baseline
# Alerts on: new unprotected VMs, rule deletions,
# permission changes, TZ modifications

# Compliance frameworks:
# Map NSX security controls to:
# - PCI-DSS (Requirement 1: Firewall, Req 6: Patching)
# - HIPAA (Access Controls, Audit)  
# - NIST 800-53 (SC-7: Boundary Protection)
# Export compliance reports as PDF for auditors

NSX Container Networking (NCP/Antrea) — Kubernetes Integration

Configure NSX Container Plugin (NCP) or Antrea CNI for Kubernetes pod networking, network policies, and DFW-to-pod microsegmentation

HighNCPAntreaKubernetesContainer Networking

🛈Context: NSX provides container networking via two approaches: NCP (NSX Container Plugin) for full NSX integration with per-pod logical ports, or Antrea CNI with NSX management plane integration for Tanzu Kubernetes clusters. Both enable DFW microsegmentation at the pod/namespace level.

Architecture Options

NSX Container Plugin (NCP)

Full NSX integration — each pod gets NSX logical port
DFW rules applied directly to pod vNICs
NSX segments mapped to K8s namespaces
T1 gateway per namespace for routing isolation
Best for: Tanzu on vSphere, full NSX investment

Antrea CNI + NSX

Antrea handles in-cluster networking (OVS-based)
NSX manages multi-cluster policies and observability
K8s NetworkPolicy enforced locally by Antrea
NSX provides cross-cluster security and Intelligence
Best for: Multi-cluster, cloud-native approach

Configuration

NCP deployment and troubleshooting

# NCP runs as a pod in the K8s cluster (nsx-system namespace)
kubectl get pods -n nsx-system
# Expected: nsx-ncp-xxxx (Running), nsx-node-agent-xxxx (Running on each node)

# Check NCP health:
kubectl logs -n nsx-system -l component=nsx-ncp --tail=50
# Common errors:
# "Failed to create logical port" — IP pool exhausted
# "NSX Manager unreachable" — check connectivity on port 443
# "Stale port" — pod deleted but NSX port not cleaned up

# NCP configuration (ConfigMap):
kubectl get configmap nsx-ncp-config -n nsx-system -o yaml
# Key settings:
# nsx_api_managers = <manager-ip-1>,<manager-ip-2>,<manager-ip-3>
# top_tier_router = /infra/tier-0s/<t0-id>
# overlay_tz = /infra/sites/default/enforcement-points/default/transport-zones/<tz-id>

# IP pool for pods:
# Each namespace gets a subnet from the configured IP block
GET https://<nsx-manager>/policy/api/v1/infra/ip-blocks
# Ensure sufficient /24 subnets available for namespace growth

# Troubleshoot pod connectivity:
# 1. Check pod's NSX logical port:
kubectl describe pod <pod-name> | grep nsx
# 2. Verify segment exists in NSX for the namespace
# 3. Check T1 router has correct static routes

DFW microsegmentation for containers

# NSX DFW can target pods using:
# - Namespace labels (mapped to NSX tags)
# - Pod labels (mapped to NSX segment port tags)
# - K8s NetworkPolicy (translated to DFW rules by NCP)

# Example: K8s NetworkPolicy (NCP translates to DFW):
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress: []  # Empty = deny all ingress

# NSX-native DFW rule targeting pods:
# Use NSX Manager UI or API to create rules with scope:
# Source: Tag = "k8s-namespace:production"
# Dest: Tag = "k8s-app:database"
# Service: TCP/5432
# Action: ALLOW

# Antrea ClusterNetworkPolicy (multi-cluster enforcement):
apiVersion: crd.antrea.io/v1beta1
kind: ClusterNetworkPolicy
metadata:
  name: restrict-db-access
spec:
  priority: 5
  tier: securityops
  appliedTo:
  - podSelector:
      matchLabels:
        app: postgres
  ingress:
  - action: Allow
    from:
    - podSelector:
        matchLabels:
          role: backend
    ports:
    - protocol: TCP
      port: 5432
  - action: Drop