Skip to content

Ingesting Syslog from Network Appliances

This guide covers firewalls, switches, routers, VPN concentrators, and other network appliances that emit syslog. These devices are usually the largest single log source in an estate, and they are also the least flexible about how they send data: most can only forward plain syslog to an IP address and port, over UDP or TCP.

The SenseOn managed collector used in Receive mode accepts HTTPS POST with a JSON body, at a hostname. Most appliances cannot do that. They cannot resolve a hostname, wrap the payload in JSON, or negotiate TLS. The answer is Relay mode: run a collector inside your own estate that listens for syslog on an IP address and port, converts each message to JSON, and forwards it to SenseOn over HTTPS.

When you need this guide

Use a relay collector when any of the following is true of your log source:

  • It can only send to an IP address and port, not a hostname or URL.
  • It sends plain syslog rather than JSON.
  • It cannot act as an HTTPS client, or cannot present the certificates required.
  • You want to filter or reduce the volume before it leaves your network.

If your source can already POST JSON over HTTPS, you do not need this guide. Use Receive mode instead, which needs no infrastructure from you.

How it works

Firewalls, switches, VPN concentrators
        -> syslog over UDP or TCP, to an IP and port
        -> relay collector in your estate (Fluent Bit)
             parses syslog, adds a source label, converts to JSON
        -> HTTPS POST, port 443
        -> https://<code-name>-collector.snson.net

The relay is the only component that needs to reach the Internet. The appliances only need to reach the relay, which is usually already permitted inside a management network.

Prerequisites

  • A Linux host inside your estate to act as the relay. It needs a static IP address reachable from your appliances, and outbound HTTPS on port 443 to your collector endpoint.
  • Fluent Bit installed on that host. The installation steps are in Configuration Examples.
  • Your collector endpoint, in the form <code-name>-collector.snson.net, provided by SenseOn.
  • Administrative access to each appliance to change its logging destination.

💡 Note: An existing SenseOn network probe can be configured as a log forwarder instead of a separate host. If you already have a probe deployed where your appliances can reach it, contact support@senseon.io before building a new relay.

Step 1: Choose the listener protocol and port

Decide these before you configure anything, because the appliance and the relay have to agree.

Choice Guidance
UDP or TCP Use TCP where the appliance supports it, as it will not silently drop messages under load. Many older appliances only offer UDP.
Port Ports below 1024 require root privileges or the CAP_NET_BIND_SERVICE capability. Prefer a high port such as 5140. Use a different port per source type if you want to label them separately.
Format Most appliances send RFC 3164, sometimes described as BSD syslog. Newer ones can send RFC 5424. Check which your appliance emits, as this determines the parser.

Step 2: Configure the relay to listen for syslog

Fluent Bit's syslog input plugin listens on a socket rather than reading a file. The following configuration listens for RFC 3164 syslog over UDP on port 5140 and forwards everything to SenseOn.

[SERVICE]
    Flush         5
    Daemon        Off
    Log_Level     info
    Parsers_File  parsers.conf

[INPUT]
    Name              syslog
    Mode              udp
    Listen            0.0.0.0
    Port              5140
    Parser            syslog-rfc3164
    Tag               appliance.firewall
    Buffer_Chunk_Size 32k
    Buffer_Max_Size   1M

[FILTER]
    Name    record_modifier
    Match   appliance.*
    Record  log_source firewall
    Record  collected_by senseon-relay-01

[OUTPUT]
    Name            http
    Match           *
    Host            <code-name>-collector.snson.net
    Port            443
    URI             /
    Format          json_lines
    json_date_key   false
    tls             On
    tls.verify      On
    Header          Content-Type application/json
    Retry_Limit     3
    net.keepalive   On

Replace <code-name> with the code name SenseOn gave you.

Points worth noting:

  • Listen 0.0.0.0 accepts messages on every interface. Restrict it to a specific address if the host has more than one interface.
  • Set Mode tcp for TCP, keeping the same Listen and Port settings. For RFC 5424 sources, change Parser to syslog-rfc5424.
  • The record_modifier filter is not optional in practice. Syslog from many devices arrives as one undifferentiated stream, and these added fields are how you tell sources apart later in Hunt Lab. Set log_source to something meaningful per source type.
  • Buffer_Chunk_Size and Buffer_Max_Size govern how much raw data the listener will hold before parsing. Raise Buffer_Max_Size if you see buffer overflow warnings in the Fluent Bit log.

Start the service and confirm it is listening:

