Custom UDP Logs with customized pipeline parser configuration troubles

[Fudozzo]

Version

2.4.200

Installation Method

Security Onion ISO image

Description

configuration

Installation Type

Standalone

Location

on-prem with Internet access

Hardware Specs

Does not meet minimum requirements

CPU

4

RAM

8

Storage for /

200

Storage for /nsm

0

Network Traffic Collection

other (please provide detail below)

Network Traffic Speeds

Less than 1Gbps

Status

Yes, all services on all nodes are running OK

Salt Status

No, there are no failures

Logs

No, there are no additional clues

Detail

Good afternoon everyone , i'm having troubles configuring a Custom UDP Logs integration to be applied to syslog messages sent to my Security Onion installation.
The installation at the moment is low on ram because we got no traffic collection and it's still a test machine.
In my network i have multiple vendor devices so i was planning to use a custom log pipeline to parse different messages.
I've created my pipelines like this, the parser parts are like a dummy for now:

# 124: GET _ingest/pipeline/1001_preprocess_switches 200 OK
{
  "1001_preprocess_switches": {
    "description": "Route syslog from switches by IP using enrich inventory",
    "processors": [
      {
        "set": {
          "field": "debug.pipeline",
          "value": "1001_preprocess_switches"
        }
      },
      {
        "enrich": {
          "policy_name": "switch_inventory",
          "field": "host",
          "target_field": "device",
          "ignore_missing": true
        }
      },
      {
        "pipeline": {
          "name": "1002_switch_Huawei_parse",
          "tag": "pipeline_call_huawei",
          "if": "ctx.device != null && ctx.device.vendor != null && ctx.device.vendor == 'Huawei'"
        }
      },
      {
        "pipeline": {
          "name": "1002_switch_Cisco_parse",
          "tag": "pipeline_call_cisco",
          "if": "ctx.device != null && ctx.device.vendor != null && ctx.device.vendor == 'Cisco'"
        }
      }
    ],
    "on_failure": [
      {
        "set": {
          "field": "event.kind",
          "value": "pipeline_error"
        }
      },
      {
        "append": {
          "field": "error.message",
          "value": "Failed in {{ _ingest.on_failure_pipeline }}: {{ _ingest.on_failure_processor_type }} ({{ _ingest.on_failure_processor_tag }})"
        }
      }
    ]
  }
}
# 125: GET _ingest/pipeline/1002_switch_Cisco_parse 200 OK
{
  "1002_switch_Cisco_parse": {
    "description": "Dummy Cisco switch parsing pipeline",
    "processors": [
      {
        "set": {
          "field": "parsed_vendor",
          "value": "Cisco"
        }
      },
      {
        "set": {
          "field": "parsed_model",
          "value": "{{device.model}}"
        }
      },
      {
        "set": {
          "field": "parsed_hostname",
          "value": "{{device.hostname}}"
        }
      }
    ]
  }
}
# 126: GET _ingest/pipeline/1002_switch_Huawei_parse 200 OK
{
  "1002_switch_Huawei_parse": {
    "description": "Dummy Huawei switch parsing pipeline",
    "processors": [
      {
        "set": {
          "field": "parsed_vendor",
          "value": "Huawei"
        }
      },
      {
        "set": {
          "field": "parsed_model",
          "value": "{{device.model}}"
        }
      },
      {
        "set": {
          "field": "parsed_hostname",
          "value": "{{device.hostname}}"
        }
      }
    ]
  }
}

My switch inventory is:

{
  "took": 1,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 2,
      "relation": "eq"
    },
    "max_score": 1,
    "hits": [
      {
        "_index": "switch_inventory",
        "_id": "ESPUA5wBLSbL5ojreKSW",
        "_score": 1,
        "_source": {
          "host": "172.21.1.1",
          "vendor": "Huawei",
          "model": "ABC",
          "hostname": "Switch-1"
        }
      },
      {
        "_index": "switch_inventory",
        "_id": "EiPUA5wBLSbL5ojreKTL",
        "_score": 1,
        "_source": {
          "host": "172.21.1.2",
          "vendor": "Cisco",
          "model": "DEF",
          "hostname": "Switch-2"
        }
      }
    ]
  }
}

Using the pipeline simulate works and gives me the right output (i suppose):

{
  "docs": [
    {
      "doc": {
        "_index": "_index",
        "_version": "-3",
        "_id": "_id",
        "_source": {
          "debug": {
            "pipeline": "1001_preprocess_switches"
          },
          "parsed_model": "ABC",
          "host": "172.21.1.1",
          "message": "<134>Jan 28 12:34:56 Huawei test message",
          "device": {
            "host": "172.21.1.1",
            "hostname": "Switch-1",
            "model": "ABC",
            "vendor": "Huawei"
          },
          "parsed_vendor": "Huawei",
          "parsed_hostname": "Switch-1"
        },
        "_ingest": {
          "timestamp": "2026-01-28T15:20:24.099475833Z"
        }
      }
    }
  ]
}

Now, i added a new integration to a different port to avoid to break the original one:

After that i was expecting, or atleast hoping to see some logs appear somewhere, i admit to be ignorant about this argument and to be honest i don't know where to look, i tried the logs but without luck. Maybe the problem is linked to the dummy part, but without knowing what to search i'm lost.
I've checked with tcpdump and the messages arrives to my UDP 515 port.
I've added a couple of tags to see if it could help in the query search.
Any help to troubleshoot this is welcome.

Thank you in advance.

Alessandro.

Guidelines

• I have read the discussion guidelines at Read before posting! #1720 and assert that I have followed the guidelines.

[cm-ops]

