utmstack
Fortigate Logs over TCP arrive to agent but not to UTMStack
Acknowledgements
- [x] I have searched (https://github.com/utmstack/UTMStack/issues) for past instances of this issue
- [x] I have verified that my UTMStack version is up-to-date
Describe the bug
Fortigate version: 7.2.8 Fortigate Logs sent over TCP arrive to agent but not to UTMStack. The agent seems to not forward them to the master.
It works over UDP but not TCP
Regression Issue
- [ ] Select this option if this issue appears to be a regression.
Expected Behavior
Logs arrive to the master on TCP. It works over UDP but not TCP
Current Behavior
Logs stop at the agent but are not sent to the master server
Reproduction Steps
integrate a fortigate syslog with Reliable integration (not the legacy) and send logs to a windows or linux agent.
Possible Solution
No response
Additional Information/Context
No response
UTMStack Version
10.7
Operating System and version
Ubuntu
Hypervisor and Version | Server Vendor and Model
VMWare
Browser and version
Chrome
Hi Anwesh!
We’d love for you to contribute in any way that suits you-whether it’s improving documentation, participating in discussions, or helping with coding. Just be sure to review our contribution guidelines and community code of conduct. Thank you for being part of our community!
Hi everyone,
Just a quick note from a UTMStack user in case anyone else runs into the same problem with FortiGate or other TCP-based syslog sources.
We encountered an issue with FortiGate logs sent over TCP (“reliable” syslog). FortiGate uses RFC 6587 octet-counting/framing, which the current UTMStack agent doesn’t support yet. At the moment, the agent only handles line feed (\n) terminated syslog messages.
In our case, any TCP syslog message without a trailing line feed wasn’t being parsed or ingested. This affects FortiGate and potentially other devices that use the same framing method.
A big thanks to the UTMStack team for confirming the issue and working on a patch, much appreciated!