sudo systemctl restart fluent-bit
sudo systemctl status fluent-bit
sudo ss -lntup | grep 5140

Step 3: Allow the traffic

  • On the relay host, permit inbound UDP or TCP on your chosen port from your appliance management addresses only.
  • On the network path, permit the appliances to reach the relay on that port.
  • Confirm the relay can still reach <code-name>-collector.snson.net on port 443 outbound.

Step 4: Point each appliance at the relay

The setting is named differently by each vendor, but you are always looking for the same four things: a remote syslog server address, a port, a protocol, and which facilities or severity levels to send. Look for a section called remote logging, syslog server, log forwarding, or log settings. Vendor documentation is authoritative for the menu path.

On appliances such as Fortinet, Palo Alto, Cisco, Meraki, Cato, WatchGuard, and SonicWall devices, set:

Setting Value
Server address The relay host's IP address
Port The port you chose in Step 1, for example 5140
Protocol UDP or TCP, matching the relay's Mode
Facility and severity Start with the defaults. Narrow the severity later if the volume is higher than you want.

Send from one appliance first and confirm it end to end before adding the rest.

Step 5: Verify the flow

Work outwards from the appliance.

Confirm messages are arriving at the relay. Watch the port directly:

sudo tcpdump -n -i any port 5140

You can also generate a test message from any Linux host that can reach the relay, which confirms the listener works independently of the appliance. Match the flag to the listener's Mode — -d sends UDP, -T sends TCP:

# For a UDP listener (Mode udp)
logger -n <relay-ip> -P 5140 -d "senseon relay connection test"

# For a TCP listener (Mode tcp)
logger -n <relay-ip> -P 5140 -T "senseon relay connection test"

Confirm the relay is forwarding. A successful POST is logged as HTTP status 201:

sudo journalctl -u fluent-bit -f

Look for lines resembling [output:http:http.0] <code-name>-collector.snson.net:443, HTTP status=201.

Confirm the data has landed in SenseOn. Query for the fields you added in Step 2, filtering on the log_source value you set.

Separating multiple sources

Once several appliance types report to one relay, you need to keep them apart. Two approaches, which combine well:

  • A listener per source type. Add another [INPUT] block on a different port with its own Tag, then a matching [FILTER] that sets a different log_source. This is the clearest option and lets you use different parsers per source.
  • One listener, labelled by host. Keep a single input and rely on the hostname that the syslog parser extracts from each message. This is less work, but depends on your appliances sending accurate hostnames.

Reliability and volume

  • UDP loses messages silently. There is no delivery guarantee and no back pressure, so a busy firewall can overrun the listener without either end reporting an error. Use TCP where the appliance supports it.
  • The relay is a single point of failure. If it is down, the messages are gone, because appliances do not retry. For high-value sources, run two relays and point the appliances at both where the appliance allows more than one destination.
  • Firewall logging is high volume. Filter at the relay rather than sending everything and paying to store it. Narrowing the severity on the appliance is the cheapest reduction available.
  • Watch the relay's disk and memory. Fluent Bit buffers in memory by default. If the connection to SenseOn is interrupted, that buffer is what protects you, and it is bounded.

For guidance on which pipeline each source should feed, see Architecture.

Troubleshooting

Symptom Likely cause What to check
Nothing in tcpdump on the relay The appliance is not sending, or traffic is being blocked Confirm the appliance's syslog destination and port. Check the firewall rules on the path and on the relay host.
Messages arrive but Fluent Bit logs parser errors The appliance is not sending the format your parser expects Capture a raw message and compare it against RFC 3164 and RFC 5424. Switch Parser accordingly.
Fluent Bit logs buffer overflow warnings The listener cannot keep up, or single messages exceed the chunk size Raise Buffer_Max_Size, and move to TCP if you are on UDP.
HTTP status 400 in the Fluent Bit log The payload is not valid JSON, or is the wrong shape Confirm Format json_lines is set. See the FAQ for the related json format error.
HTTP status 401 or 403 Wrong collector endpoint Confirm the code name in the Host setting matches the endpoint SenseOn gave you.
Nothing reaches SenseOn, no errors logged Fluent Bit is running but not matching your input Confirm the [OUTPUT] Match covers the input's Tag.

Need help?

Contact SenseOn support at support@senseon.io

When contacting support, include:

  • Your organisation name
  • Collector endpoint URL
  • The appliance make and model, and the syslog format it is configured to send
  • Your Fluent Bit configuration file
  • A sanitised example of a raw syslog message as the appliance sends it
  • Relevant lines from the Fluent Bit log

Additional Documentation