FAQ - Security Services Platform ( SSP)
search cancel

FAQ - Security Services Platform ( SSP)

book

Article ID: 394988

calendar_today

Updated On:

Products

VMware vDefend Firewall VMware vDefend Firewall with Advanced Threat Prevention

Issue/Introduction

This article provides a consolidated repository of frequently asked questions (FAQs), architectural details, and operational guidance for the Security Services Platform (SSP) and its features.

It addresses common queries encountered during deployment, lifecycle management, storage planning, and component troubleshooting to assist administrators in maintaining a healthy security platform environment.

Environment

 Security Services Platform (SSP)

Resolution

Security Services Platform (SSP)

General

1. Can we restore an SSP backup onto a different datastore?

Yes. The backup and restore (B&R) process does not have a hard dependency on the underlying datastore. For example, if you back up an instance on Datastore A, uninstall it, and reinstall it on Datastore B, the restore will work.

Workflow Steps:

  1. Prepare the environment: Deploy the SSP on an NFS datastore, onboard the NSX Manager, and configure the SFTP server for Backup and Restore.

    • Note: To deploy on an NFS datastore, add the NFS datastore, create a Datastore Tag-Category pair, apply the tag to the NFS datastore, and create a Tag-based Storage Policy in vCenter.

  2. Take a backup: Perform a manual backup of the current SSP instance.

  3. Tear down: Offboard the NSX Manager and delete the existing SSP instance.

  4. Deploy the new instance: Deploy a fresh SSP instance using the exact same build version via the SSP Installer (SSP-I) onto a vSAN datastore.

    • Note: Complete the onboarding of the same NSX site immediately, as the UI requires onboarding before allowing navigation to other pages.

  5. Target the backup repository: Configure the exact same SFTP server and directory path utilized in Step 1.

  6. Fetch backups: Navigate to the Backup and Restore page on the SSP UI and click Restore to retrieve historical backup states.

  7. Restore: Select the desired backup point and execute the restore operation.

    • Note: This same logic applies when migrating to a new Storage Policy.

2. What configurations are backed up during the B&R process?

For a detailed breakdown of the exact configuration components saved during a backup, please refer to the official documentation:

⚠️ Important: Security Services Platform (SSP) backup and restore operations are not supported on the Evaluation deployment type.

3. As per the Ports and Protocols page, LDAP uses ports 389 / 636. Can this be customized to use the Global Catalog Port 3269 instead?

Yes. Customizing the LDAP configuration to utilize Global Catalog port 3269 (or 3268 for non-SSL) is fully supported.

4. How do I add multiple LDAP authentication providers?

The platform currently allows you to configure only one identity source at a time. Multi-provider LDAP environments are not supported. For more details, see the official documentation:

5. Why does configuring an SFTP backup server fail on a Windows Server with public key errors?

If you encounter errors such as Failed to create sftp client or sftp: problem parsing server host public key: ssh: no key found, it is because only Linux-based SFTP servers are supported on the version SSP 5.0 and certified as target repositories for SSP backups. Windows Server host key parsing is available from the version SSP 5.1 onwards.

6. Can SSP be deployed on a vSAN Stretched Storage Cluster?

Yes, this topology is supported. For specific deployment prerequisites and configurations, review the following guide:

7. Can multiple SSP instances be deployed on the same vCenter Server?

Yes. Multiple distinct SSP instances can coexist and be managed within a single vCenter Server instance.

8. Can we modify the Site Name for NSX after the SSP deployment?

No. Setting the site-name during the onboarding of the NSX Manager is a one-time immutable operation.

The site-name is tightly coupled with internal configuration schemas, database structures, clusters, and backup schedules throughout the NSX ecosystem. Changing it post-deployment introduces structural mismatches that can lead to configuration corruption or service failures. Renaming requires a full uninstallation and reinstallation of the platform.

9. How do I enable SSH on the SSP Installer (SSP-I) VM?

