Suricata

Replaying a single connection (TCP connection tunneled inside a Geneve UDP) produces two flow log entries, one for the inner flow and one for the parent, but the flow log does not indicate the relationship between the two. For forensic investigations of log data it would be very useful to link the two so that the tunnel relationship is preserved in the flow logs. Zeek preserves this relationship in the logs it produces via its tunnel_parents field, which indicates the parent tunnel's flow ID, and it would be very useful if Suricata did something similar.

Here are two related flow log entries produced by my test:

{
  "timestamp": "2025-09-11T23:33:14.375735+0000",
  "flow_id": 769347704832952,
  "event_type": "flow",
  "src_ip": "10.0.1.43",
  "src_port": 56382,
  "dest_ip": "18.246.151.77",
  "dest_port": 443,
  "proto": "TCP",
  "flow": {
    "pkts_toserver": 12,
    "pkts_toclient": 9,
    "bytes_toserver": 638,
    "bytes_toclient": 506,
    "start": "2025-09-11T23:33:14.375735+0000",
    "end": "2025-09-11T23:33:20.437882+0000",
    "age": 6,
    "state": "established",
    "reason": "shutdown",
    "alerted": false
  },
  "tcp": {
    "tcp_flags": "1b",
    "tcp_flags_ts": "1a",
    "tcp_flags_tc": "1b",
    "syn": true,
    "fin": true,
    "psh": true,
    "ack": true,
    "state": "fin_wait2",
    "tc_gap": true,
    "ts_gap": true,
    "ts_max_regions": 1,
    "tc_max_regions": 1
  }
}
{
  "timestamp": "2025-09-11T23:33:14.375735+0000",
  "flow_id": 769348528774311,
  "event_type": "flow",
  "src_ip": "10.0.10.251",
  "src_port": 60475,
  "dest_ip": "10.0.12.58",
  "dest_port": 6081,
  "proto": "UDP",
  "app_proto": "failed",
  "flow": {
    "pkts_toserver": 21,
    "pkts_toclient": 0,
    "bytes_toserver": 2866,
    "bytes_toclient": 0,
    "start": "2025-09-11T23:33:14.375735+0000",
    "end": "2025-09-11T23:33:20.437882+0000",
    "age": 6,
    "state": "new",
    "reason": "shutdown",
    "alerted": false
  }
}

This might take the form of a tunnel_parent: 769348528774311 on the inner flow's record, or something similar.

It is somewhat similar to the "tunnel" object supported in alert logs, but including this data in the flow log and using the flow_id as the identifier makes it much easier for tooling to be able to always associate the correct related flows.