syslog Archives - Wavecrest Knowledge Base

Is Cyfin Receiving Syslog from Your Firewall or Proxy? A Troubleshooting Guide

If you’ve configured a firewall, proxy, or gateway — a SonicWall, Palo Alto, Checkpoint, WatchGuard, Cisco Firepower, Zscaler, or similar device — to send syslog to Cyfin, but your reports are empty, a device isn’t showing up, or the traffic you expect isn’t appearing, this guide will help you pin down where the problem is.

Almost every “Cyfin isn’t showing my firewall data” issue comes down to one question:

Is the syslog data actually reaching Cyfin?

That single question splits the problem into two very different situations, each with a different fix:

The data isn’t arriving. The stream isn’t reaching Cyfin at all. This is almost always something in how the sending device is configured to forward syslog, or something on the network path between it and Cyfin. We’ll show you how to confirm this and what to check.
The data is arriving, but Cyfin isn’t turning it into reports. The stream is reaching Cyfin, but Cyfin either doesn’t have a parser for that device’s log format, or the format isn’t quite what the parser expects. This is the case where we can help you directly — often quickly.

Work through the guide in order. The first job is simply to find out which of those two situations you’re in.

What Cyfin can parse

Cyfin reads log data from many firewall, proxy, and gateway devices, but it reads a specific set of log formats. When a device sends syslog in a format Cyfin recognizes, Cyfin parses it into users, sites, and categories automatically. When it sends a format Cyfin doesn’t yet recognize, the data can arrive perfectly and still produce nothing — because Cyfin doesn’t know how to read it.

Devices and formats Cyfin parses out of the box:

Palo Alto Network

Check Point

Cisco Firewall

Cisco Firepower

FortiGate

SonicWall

WatchGuard

Zscaler

If your device isn’t on that list, that doesn’t necessarily mean Cyfin can’t read it — it means we may need to add or adjust a parser for your specific format. See “The data is arriving, but nothing shows up” below; that’s a fast turnaround when we have a sample of your log.

Step 1: Confirm whether Cyfin is receiving the syslog

You can check this yourself, directly in Cyfin — no command-line or server access required. This works the same whether Cyfin is running in a VM on your own network or hosted in the cloud, so you don’t need to touch the underlying machine either way.

In Cyfin, go to:

System Status → Syslog → Syslog Status

This screen shows statistics on the syslog Cyfin is receiving, along with a live sampling of the incoming data. It’s the definitive, self-service answer to “is anything arriving?”:

You see stats climbing and sample data on the screen → syslog is reaching Cyfin. The problem, if any, is on the parsing side. Skip to “The data is arriving, but nothing shows up.” (Keep this screen open — the sample it shows is exactly what support will need, so it’s worth capturing now.)
The screen shows no activity — no stats, no sample — while the device should be sending → the data is not reaching Cyfin. Continue to Step 2.

Note for Cloud Cyfin customers: your instance is administered by Wavecrest, but you still confirm receipt yourself through this same Syslog Status screen. If the screen shows nothing and the send side checks out, Wavecrest can additionally verify at the network level on the hosted server — see Step 2.

Step 2: The data isn’t arriving — get the stream flowing

If nothing is reaching the server, the syslog isn’t leaving the sending device, isn’t addressed correctly, or is being stopped on the network in between. The exact steps to configure forwarding live in your device’s own admin interface — and because every vendor’s interface is different, those specific screens are outside what we can document for you. But the requirements the device has to meet are the same for every vendor, and you can verify each one:

1. Destination address. The device must be sending to the IP address (or hostname) of the Cyfin server. Confirm it’s pointed at the right host — not an old address, not a load balancer or gateway that drops it.

2. Port and protocol. The device must send on the port and protocol Cyfin is listening on (typically UDP/514 — but confirm against the value above). A mismatch here is one of the most common causes: the device sends on UDP/514, Cyfin listens on something else, and nothing lands.

3. A clear network path. Nothing between the device and Cyfin can be dropping the traffic. The usual culprits:

