Skip to content
Notifications
Clear all

Has anyone tried integrating FortiSASE logs directly into Splunk without a collector VM?

2 Posts
2 Users
0 Reactions
0 Views
(@hannahr2)
Eminent Member
Joined: 1 week ago
Posts: 19
Topic starter   [#21657]

Hello everyone! 👋 I've been deep in the weeds with FortiSASE for a few months now, primarily for securing our remote workforce, and I'm absolutely loving the granular visibility it provides. However, I've hit a bit of a snag with our analytics pipeline and I'm wondering if anyone has found a more elegant path forward.

Our current setup for other services is beautifully streamlined: logs flow directly from the source into Splunk Cloud, no intermediate hops. With FortiSASE, the documented path for detailed logging (think web filtering, application control, DNS) seems to require a FortiGate VM deployed as a collector, which then forwards to Splunk via a Universal Forwarder. This feels like an extra piece of infrastructure to manage, patch, and monitor just for log transport.

My core question is this: **Has anyone successfully configured FortiSASE to send its logs *directly* to a Splunk HTTP Event Collector (HEC) endpoint, bypassing the collector VM entirely?**

I’ve been scouring the admin guide and poking around the portal. I see options for syslog, but my understanding is that for the rich, structured data I need (especially for security analytics), the syslog output might be less detailed than the JSON logs a collector provides. I'm trying to avoid a scenario where we lose data fidelity for the sake of architectural simplicity.

I’d be incredibly grateful if anyone has explored this and could share their experience. Specifically:

* Is direct HEC integration supported natively in the FortiSASE portal, or is it a "supported" configuration that requires workarounds?
* If you’ve done it, what was the exact workflow? Was it a simple case of pointing a "Remote Logging" setting to the Splunk HEC URL and token?
* Did you encounter any major limitations in log volume, event types, or required parsing compared to the collector VM method?
* Any tips on the necessary log format (CEF, JSON) and the Splunk props/transforms configurations needed on the other end?

I’m a firm believer that every extra server in a pipeline is a potential point of failure, so eliminating that hop would align perfectly with my workflow optimization goals. If a direct integration isn't feasible, I'd also love to hear about how you've minimized the overhead of managing that collector VM.

Thank you in advance for sharing your wisdom—this community has been a lifesaver for so many of my automation projects!

—Hannah


Measure twice, automate once.


   
Quote
(@integration_maven)
Estimable Member
Joined: 4 months ago
Posts: 132
 

The syslog output you found is indeed the native mechanism, but you're right that its structure can be limiting for full analytics. I've worked around this by using a lightweight middleware script as a relay; it's not a direct HEC push from FortiSASE, but it eliminates the overhead of a full collector VM.

The approach uses the FortiSASE syslog-to-HTTPS forwarding capability, targeting a small container or serverless function (e.g., AWS Lambda, Azure Function) that parses and reformats the CEF-style syslog messages into JSON, then posts them directly to your Splunk HEC. This keeps the architecture serverless or containerized, avoiding VM management.

If you're comfortable with Python, I can share a basic transformer script that handles the CEF parsing and batch posting to HEC. The key caveat is you'll need to manage the HTTPS endpoint's security and scaling, but it's far less operational burden than a FortiGate VM.


IntegrationWizard


   
ReplyQuote