MPS Malware Detonation Installation Error: Failed to authenticate with the guest operating system using the supplied credentials.

Products

• VMware vDefend Firewall
• VMware vDefend Firewall with Advanced Threat Prevention

Issue/Introduction

MPS Malware Detonation installation may fail early immediately after the first VM (i.e. the VPN Gateway VM) is created, with error "Failed to authenticate with the guest operating system using the supplied credentials.". This generally happens because the VM boot sequence gets stuck waiting for networking to come online, because there are problems in the supplied network configuration during MPS Malware Detonation setup.

Environment

Security Services Platform (SSP) 5.2.0 with MPS Static Analysis installed and MPS Malware Detonation installation in error state

Cause

When the VPN Gateway VM is created, the networking configuration chosen during MPS Malware Detonation setup is passed as a netplan configuration string to the network-config OVF parameter. When the VM boots, its boot sequence will apply this netplan configuration, and then wait until the systemd-networkd-wait-online.service service completes running. This service waits until the netplan configuration finishes bringing the network up. The definition of what "up" is depends on the network configuration supplied, but ultimately means that the network interfaces are able to make the network communications that the configuration dictates they should be usable for. 

The other configurations for the VPN Gateway VM (e.g. the guest operating system authentication credentials) are supplied to the VM via a separate user-data OVF parameter that is passed to cloud-init. But cloud-init is not run until after systemd-networkd-wait-online.service finishes. Thus, if there is a problem in the networking configuration that causes systemd-networkd-wait-online.service to block for too long, then cloud-init will not run in time before MPS Malware Detonation tries to authenticate to the guest operating system in the VM, thus causing MPS Malware Detonation to fail with this "Failed to authenticate with the guest operating system using the supplied credentials." error.

Steps to retrieve Pod Logs: 

1. SSH into the ssp-installer host:

   ssh sysadmin@<IP_OF_SSP_INSTALLER>

2. Find the most recent malware-analysis-vc-fe3-pipeline-pre-install-* pod: 
    

   k --ssp <SSP_INSTANCE_NAME> --namespace nsxi-platform get pods | grep malware-analysis-vc-fe3-pipeline-pre-install
   
   
3. Inspect the logs of that pod: 
    

   k --ssp <SSP_INSTANCE_NAME> --namespace nsxi-platform logs <POD_NAME> | less
    

This error can be observed in the malware-analysis-vc-fe3-pipeline-*  pod logs, e.g.: 

2026-07-13 07:14:42,630 - fe3.pipeline_stage.vm_maintainer_stage - INFO - Creating onprem-sandbox-anonvpn-for-vDefend-5.2.0.0.0-r25400461-primary-vm1 from OVF onprem-sandbox-anonvpn-for-vDefend-5.2.0.0.0-r25400461 in fe3-content-library
2026-07-13 07:15:57,739 - fe3.pipeline_stage.vm_utils - INFO - Powering on the vm.
2026-07-13 07:15:57,757 - amg_vmware_api_helper.vsphere_api_helper - INFO - Powering on VM: onprem-sandbox-anonvpn-for-vDefend-5.2.0.0.0-r25400461-primary-vm1
2026-07-13 07:15:58,985 - amg_vmware_api_helper.vsphere_api_helper - INFO - Sleeping for 5 seconds before checking again if guest tools is running
2026-07-13 07:16:03,993 - amg_vmware_api_helper.vsphere_api_helper - INFO - Sleeping for 5 seconds before checking again if guest tools is running
2026-07-13 07:16:09,001 - amg_vmware_api_helper.vsphere_api_helper - INFO - Sleeping for 5 seconds before checking again if guest tools is running
2026-07-13 07:16:14,010 - amg_vmware_api_helper.vsphere_api_helper - INFO - Sleeping for 5 seconds before checking again if guest tools is running
2026-07-13 07:16:19,018 - amg_vmware_api_helper.vsphere_api_helper - INFO - Sleeping for 5 seconds before checking again if guest tools is running
2026-07-13 07:16:24,028 - amg_vmware_api_helper.vsphere_api_helper - INFO - Sleeping for 5 seconds before checking again if guest tools is running
2026-07-13 07:16:29,038 - amg_vmware_api_helper.vsphere_api_helper - INFO - Sleeping for 5 seconds before checking again if guest tools is running
2026-07-13 07:16:34,048 - amg_vmware_api_helper.vsphere_api_helper - INFO - Sleeping for 5 seconds before checking again if guest tools is running
2026-07-13 07:16:39,058 - amg_vmware_api_helper.vsphere_api_helper - INFO - Sleeping for 5 seconds before checking again if guest tools is running
2026-07-13 07:16:44,065 - fe3.pipeline_stage.vm_utils - INFO - Give cloud init a couple extra seconds to setup the user.
2026-07-13 07:16:54,086 - amg_vmware_api_helper.vsphere_api_helper - INFO - Running /usr/bin/cloud-init status > /tmp/status.txt in guest
2026-07-13 07:16:57,411 - amg_vmware_api_helper.vsphere_api_helper - INFO - Powering off VM: onprem-sandbox-anonvpn-for-vDefend-5.2.0.0.0-r25400461-primary-vm1
2026-07-13 07:16:57,847 - amg_vmware_api_helper.vsphere_api_helper - INFO - Deleting VM: onprem-sandbox-anonvpn-for-vDefend-5.2.0.0.0-r25400461-primary-vm1
2026-07-13 07:16:58,178 - fe3 - ERROR - Error while executing the mcllama preparation steps for clone onprem-sandbox-anonvpn-for-vDefend-5.2.0.0.0-r25400461-primary-vm1: Error starting program /usr/bin/cloud-init. (vim.fault.InvalidGuestLogin) {
   dynamicType = <unset>,
   dynamicProperty = (vmodl.DynamicProperty) [],
   msg = 'Failed to authenticate with the guest operating system using the supplied credentials.',
   faultCause = <unset>,
   faultMessage = (vmodl.LocalizableMessage) []
}

 

