Deploy Sophos NDR on VMware ESXi or Hyper-V

Sophos NDR runs on ESXi or Hyper-V as a virtual Integration Appliance. The VM requires two clearly separated paths: MGMT obtains a normal IP address and reaches Sophos Fusion (formerly Sophos Central) or the Sophos Data Lake; SPAN1 and optional SPAN2 receive only mirrored copies of the traffic to be inspected. A green VM or the Central status Connected therefore does not yet confirm that NDR can see packets.

Quick workflow: Check prerequisites and capacity, create the NDR configuration in Sophos Fusion, prepare mirroring for the relevant platform, deploy the generated image exactly once, wait for the initial startup and automatic restart to finish, and then validate the management and SPAN paths separately.

Important boundary: The SPAN path is not inline and must not be used as the management network. Mirroring is configured on the switch and hypervisor; the NDR appliance does not modify the original production traffic. For Hyper-V, no external PowerShell mirroring commands are deliberately provided here. Implement the design in Hyper-V according to the approved Microsoft and Sophos guidance and verify it with real test traffic.

Verify the prerequisites

The following minimum requirements initially apply to both platforms:

an active Sophos Network Detection and Response integration license pack entitlement in the tenant being used;
4 vCPUs, 16 GB RAM, and 160 GB storage;
the CPU flags pdpe1gb for Packet Capture and avx2 for the machine learning features;
a dedicated management network with DHCP or a static address, DNS, a default gateway, and outbound internet access;
prepared SPAN paths for bidirectional copies of all approved traffic classes: virtual internal traffic and physical external traffic, if both are part of the agreed monitoring scope;
documented ownership for Central, the hypervisor, physical switches, and firewall allowlisting.

If the approved scope actually contains only one of these traffic classes, document that boundary explicitly. A single SPAN path must then not be considered coverage of the other class.

Do not install an additional Sophos Agent or any other antimalware agent on the appliance. Sophos manages operating system, security, and appliance updates. Custom patching or hardening requirements must not alter this managed state without prior validation.

Platform limits

VMware ESXi requires:

ESXi 6.7 Update 3 or later;
VM hardware version 11 or later;
an EVC mode of Skylake or later when Enhanced vMotion Compatibility is used;
no deployment in VMware Cloud, because it is not supported.

The CPU flags must remain visible in the VM through the selected EVC mode. A recent physical processor alone is not sufficient if EVC hides required capabilities.

Microsoft Hyper-V requires:

Hyper-V 6.0.6001.18016, corresponding to Windows Server 2016, or later;
Processor Compatibility Mode disabled;
no more than 8 CPU cores and 32 GB RAM per NDR VM;
a maximum of one NUMA node and one CPU socket.

The Hyper-V limits are not a recommendation to always assign the maximum resources to the VM. They prevent an unsupported NUMA topology.

Size the VM according to traffic

The standard size with 4 vCPUs is intended for a dedicated NDR appliance up to these guidelines:

500 Mbit/s,
70'000 packets per second,
1'200 flows per second.

For high load up to 1 Gbit/s, 300'000 packets per second, or 4'500 flows per second, use 8 vCPUs. SPAN2 also requires at least 8 vCPUs. If the load exceeds these values, distribute it across multiple NDR appliances at suitable network points; do not scale a single VM beyond the documented limits.

If additional log collector integrations run on the same appliance, plan their load separately. NDR reserves two CPUs with high priority when using 4 vCPUs and three when using 8 vCPUs. Other integrations can nevertheless load these CPUs. With 16 GB RAM, log collector integrations may use no more than 2 GB in total. Regardless of the number of integrations, an appliance accepts no more than 8'000 log events per second. Only one NDR integration is possible per appliance.

Allow outbound connections

If the firewall supports wildcards, the appliance requires these destinations:

Destination	Port and protocol
`*.sophos.com`	TCP 443 and TCP 22
`*.amazonaws.com`	TCP 443
`*.ntp.org`	UDP 123
`sophossecops.jfrog.io`	TCP 443
`yum.oracle.com`	TCP 443, optional

