Forwarding Fortinet Firewall Logs to Cribl Cloud via TLS Syslog

Bridging an out-of-band firewall into a cloud-native observability pipeline without touching the internal network.

Architecture Overview

+---------------------+                        +---------------------+                        +---------------------+
|                     |                         |                     |                         |                     |
|   Fortinet          |   Syslog over TLS       |   Cribl Cloud       |   Processed logs        |   Downstream        |
|   FortiGate         | ----------------------> |   Syslog TLS        | ----------------------> |   SIEM              |
|                     |      port 6514           |   Source            |                         |                     |
|   External network  |                         |                     |                         |   Destination       |
+---------------------+                        +---------------------+                        +---------------------+

Background

A Fortinet FortiGate firewall deployed outside of a standard network perimeter needed to ship its logs to our central observability stack. Because the device couldn’t reach the internal log aggregation infrastructure directly, it required a cloud-reachable endpoint that could accept syslog traffic over a secure, encrypted channel.

Cribl Stream on Cribl Cloud was the perfect fit. It exposes a publicly addressable Syslog source with TLS support, handles certificate management, and slots cleanly into existing pipeline routing.

Implementation

01 – Configure a Syslog TLS Source in Cribl Cloud

In Cribl Stream, a new Syslog source was created and TLS was enabled on it. Cribl Cloud allows you to activate Cribl-provided certificates – issued by Google Trust Services – directly from the source configuration without needing to provision your own PKI.

02 – Enable TLS on the Cribl Cloud source

Under the TLS settings for the source, the Cribl-provided certificate option was selected. This activates a Google Trust Services-issued certificate on the endpoint. Since GTS roots are included in virtually all modern trust stores, no manual certificate installation is needed on the sending device in most cases.

03 – Configure the Fortinet firewall via CLI

On the FortiGate, the syslog destination was configured using the CLI. The key settings are mode reliable (TCP instead of UDP), enc-algorithm high to enforce TLS encryption, and port 6514 – the standard syslog-over-TLS port used by the Cribl source.

04 – Verify certificate trust (if needed)

If the device does not already trust Google Trust Services roots, the intermediate and root certificates can be downloaded from pki.goog and imported into the firewall’s CA store. In this case the FortiGate trusted the GTS chain out of the box, so no manual import was necessary.

05 – Validate and route in Cribl

Once the firewall started forwarding logs, events were visible in Cribl’s live capture view. From there, pipeline routes were applied to parse, enrich, and forward the data to the appropriate downstream destination.

Fortinet CLI Configuration

The following commands are entered on the FortiGate to point it at the Cribl Cloud syslog endpoint. Replace YOUR_CRIBL_HOSTNAME_OR_IP with the hostname shown in your Cribl source configuration.

config log syslogd setting
    set status        enable
    set server        "YOUR_CRIBL_HOSTNAME_OR_IP"
    set port          6514          # standard syslog-over-TLS port
    set mode          reliable      # TCP (required for TLS)
    set format        default
    set enc-algorithm high          # enforces TLS encryption
end

Note: mode reliable switches the transport from UDP to TCP, which is required for TLS to function. Without this, enc-algorithm high has no effect.

Why This Approach Works Well

Cribl-provided certificates on Cribl Cloud remove the operational burden of self-signed CA management. Google Trust Services certs are trusted broadly enough that most network devices – including Fortinet firewalls – will validate the chain without any configuration changes on the client side. This makes it straightforward to onboard devices that sit outside the internal network without standing up a relay, a VPN tunnel, or a local syslog forwarder.

Outcomes