A firewall rule (often on the sending device itself, or a firewall in between) blocking outbound/inbound syslog on that port.
NAT or routing that prevents the packets from reaching the server.
The device and server being on segments that can’t reach each other.

How to localize the break: you own both ends you can actually see — the Syslog Status screen tells you nothing is arriving at Cyfin, and your sending device’s own logs or status page tell you whether it’s actually transmitting. If the device shows it’s sending but Cyfin’s Syslog Status stays empty, the packets are being lost on the network in between (firewall, NAT, or routing) — that’s the path to work through. If the device isn’t showing outbound syslog activity at all, the forwarding config on the device isn’t active yet, and that’s where to focus. For Cloud Cyfin, if you’ve confirmed the device is sending but nothing arrives, Wavecrest can capture at the network level on the hosted server to confirm definitively whether packets are reaching it.

We know that even though the sending device’s configuration is on your side of the fence, you’re looking to us to help you get this working — and we will. If you’ve verified the destination, port, and path and syslog still isn’t arriving, contact support (below) and we’ll help you work through it. What we can’t do is write the click-by-click steps for your specific vendor’s admin UI; for that, your device vendor’s syslog-forwarding documentation is the authority.means the network/firewall is eating them; not leaving the device at all means the forwarding config on the device isn’t active.

Step 3: The data is arriving, but nothing shows up

If the Syslog Status screen shows data arriving but Cyfin still produces no reports — or the data looks wrong, miscategorized, or partial — the issue is on the parsing side: Cyfin is receiving the stream but doesn’t have a parser that matches your device’s exact log format.

This is the case we can usually turn around quickly — as long as we can get a sample of your actual log. With a real sample in hand, adding or adjusting a parser for your format is fast, straightforward work. Without one, we’re guessing at a format we can’t see.

To get this resolved quickly, contact support and include:

The device sending the logs — make and model (e.g. “SonicWall TZ470”, “Palo Alto PA-440”).
A sample of the raw syslog — a handful of representative lines exactly as they arrive. The easiest place to get this is the System Status → Syslog → Syslog Status screen, which shows a live sampling of the incoming data; copy or screenshot those lines so we see the real bytes Cyfin is receiving, not a reformatted copy.
What you expected to see in Cyfin versus what you’re actually getting (nothing at all, wrong users, wrong categories, etc.).

That sample is the one thing that turns “my device doesn’t work with Cyfin” into “here’s the format, we’ll add the parser.” The faster we have it, the faster this closes.device doesn’t work with Cyfin” into “here’s the format, we’ll add the parser.” The faster we have it, the faster this closes.

Quick reference: which situation am I in?

What the Syslog Status screen shows	Where the problem is	What to do
No activity — no stats, no sample	Sending device config or network path	Step 2 — verify destination, port/protocol, and path; contact support if still stuck
Data arriving, but no reports in Cyfin	Parser / log format	Step 3 — send support a raw log sample
Data arriving, but reports look wrong	Parser needs adjustment	Step 3 — send support a raw log sample + what’s wrong
Haven’t checked yet	Unknown — check first	Step 1 — open System Status → Syslog → Syslog Status

Contact

For help confirming whether Cyfin is receiving your syslog, or to have us add or adjust a parser for your device, contact Wavecrest support:

[VERIFY — insert the canonical support contact (support email + technical support phone/extension). Per current routing: technical/syslog/parser issues go to SUPPORT, not sales. Sales — sales@wavecrest.net, 321-953-5351 — handles only licensing, renewals, and purchasing.]

When you contact us about syslog that’s arriving but not parsing, include the device make/model and a raw log sample — that’s what lets us turn it around fast.

Cyfin — Why Are User IDs Missing From My Reports?

Applies to: Cyfin · When reports show no usernames (blank or IP addresses instead of people).

Cyfin reports on whatever is contained in the log or syslog data it ingests from your firewall or proxy. User IDs are what let Cyfin attribute web activity to specific people. If your reports show activity by IP address or blank instead of by username, the User ID is missing from the data Cyfin is receiving — and it’s almost always one of the two causes below.