yum.oracle.com is optional because the appliance uses the Sophos JFrog mirror if it cannot reach that destination. Do not blindly extend wildcards to other zones. If the firewall does not allow wildcards, add the complete current region-specific Sophos hostname list to the allowlist before the change and verify it from the MGMT zone with DNS and connectivity tests. A shortened list or one copied from another region is not a safe substitute.

Create the integration and image in Sophos Fusion

In Sophos Fusion, open Threat Analysis Center > Integrations > Marketplace.
Select Sophos Network Detection and Response (NDR).
Under Data Ingest (Security Alerts), click Add Configuration.
In Step 1, enter a unique name and a description for the integration.
In Step 2, select an existing appliance or click Create new appliance. An existing appliance must not already have another NDR integration.
For a new appliance, choose a unique Appliance name, a description, and the correct platform, VMware ESXi or Microsoft Hyper-V.
Under Internet-facing network port settings, configure either DHCP or Manual. An address assigned by DHCP must be reserved.
In Step 3, enter an Exclusion list name. This name is required even if the list is initially empty.
Finish by clicking Save.

For Manual, complete the IP address, Subnet mask, Gateway address, DNS 1, and optional DNS 2 fields. An internal example is:

IP address: 10.0.252.5
Subnet mask: 255.255.255.0
Gateway address: 10.0.252.1
DNS 1: 10.0.252.53
DNS 2: 10.0.252.54

Replace these values with available addresses and reachable DNS servers from your own management network. Check the static address against the DHCP pool, IPAM, and existing hosts in advance.

Under Domain exclusions, you can enter a domain name. Protocol exclusions has one field for the master protocol, such as TCP or UDP, and one field for the subprotocol, such as facebook; when both are specified, Central joins them with a single period. Do not exclude an entire master protocol merely to reduce data volume. Every exclusion requires a confirmed false positive or a justified capacity decision, an owner, and a review date.

After saving, select the platform-specific download in the Actions column: Download OVA file for ESXi or the ZIP package for Hyper-V. The status to the left of the integration changes to Waiting for deployment. The image contains the specific appliance configuration and must not be reused across tenants or appliances.

Deploy on VMware ESXi

1. Prepare SPAN port groups

For virtual internal traffic, create a dedicated port group on the relevant standard vSwitch:

Open Networking > Virtual switches and select the intended vSwitch.
Under Port groups, click Add port group.
Assign a unique name.
Set VLAN ID to 4095.
Under Security, set Promiscuous mode to Accept.
Save the port group.

For mirrored traffic from a physical switch, use a separate vSwitch with its own SPAN port group following the same pattern. Under vSwitch topology, use Add uplink to assign an available physical NIC. Connect the dedicated mirror destination port on the physical switch directly to this NIC on the ESXi host.

On the physical switch, select only the approved ports or VLANs as mirror sources and select both directions. The destination port carries copies to the ESXi NIC and must not simultaneously be used as a normal access, trunk, or management port. The exact switch syntax is vendor-specific and must not be copied from an example for a different model.

If physical SPAN and vMotion are used together, the NDR VM must remain on the ESXi host whose physical NIC receives the mirror traffic. An unintended migration to another host can silently remove the SPAN path even though MGMT continues to work.

2. Import the OVA and map interfaces

The downloaded OVA is tied to this Central configuration and can be used only once. Generate a new OVA in Central for a replacement or fresh deployment.

On the ESXi host, open Virtual Machines > Create/Register VM.
Select Deploy a virtual machine from an OVF or OVA file.
Enter a VM name and select ndr-sensor.ova.
Select Standard as the storage type and then choose the intended datastore.
Under Deployment options, map the networks carefully:
- SPAN1: first prepared SPAN port group;
- SPAN2: second SPAN port group, if actually required;
- SYSLOG: for a dedicated NDR appliance, select a placeholder port group and disconnect the adapter after the import;
- MGMT: the management port group with DHCP or the static network parameters entered in Central.
Set Disk Provisioning to Thin.
Enable Power on automatically.
Skip Additional settings without making changes and click Finish to import.

