Views:

To troubleshoot this issue:

  1. Make sure that NSX Security Groups and NSX Policy for Deep Security exist and the affected VM exist on the Security Group's VM list.

    1. In vSphere Web Client, go to Home > Networking & Security > Service Composer > Security Groups and make sure that Deep Security group exist.

      Check for Deep Security group

    2. Go to Home > Networking & Security > Service Composer > Security Policies and make sure that Deep Security policy exist.

      Check for Deep Security policy

       
      If either of Security Group or Security Policy for Deep Security does not exist, create these by following the instructions in an article from the Deep Security Help Center: Create NSX security groups and policies.

    3. Go to Home > Networking & Security > Service Composer > Security Groups and make sure that the affected VM exists in list of VMs on the Deep Security Group.

      Check for affected VM

      If the affected VM doesn't exist on this list, edit the Deep Security Group and modify the "Select objects to include" so that it includes the cluster where the agentless protected VM resides. Refer to the Deep Security Help Center article: Create NSX security group and policies.

  2. On the Deep Security Manager console, make sure that the Trend Micro Deep Security Appliance version is displayed as higher than 9.5.2-2202. The appliance's initial version is 9.5.2-2202 which will be automatically upgraded to higher version provided that the Deep Security Manager has the latest Agent-RedHat_EL6 package available in it's software list.

    Check for DSA version

  3. Make sure that the affected VM is listed in ESXi's /var/run/muxconfig.xml.

    1. On the vSphere Web Client, get the UUID of the affected VM by displaying the UUID column of the VMs list.

      get the UUID

    2. Log in to ESXi command line and search for this UUID in /var/run/muxconfig.xml file.

      ESXi command line

      If the UUID does not exist in muxconfig.xml, restart the Guest Introspection VM and then restart the EPSEC service by executing "/etc/init.d/vShield-Endpoint-Mux restart" on the ESXi command line. If this still does not help, upgrade the NSX Manager to the latest supported version and re-install the Guest Introspection service.

  4. Make sure that the Guest Introspection driver (vsepflt) is installed and running on the protected machine.

    1. Run msinfo32 on the affected VM.

    2. Go to System Drivers and make sure that vsepflt exists and is running.

      If the vsepflt does not exists, install the Introspection driver from the VMWare Tools. Afterwards, run the command "fltc load vsepflt" to load the driver.

      Check vsepflt

  5. Verify that only one Deep Security Appliance exist on an ESXi host. If there exist an old Deep Security Virtual Appliance from previous installation, delete it even if it's unused or powered off.
  6. If NSX Manager was an upgrade from vShield Manager, it's recommended to just redeploy the NSX Manager. In many cases, the SOAP Web Service API is not upgraded/migrated correctly when upgrading vShield Manager to NSX which causes NSX to give wrong information to Deep Security Manager.
  7. If NSX free license is used, turn off Firewall, Intrusion Prevention, and Web Reputation on all policies unless the VMs have Deep Security Agent installed. Otherwise, this results to "Firewall Engine Offline", "Intrusion Prevention Engine Offline", and "Connection to Filter Driver Failure" errors.To use agentless Firewall, Intrusion Prevention, and Web Reputation features, NSX Advanced or Enterprise license is required.
Keywords: Anti-malware Engine Offline,Firewall Engine Offline,Intrusion Prevention Engine Offline,Connection to Filter Driver Failure,Agentless NSX environment,configuration,errors in Deep Security Agentless NSX Environment,Agentless NSX Environment error,correct c