Resolution

To resolve this problem, the specific error(s) in the networking configuration needs to be resolved.

Depending on the configuration and on the networking environment that the vSphere cluster exists in, there can be many different errors that will present with this same "Failed to authenticate with the guest operating system using the supplied credentials." MPS Malware Detonation failure behavior. Here are some commonly observed networking configuration errors and their resolutions:

 

Configuration	Resolution	Notes
Management Network and Detonation Network configured for same network port group	Use a separate isolated network port group for the Detonation Network	While this is a bad configuration, it may appear to work, and MPS Malware Detonation installation may actually be able to complete. Some example scenarios: If the Management network is configured with a static networking configuration and there is no DHCP server listening on the management network, then the DHCP server run by the VPN Gateway VM for the sandbox VM's will be able to service the sandbox VMs on the management network without a problem If the Management Network is configured to receive its networking configuration from DHCP, then the Management Network interface will receive its DHCP lease from the Management Network's DHCP server before it begins running a DHCP server on the Detonation Network interface. However, once the Detonation Network Interface's DHCP server is running, it will begin competing/conflicting with the Management Network's DHCP server, which can cause undefined behavior on the Management Network. This undefined behavior may manifest in the aforementioned guest operating system authentication error during MPS Malware Detonation installation, in a different unknown error, or MPS Malware Detonation installation may even appear to complete correctly. It has been observed that if MPS Malware Detonation appears to complete correctly, the Life Cycle Manager that manages the life of the VPN Gateway VM may decide to try to recreate the VPN Gateway VM, and the newly created VM's Management Interface will likely receive a DHCP lease from the first VPN Gateway VM that has not yet been deleted. This can ultimately cause systemd-networkd-wait-online.service to not complete in the new VPN Gateway VM, resulting in the same aforementioned guest operating system authentication error.
Management Network configured to receive configuration from DHCP, when no DHCP server is listening on Management Network port group	Either: Configure a DHCP server that is connected and listening on the network port group being used as the Management Network Provide a static network configuration for the Management Network during MPS Malware Detonation setup	In this case, systemd-networkd-wait-online.service will wait until a DHCP lease is received for the DHCP request that the Management Network Interface makes. Since there is no DHCP server to respond with a lease, systemd-networkd-wait-online.service blocks and ultimately causes the aforementioned guest operating system authentication error. For a static configuration, be careful to not confuse fields: "Gateway VM IP": IP address to be assigned to the Management Network interface of the Gateway VM "Default IPv4 Gateway": Default gateway of the Management Network