Before powering on the VM for the first time, document the mapping, link status, and MAC addresses of all vNICs again. MGMT must not be on a SPAN port group. If SPAN2 is used, the VM must have at least 8 vCPUs.

Deploy on Microsoft Hyper-V

1. Prepare the mirroring design

Before running the script, determine which purpose each vSwitch serves:

a normal vSwitch for MGMT with DHCP or the planned static network path;
a destination path for SPAN1;
optionally, a second destination path for SPAN2, in which case at least 8 vCPUs are required;
no active SYSLOG path unless the same appliance also processes approved third-party integrations.

For Hyper-V, the mirroring configuration conceptually consists of four parts: a traffic mirroring port, a SPAN Virtual Interface connected to the vSwitch, the enabled Microsoft NDIS Capture Extension, and correctly configured Source and Destination mirroring modes. The implementation depends on the Windows/Hyper-V version, vSwitch type, and source of the traffic to be mirrored. For this reason, do not copy unverified PowerShell commands from other environments.

Before starting NDR, the platform team checks the intended path as a deployment smoke test using a known bidirectional test flow. The copy must arrive at the intended destination path without altering the original production flow. Only then is this vSwitch selected as the SPAN destination in the Sophos script. This single test does not confirm complete mirroring coverage.

2. Extract the ZIP and run the Sophos script

Extract the ZIP downloaded from Central to a protected local folder on the Hyper-V host. It contains virtual disks, seed.iso, and ndr-sensor.ps1.
In the folder, start ndr-sensor.ps1 with Run with PowerShell.
At the Security Warning, verify the local file downloaded directly from Central and approve it with Open.
Enter a unique VM name.
Check the displayed new VM directory in the default path for virtual disks and enter C to create it.
Specify 4 CPUs for the standard size or 8 CPUs for high load or SPAN2.
Specify 16 GB RAM as the default; do not exceed the Hyper-V limit of 32 GB.
From the numbered vSwitch list, select the MGMT vSwitch first.
For SYSLOG on a dedicated NDR appliance, select a placeholder vSwitch and disconnect this adapter after creation.
Select the prepared vSwitch for SPAN1 and, if planned, the one for SPAN2.
Wait for Installation Completed Successfully and then press any key to exit the script.
Open the new VM in Hyper-V Manager and, before starting it, check the CPU, RAM, network adapters, connected vSwitches, and disconnected SYSLOG adapter.

The virtual disks and seed.iso generated by Sophos belong together. Do not replace individual files with identically named files from an older download.

Initial startup and deployment smoke test

During the initial startup, the appliance checks the assigned networks and internet access, and then restarts automatically. This process can take up to ten minutes.

Do not interrupt the initial startup and automatic restart. Manually powering off the VM during this window can leave it in an incomplete state and is not a troubleshooting step.

Perform the technical deployment smoke test in this order:

VM console: The boot process finishes without a persistent error or restart loop.
Management path: The configured or reserved MGMT address, DNS, NTP, and required outbound destinations are reachable.
Central control path: Under Threat Analysis Center > Integrations > Configured > Integration Appliances, or on the NDR integration page, the appliance changes from Waiting for deployment to Connected.
SPAN path: For each deployed SPAN path, generate an announced, harmless test flow in both directions between two known test systems. On the switch or hypervisor, Source, Direction, and Destination must match the change; on the appliance, the mapped SPAN adapter must receive traffic.
Plausibility: Compare the time window, source and destination addresses, and direction of the observed test flow. The relevant deployed path is confirmed for this smoke test only when these values match.
Load: During an initial suitable load window, compare throughput, packets, and flows with the selected sizing tier. A Connected status is not proof of capacity.

A single artificial detection is not required for the deployment smoke test. What matters is a stable management path and proven bidirectional traffic on the correct SPAN interface. The test flow contains neither malware nor real customer data in a Packet Capture.

This smoke test proves only the paths specifically tested. Full acceptance of all intended sources, VLANs, directions, and traffic classes belongs in the separate runbook Plan and validate traffic mirroring for Sophos NDR; neither Connected nor one successful flow is treated here as proof of comprehensive mirror coverage.