If the SSP-I OVA was deployed without selecting the "Enable SSH" checkbox during the vSphere OVF deployment wizard, you can manually enable it via the CLI:

  1. Open the VM Web Console via vCenter.

  2. Log in using your root credentials.

  3. Run the following command:

    systemctl start ssh

  4. (Optional) To ensure it persists across restarts, run:

    systemctl enable ssh


10. Why does the SSP UI fail to load with the error "Failed to fetch form factor"?

This is expected behavior when one or more internal Kubernetes worker nodes drift into a NotReady state. When the UI cannot resolve node health, it fails to evaluate the form factor deployment type.

Resolution: Investigate the health of the underlying nodes by checking the MachineHealthCheck (MHC) components. Refer to the High Availability documentation for recovery procedures:


11. Does every vCenter certificate rotation necessitate full node recreation, and is there a grace period before the vSphere CSI driver times out?

  • Node Recreation Behavior: Yes, this is by design. The vCenter certificate thumbprint is statically embedded within the node template specifications defined inside the SSP Installer (SSPI). When a vCenter certificate rotates, a thumbprint mismatch occurs. Reconnecting the SSPI to vCenter triggers a template regeneration process, which purposefully decommissions old nodes and provisions new ones with the updated thumbprint to ensure cryptographic integrity.

  • Timeout / Grace Period: The vsphere-csi driver does not feature an automated grace period or timeout handling for certificate mismatches. The moment a mismatch occurs, CSI pods immediately fail initialization and will trigger a CrashLoopBackOff (CLBO). Node regeneration must be manually and explicitly initiated to restore cluster storage communication.


12. What causes frequent vCenter events regarding container volume and storage activities (e.g., Attach/Detach, Update, or Delete virtual storage objects)?

These events are standard operations. The SSP runs an upstream Kubernetes cluster that uses the native vSphere Container Storage Interface (CSI) driver to manage lifecycle volumes.

  • Reason for Occurrence: When application pods utilizing a PersistentVolumeClaim (PVC) are scaled, restarted, rescheduled, or undergo rolling updates, the Kubernetes control plane constantly requests vCenter to dynamically map, move, detach, or reattach backend storage objects to the respective active worker nodes.

  • Is this a concern? No. This represents expected CSI-driven lifecycle behavior within a healthy Kubernetes-on-vSphere environment and does not signify errors or service degradation. No administrative action is required.


13. The recommended platform storage is significantly higher than the minimum required storage. Which components grow over time to contribute to this increased requirement?

  • Minimum Storage represents the baseline capacity required to satisfy initial pre-deployment validation checks.

  • Recommended (Maximum) Storage accounts for future system scale-out operations.

As the platform scales, storage consumption grows across two primary layers:

  • VM Local Storage: Scale-out adds additional nodes to the cluster, with each virtual machine requiring an allocation of 200 GB of local storage.

  • Persistent Volume (PV) Storage: Increasing application replica counts naturally drives higher utilization across backend Persistent Volumes (PVCs).

ℹ️ Note: The Content Library footprint (~50 GB) and the system Reservation Buffer (~200 GB) remain completely static and do not expand during scale-out operations.


14. In the storage breakdown under "Content Library and VM Storage" (1,650 GB), does this imply that 250 GB is allocated to the Content Library/buffer and the remaining 1,400 GB is for VM storage (7 nodes × 200 GB)?

Yes, that interpretation is correct. The Content Library resides on the vCenter server and requires approximately 50 GB. Each control plane and worker node requires 200 GB of local storage.

The exact breakdowns across different deployment scales are detailed below:

Advanced Deployment (Standard 7-Node Setup)

  • Local VM Storage: 1,400 GB (7 nodes × 200 GB per node)

  • Reserved Buffer: 200 GB (Reserved for future system overhead)

  • Content Library: 50 GB

  • Total Capacity Required: 1,650 GB

Large Advanced Deployment (Full 13-Node Scale-Out)

  • Local VM Storage: 2,600 GB (13 nodes × 200 GB per node)

  • Reserved Buffer: 200 GB

  • Content Library: 50 GB

  • Total Capacity Required: 2,850 GB

