Ingest network telemetry through a Sophos XDR collector

For OPNsense, pfSense, Netskope SSE and NetScaler ADC, the documented path uses a Sophos XDR Data Collector. Deploy the collector first, connect the source using its appropriate syslog format, then verify actual ingestion. A generic syslog destination address alone is insufficient: Sophos must correctly map the format and event category.

The netflow data described here requires a Sophos Next-Gen SIEM subscription. Netskope and NetScaler also provide other schemas, which do not all carry the same SIEM footnote in the product documentation. For OPNsense and pfSense, the reviewed scope consists of firewall connection events in netflow. SIEM scope and the integration guide explain selection and licensing.

Sources were checked on 27 October 2026.

Prepare the collector and source scope

Provision the collector for the correct tenant under Security Operations > Integrations > Data Collectors. The collector runbook explains resources, regional uplinks, DNS, time synchronization and the distinction from the old SVA and NDR. A new XDR Data Collector does not automatically take over an existing NDR workload.

Before changing a source, record its existing logging path, the new collector target, allowed source networks and intended event scope. Permit inbound syslog only from those networks. Do not replace a documented UDP path with TLS syslog or another format without checking compatibility. UDP does not acknowledge individual message delivery; consider losses when reconciling source and destination.

For each pilot, choose a harmless approved event with a timestamp and source evidence. A configured receiver or green integration status proves neither ingestion of every log type nor normalization. Accept communication, data flow and meaningful content separately.

OPNsense: filterlog over UDP/514

The documented OPNsense path processes filterlog messages for allowed or blocked TCP, UDP and ICMP connections. It requires OPNsense administration access and a reachable XDR Data Collector.

1. Once the collector is deployed, open the OPNsense remote logging configuration. Navigation varies with the OPNsense version; the field values below are those documented by Sophos.
2. Turn on Enabled and set Transport to UDP(4).
3. Under Applications, choose filter (filterlog). Select info, notice, warn, error, critical, alert and emergency under Levels. Leave Facilities empty.
4. Enter the actual collector IP in Hostname and set Port to 514. Turn off rfc5424. The documented Description is FilterLog; do not confuse that name with another log format.
5. Save and generate an intended harmless firewall event. The source rule must actually log it. First verify timestamp, source/destination address and action in OPNsense, then compare them in the Sophos netflow schema.

For a missing record, check source logging, the filterlog selection, UDP/IPv4 connectivity, target IP, port and RFC5424 setting. Do not disable protection rules merely to force a test flow.

pfSense: Firewall Events in BSD format

pfSense also provides TCP, UDP and ICMP firewall filter logs. The documented format differs from other pfSense logs and must not be replaced by an arbitrary remote-syslog selection.

1. Open Log Settings in pfSense administration.
2. Under General Logging Options, select BSD (RFC 3164, default) as the log message format.
3. Enable Enable Remote Logging under Remote Logging Options.
4. For Source Address, choose an interface or network that can reach the collector. Set IP Protocol to IPv4.
5. Enter the actual collector IP under Remote log servers and select Firewall Events under Remote Syslog Contents.
6. Save, generate an approved firewall event that is actually logged, and verify it as netflow in the correct Sophos tenant. Its action and connection details must match the source log.

Changing Source Address can affect routing and firewall matching. If data is missing, first check that interface’s outgoing path, then the receiver and BSD format. This procedure does not automatically cover other log categories.

Netskope SSE: Cloud Log Shipper and CEF

This path has two stages: Netskope Cloud Log Shipper retrieves data through the Netskope APIs and forwards it as CEF over syslog to the Sophos collector. Entering a Netskope account directly on the collector does not replace the Log Shipper.

The integration can provide web/cloud activity, malware findings, security and policy alerts, and administrative activity, mapped to schemas including http, antivirus, thirdpartyalert, nids and auth. Additional netflow connection and tunnel events are subject to the SIEM requirement.

1. Deploy an approved Cloud Log Shipper for your Netskope tenant. Configure API access and intended categories according to the matching Netskope procedure. The Sophos guide does not define one universal API permission set.
2. In the Shipper, select output Plugin: Syslog.
3. Use Syslog Defaults Mapping for Mapping. Preserve the documented CEF path; freely modified mapping can change normalization.
4. Set the actual Sophos XDR Data Collector IP as the destination. Transport and receiver must match the approved Shipper/collector configuration; other products’ UDP/514 requirements do not establish a universal Netskope port.
5. Select a suitable source event and confirm that the Shipper retrieved it from the API and forwarded it. Compare the expected schema and required fields in Sophos afterwards.

If only connection data is missing, also check event selection and SIEM entitlement. An HTTP record does not prove ingestion of every Netskope category. Investigate API retrieval and syslog forwarding problems separately.

NetScaler ADC: audit logs with unambiguous timestamps

NetScaler ADC, formerly Citrix ADC, supplies syslog including web/Application Firewall events (http), authentication and VPN sessions (auth), and administrative commands (managementevent). TCP connection setup and teardown map to netflow and require SIEM.

1. After deploying the collector, open the NetScaler syslog Audit Logging configuration. Configure server/policy assignment for the installed NetScaler version and intended scope; the Sophos source does not document a universal CLI command.
2. Set the correct Sophos XDR Data Collector IP as the syslog destination and verify the approved network path.
3. Set the date format to MM/DD/YYYY. DD/MM/YYYY is not supported for correct ingestion.
4. Send event timestamps in UTC. Changing the Sophos display afterwards does not repair a misinterpreted source timestamp.
5. Generate an approved administrative change or login within the intended audit scope. Compare source evidence, time, user and action with the corresponding Sophos schema. Desired netflow ingestion needs its own connection test.

For apparently missing events, compare source time and search window first. An incorrect date or time zone can place a record outside the expected range. Then check audit policy, the category actually sent, collector IP and network connectivity.

Acceptance and controlled removal

For each source, record at least one reproducible event, source, tenant, ingestion time and normalized schema. Compare addresses, ports, action and user where expected and available. No detection or case does not necessarily mean no ingestion; the actual record is decisive.

Repeat acceptance after source or format changes. A receiver that parsed valid CEF yesterday proves nothing about today’s altered mapping. For time discrepancies, check the source clock rather than disabling protection.

To remove the setup, stop the newly configured remote-logging entry or dedicated Shipper output, then check the previously documented logging path. Preserve shared collectors, API identities and other Shipper outputs. Remove exclusively dedicated resources only after checking remaining dependencies. Deleting an integration does not establish deletion of historical telemetry or restore lost events.