(This is different from activity that appears under Ungrouped IDs — that means IDs are being captured but haven’t been organized into your Groups and IDs tree. See the Terms Glossary for Ungrouped IDs. This article is about IDs not being captured at all.)

Cause 1 — Your firewall or proxy isn’t capturing the User ID

This is the most common cause, and the key fact to understand:

The User ID is not a default field in any firewall or proxy log. A firewall or proxy only records who made a request if authentication is enabled on that device. By default, most devices log the connection (IP, URL, time, bytes) but not the authenticated username. If authentication isn’t turned on, there is simply no User ID in the log for Cyfin to report on — this is a configuration on the device, not something Cyfin can add after the fact.

The fix: enable user authentication on the firewall or proxy that generates your logs, so the authenticated User ID is written into the log/syslog. Once the device is capturing usernames, they flow into Cyfin and appear in reports.

How to do it depends on your device. Every firewall and proxy vendor has its own process and terminology for this — it may be called user authentication, user identification, User-ID, identity awareness, or similar. Consult your device’s documentation (or its vendor support) for how to enable authenticated user logging. Common examples include Palo Alto (User-ID), SonicWall, Fortinet (FSSO), and Check Point (Identity Awareness), among others.

How to confirm it’s a device issue: look at the raw log or syslog Cyfin is ingesting. If there’s no populated username field in the records themselves, the gap is on the device side — enabling authentication there is the fix.

Cause 2 — Authentication is enabled and IDs are in the log, but not in reports

If your firewall/proxy authentication is already on and you can see usernames in the raw log/syslog, but those usernames still aren’t showing up in Cyfin reports, the issue is on the parsing side: the log/syslog format or fields may have changed, so Cyfin’s parser no longer maps the User ID field correctly.

The fix: contact Wavecrest Technical Support (support@wavecrest.net). Let them know authentication is enabled and usernames are present in the raw log but not appearing in reports. The log fields may have changed and Cyfin’s parser / data configuration may need to be updated to read the User ID from the current log format.

Quick summary

Reports show IPs/blank, and the raw log has no username → enable authentication on your firewall/proxy (Cause 1). The User ID is never a default log field.
Reports show IPs/blank, but the raw log does have usernames → contact Wavecrest Support; the parser may need updating (Cause 2).
Reports show usernames but they’re all under Ungrouped IDs → that’s a grouping issue, not a capture issue; build or sync your Groups and IDs tree (see the Terms Glossary).

How to configure syslog on FortiGate

Below are the steps that can be followed to configure the syslog server:

From the GUI:

Log into the FortiGate.
Select Log & Report to expand the menu.
Select Log Settings.
Toggle Send Logs to Syslog to Enabled.
Enter the Syslog Collector IP address.
Select Apply.

If it is necessary to customize the port or protocol or set the Syslog from the CLI below are the commands:

config log syslogd setting 
    set status enable
    set server "192.168.1.19"
    set mode udp
    set port 514 
end

To establish the connection to the Syslog Server using a specific Source IP Address, use the below CLI configuration:

config log syslogd setting
    set status enable
    set server "192.168.1.19"
    set source-ip "192.168.1.1"
    set mode udp
    set port 514
end

The source ‘192.168.1.1’ can be any IP address of the FortiGate’s interface that can reach the syslog server IP of ‘192.168.1.19’ in the above example.

The ping and ping-options command from the CLI can be used to check basic connectivity to the Syslog server from a specific source IP.

exec ping-options source 192.168.1.1
exec ping 192.168.1.19
PING 192.168.1.19 (192.168.1.19): 56 data bytes
64 bytes from 192.168.1.19: icmp_seq=0 ttl=255 time=0.2 ms
64 bytes from 192.168.1.19: icmp_seq=1 ttl=255 time=0.1 ms
64 bytes from 192.168.1.19: icmp_seq=2 ttl=255 time=0.1 ms
64 bytes from 192.168.1.19: icmp_seq=3 ttl=255 time=0.1 ms
64 bytes from 192.168.1.19: icmp_seq=4 ttl=255 time=0.1 ms

--- 192.168.1.19 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0.1/0.1/0.2 ms