Persistent Volume (PV) Storage Overhead In addition to the VM base storage listed above, separate datastore capacity must be provisioned for Kubernetes Persistent Volumes:

  • Initial/Minimum PV Allocation: 1,600 GB

  • Maximum Potential PV Allocation: 3,000 GB

Full Scale-Out Target: At maximum operational capacity (13 nodes combined with maximum PV utilization), the total environment footprint requires:

2,850 GB (VM + Base Storage) + 3,000 GB (Max PV Capacity) = 5,850 GB


15. What specific data is stored within the Content Library, and what is its primary operational purpose in this deployment?

The Content Library hosts the primary golden ISO/OVA images required to provision and scale cluster worker nodes.

Its primary purpose is to centralize, standardize, and streamline lifecycle operations, ensuring that any newly added worker nodes are built from an identical, validated installation source.



Distributed Malware Prevention Service (MPS)

1. If the central MPS-specific pods are down, will file detections and preventions still function on the host?

Yes, malware detection and prevention will continue to function in a "headless" mode via the deployed host-level Service VMs (SVMs), but with specific operational limitations:

  • Local Enforcement: The SVMs will successfully block or delete known malicious files on guest VMs using their locally cached threat signatures (ASDS cache).

  • UI Visibility Loss: Because the central platform MPS pods are offline, any detection or prevention actions taken by the SVMs cannot be transmitted or logged. Consequently, these events will not appear in the NSX/SSP User Interface.

  • Verdict Registration Failure: If new or unknown files are encountered, they may still undergo deep backend or cloud analysis, but their finalized threat verdicts cannot be synchronized or registered within the local MPS system until the pods are fully restored.

2. Can we customize or rename the default names of the deployed Service VMs (SVM) post-deployment?

Yes, modifying the name of the Service VM directly within vCenter is safe to perform and will not impact active operations. However, please note that this change is temporary; any future lifecycle operations, such as redeployments or appliance upgrades, will automatically revert the VM back to the default product naming convention.

3. Why does vCenter report a provisioned storage footprint of 160 GB for the Service VM (SVM) when the official documentation states it utilizes an 80 GB disk?

This is standard vSphere behavior triggered when active snapshots are running on a VMFS datastore. vCenter calculates the total Provisioned Space using the following breakdown:

  • Base Virtual Disk: 80 GB

  • Maximum Potential Snapshot Growth (Delta limit): 80 GB

  • Swap File Overhead: ~0.08 GB

  • Total Reported Provisioned Space: ~160.08 GB

The actual physical storage consumption remains safe (typically around 80–85 GB including the snapshot delta). Once the active snapshots are deleted or consolidated, the provisioned storage reporting in vCenter will return to the expected 80 GB display.


Network Detection and Response (NDR)

1. Does SSP-NDR have the capability to import and analyze IPFIX (NetFlow) data directly from physical network devices?

No. SSP-NDR is an event-driven correlation engine that operates strictly on high-fidelity security events generated by its native integrated detectors: IDPS (Intrusion Detection/Prevention), NTA (Network Traffic Analysis), and Malware Prevention.

Raw network flow ingestion via IPFIX is handled by the NSX Intelligence component rather than NDR. Currently, IPFIX telemetry collection is limited exclusively to NSX Transport Nodes exporting distributed firewall (DFW) traffic data. Direct IPFIX ingestion from external, third-party physical switches or routers is not supported.

2. Can SSP-NDR integrate with third-party Endpoint Detection and Response (EDR) platforms to correlate and enrich threat detection?

Currently, no. SSP-NDR is purpose-built and tightly coupled with the vDefend/NSX software-defined networking layer, which limits native interoperability with external ecosystem platforms.

There is currently no native EDR integration framework available in the platform. Expanded third-party security ecosystem integrations and cross-platform threat correlation are under consideration for future product roadmaps.

Powered by Wolken Software