Log Forwarding

Send what the console records to the system where you keep everything else.

See what happened1 min readApplies to the Fowlguard console

What gets forwarded

Both logs, and they answer different questions. Access events are who connected to what, and what was blocked. Audit events are who changed a setting, what they changed it from, and when. Forwarding one without the other leaves a gap that is usually noticed during an incident.

Setting it up

  1. Give the destination: host, port and protocol.
  2. Choose the format your collector expects.
  3. Save. Events start flowing from that point on; forwarding is not retrospective, and the console keeps its own copy either way.

If the collector is unreachable

Nothing in the product stops working. Forwarding is a copy, not the record: the console remains the system of record, so an unreachable SIEM costs you the stream, not the history. Check the destination if events stop arriving, then look at the logs in the console to confirm they are still being written.

What to check first

Most failures are the same three things: a port that is closed between the two, a collector expecting a different format, and a destination that resolves internally but not from where the console runs.

The fields

Collector host is the hostname or IP of your syslog receiver.

Transport. UDP loses events silently under load, which is the worst failure mode a log feed has: nothing reports an error and the gap only appears when you go looking for an event that should be there. Use TLS for anything off-site.

Format. CEF ingests into Splunk and Sentinel without a custom parser.

Something missing or unclear? Write to hello@fowlguard.com and we will add it.