Troubleshoot by symptom

The status remains Waiting for deployment

Verify that the correct image, newly downloaded from this configuration, was deployed.
Check the VM console and power state, and allow at least ten uninterrupted minutes for the initial startup.
Compare the MGMT vNIC, port group or vSwitch, and DHCP reservation or static fields.
Check DNS, gateway, NTP, TCP 443, TCP 22, and UDP 123 from the management network according to the allowlist.
Redeploy only after these checks. On ESXi, a newly generated OVA is required; do not import the already used OVA again.

Connected, but no NDR traffic

On ESXi, first check the SPAN1/SPAN2 mapping, VLAN ID 4095, Promiscuous mode: Accept, physical uplink, and mirror destination port. When using vMotion, verify that the VM still runs on the host with the connected SPAN NIC.

On Hyper-V, the platform team checks the SPAN Virtual Interface, NDIS Capture Extension, Source/Destination mode, and the vSwitch selected in the Sophos script. Do not add firewall rules or invented mirroring commands on speculation.

On both platforms, do not immediately narrow the test filter further: first check adapter counters and a clearly identifiable bidirectional flow. MGMT traffic on the MGMT adapter is not proof that SPAN works.

Only one direction or one network is visible

The mirror source must include both sending and receiving.
With asymmetric routing, the return path may use a different uplink.
Virtual internal and physical external traffic may require separate SPAN paths.
If SPAN2 is configured, the second vSwitch or port group must be mapped correctly and at least 8 vCPUs must be available.

Repeat exactly the same test flow after each correction. This makes it clear which change had an effect.

Dragonfly remains Pending

If Central is already Connected but NDR is not working, check the Dragonfly service status in the Sophos VA Console. Before this step, local console access must have been provided according to the separate runbook Operate the Sophos NDR Integration Appliance and sensor. Do not reuse hypervisor or Central credentials without validation for this purpose; this deployment runbook does not create or disclose local appliance credentials.

For Pending in an ESXi EVC cluster, first check the EVC mode and visible CPU capabilities. Sandy Bridge is not supported for this use; Skylake or later as well as pdpe1gb and avx2 are required.

On Hyper-V, also check Processor Compatibility Mode, CPU and RAM limits, and the topology with no more than one NUMA node and one CPU socket. Do not attempt to “fix” the VM by adding CPUs or RAM beyond the supported limits.

Packets or results are missing under load

Compare current throughput, packets, and flows with the sizing limits. If a SPAN destination is slower than the combined sources, the copy can drop packets while production traffic continues without interruption. In that case, narrow the source selection, split the SPAN paths, or use multiple appliances. Broad protocol exclusions are not a substitute for correct sizing.

Locally scoped rollback of this deployment

The following steps are a conservative local change-back recommendation for the passive deployment described here. They are not a complete decommissioning or offboarding procedure documented by Sophos. The rollback is deliberately limited to the sensor and mirror objects newly created as part of the change:

Save the test evidence and last known states: Central status, VM resources, interface mapping, mirror sources, and directions.
First disable the SPAN or mirroring session on the switch or hypervisor. Do not delete or recable production source ports, VLANs, or vSwitches in the process.
Verify that the original traffic continues to work and that no more copies arrive at the NDR destination path.
Then shut down the NDR VM gracefully.
Remove dedicated port groups, vSwitches, uplinks, or VM files only after confirming that they are used exclusively by this appliance. Shared management or production objects remain in place.
Roll back the static DHCP reservation, firewall allowlist, and DNS records as separate changes after checking their references.

The Central integration or appliance is not deleted as part of this local rollback. Such deletion is outside this deployment rollback and requires a separately validated and approved offboarding process. Likewise, an existing OVA is not treated as a rollback image: generate a new image in Central for another ESXi deployment.

After a failed initial startup, the locally scoped rollback is therefore: stop mirroring, power off the VM, roll back only the network objects clearly associated with this change, and identify the cause before a new deployment. Do not spontaneously convert a passive NDR test to another network design or an inline path.