Skip to content

Firewall feeds

The firewall is the most valuable single source, because every routed packet in the network passes through it. Three feeds come from it, and they are independent: you can enable one without the others.

Everything below is passive. Suricata runs in IDS mode, the resolver just logs, and the flow exporter just exports. Nyxtrace never asks the firewall to block anything, and the free core has no path to do so.

This is a production device. The order matters more than the speed.

  1. Take a configuration backup and write down the exact rollback before each change.
  2. Change the standby node first, verify it, then wait before touching the active one.
  3. After each change verify the basics — cluster state, packet filter, interface state, DNS, management reachability, and one real cross-VLAN path — before continuing.

Configure the firewall’s flow exporter to send to the appliance, on its own UDP port per node.

Two rules that are easy to get wrong and expensive to get wrong:

Select interfaces explicitly. Export the interfaces whose traffic belongs to this tenant, and no others. Management interfaces do not belong in the export.

Register the exporter addresses. Each NetFlow sensor entry lists the canonical sampler addresses it expects:

sensors:
- sensor_id: sensor_example_netflow_a
tenant_id: example
token_env: NDR_SENSOR_EXAMPLE_NETFLOW_A_TOKEN
allowed_kinds: [netflow.flow]
trust: exporter
expected_exporters: [192.0.2.1]

A record whose sampler address does not match is kept as raw unparsed evidence and never becomes a flow observation. That is the check that stops a misconfigured or unexpected exporter from quietly writing into your data.

On the appliance side, the collector children are supervised by a gate that proves each child actually owns its configured UDP listener before reporting readiness, and that drops any flow whose source or destination matches the configured excluded prefixes before it ever reaches the transport.

Enable Suricata on the firewall in passive pcap IDS mode, on the interfaces you want covered. Do not enable IPS.

The EVE output is sent as JSON over syslog to the appliance on its own TCP port per node. Multiple EVE loggers are supported, but validate the rendered configuration on the standby node before doing the same on the active one — an include-merge that looks right in the GUI and wrong on disk is a known class of surprise.

Two operational notes:

  • Retain EVE files on the firewall. Nyxtrace keeps a bounded window of closed hourly EVE files plus the active hour, which is what makes a replay possible after an ingest misconfiguration. The retention job leaves malformed filenames, symlinks and unrelated logs alone, and reports any file dated in the future — that means the firewall’s clock is wrong, and enough of them will consume the reader’s headroom.
  • Watch the load. Suricata is the part of this that costs CPU. Observe 24 hours of CPU, load, packet loss, cluster state and disk growth on the active node before you call it done. A short canary with zero drops is encouraging; it is not the acceptance gate.

The recursive resolver’s query log is what turns 203.0.113.8 into a name. Send it over the same syslog transport as EVE.

Use a positive allowlist of the client networks whose queries should be ingested, rather than an exclusion list. On a firewall that also resolves for networks outside this tenant, an exclusion you forget to add is a leak; an allowlist you forget to extend is merely a gap you will notice.

If your firewall is a high-availability pair, each node is its own sensor:

Node A Node B
NetFlow its own UDP port its own UDP port
EVE + resolver its own TCP port its own TCP port
Sensor registration its own its own
Token its own its own

The appliance accepts each listener only from that node’s address, and the bearer token remains the authority on identity. Keeping them separate preserves provenance: you can tell which node saw what, and a failover does not look like a data anomaly.