Is there anything in the logstash.log or Elasticsearch logs that would indicate an issue with the pipelines?

[Fudozzo]

Good morning.
I've checked the logs at with tail:

/opt/so/log/logstash/logstash.log
/opt/so/log/elasticsearch/securityonion.log

then started TCPDUMP and i entered a wrong login in my device:
tcpdump output

listening on ens192, link-type EN10MB (Ethernet), snapshot length 262144 bytes
09:44:08.364736 IP 172.16.1.1.38514 > srv-securityonion: UDP, length 417
E.../.....6.......
8.r......<189>Jan 30 2026 09:45:56 Switch-L3 %%01CM/5/ADMIN_USER_ACCESSRESULT(s):Service=nasm0;USER_INFO_AUTHENTICATION. (DEVICEMAC:AA-AA-AA-AA-AA-AA;DEVICENAME:Switch-L3;USER:dasda;MAC:-;IPADDRESS:XXX.XXX.XXX.XXX;TIME:2026-01-30 10:45:56;ZONE:UTC+01:00;DAYLIGHT:false;ERRCODE:133;RESULT:Authentication fail;CIB ID:121;ACCESS TYPE:HTTP;RDSIP:-;Portal TYPE:-;VPNNAME:_public_;AUTHID:4294967295;AuthFailType:HTTP;AUTHPROTOCOL:PAP;)
09:4
<img width="1512" height="154" alt="Screenshot 2026-01-30 110707" src="https://github.com/user-attachments/assets/0f652666-eb14-4349-8a45-5bce846ef9ae" />
4:08.485033 IP 172.16.1.1.38514 > srv-securityonion: UDP, length 193
E.../.....7.......
8.r......<189>Jan 30 2026 09:45:56 Switch-L3 %%01WEBM/5/LOGINFAIL(s):Service=psspd_frame0;User failed to login. (User Name=YYYY, IP Address=XXX.XXX.XXX.XXX, Failed Reason=Incorrect username or password)

but the log files are silent.
I've done a little more digging via command line, with ss and ps trying to detemine the exact process that opens the ports, and it points me to this

/opt/Elastic/Agent/data/elastic-agent-8.18.8-bb58d0/components/agentbeat filebeat
---- Omitted ----

So i went to peek this file

/opt/Elastic/Agent/data/elastic-agent-8.18.8-bb58d0/logs/elastic-agent-20260130-1.ndjson

But i got no feedback in this to after a message arrive.

Thank you again.

Alessandro.

[cm-ops]

Did you also create the host firewall allowance for port 515? https://docs.securityonion.net/en/2.4/firewall.html#creating-a-custom-host-group-with-a-custom-port-group

[Fudozzo]

Good Morning, yes I've added it, to be sure, i've enabled the TCP integration too, and i can open the socket via telnet.

Alessandro.

[cm-ops]

You can check to see if the pipeline is loaded with sudo so-elasticsearch-pipelines-list | grep 1001_preprocess_switches And the pipeline stats with sudo so-elasticsearch-pipeline-stats 1001_preprocess_switches

Do you see it loaded and do you see events in the pipeline?

[Fudozzo]

Good morning and thank you for the feedback.
sudo so-elasticsearch-pipelines-list | grep 1001_preprocess_switches returns:
"1001_preprocess_switches",
and sudo so-elasticsearch-pipeline-stats 1001_preprocess_switches:

{
  "count": 544,
  "time_in_millis": 98,
  "current": 0,
  "failed": 0,
  "ingested_as_first_pipeline_in_bytes": 1413951,
  "produced_as_first_pipeline_in_bytes": 1481407,
  "processors": [
    {
      "set": {
        "type": "set",
        "stats": {
          "count": 544,
          "time_in_millis": 1,
          "current": 0,
          "failed": 0
        }
      }
    },
    {
      "enrich": {
        "type": "enrich",
        "stats": {
          "count": 544,
          "time_in_millis": 90,
          "current": 0,
          "failed": 0
        }
      }
    },
    {
      "pipeline:1002_switch_Huawei_parse:pipeline_call_huawei": {
        "type": "pipeline",
        "stats": {
          "count": 0,
          "time_in_millis": 0,
          "current": 0,
          "failed": 0
        }
      }
    },
    {
      "pipeline:1002_switch_Cisco_parse:pipeline_call_cisco": {
        "type": "pipeline",
        "stats": {
          "count": 0,
          "time_in_millis": 0,
          "current": 0,
          "failed": 0
        }
      }
    }
  ]
}

And now i think I've see the issue, after some tries I've noticed that the count part goes up in the 1001 pipeline, but it's always 0 in the 1002 ones, so i suppose there's something wrong between them. I've checked if there was any error.message to exclude pipeline failures on 1001, but there's none. Is there any way i can check whats happening after the enrich phase?
At this point i think it's quite sure that the problem are the ifs not matching anything.

Thank you.

Alessandro.

[Fudozzo]

I solved the problem, adding some debugging lines here and there helped me to find the real culprit.
The messages sent to the Syslog component of Security Onion, are parsed as they were sent from the machine itself, so the host.ip was like this:

"host.ip": [
    "172.16.X.X", <- Security Onion IPv4
    "fe80::250:------------", <- Security Onion IPv6
    "172.17.0.1", <- Security Onion docker network
    "192.168.232.1" <- Security Onion sobridge
  ]

The switch ip never appears in the host.ip list, but it appears as:

 "log.source.address": [
    "172.16.1.1:38514"
  ],

Changing the enrich phase on this field removing the port part solved the problem.
Without your help i would not be able to debug the issue.

Thank you.

Alessandro.