sonicwall 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.

No Usernames in SonicWall Reports? Here’s Why and How to Fix It

If your Cyfin reports and dashboards are only displaying IP addresses instead of usernames, it indicates that SonicWall is not authenticating users.

Why Are There No Usernames?

Cyfin relies on SonicWall to log usernames. When SonicWall does not authenticate users, only IP addresses are captured in the log data. As a result, Cyfin will show the IP address in place of a username.

How to Enable User Authentication in SonicWall

To report on actual usernames, user authentication must be enabled on your SonicWall firewall. Here’s how to ensure usernames are included in your logs:

Configure Authentication Settings – Go to Users | Settings in your SonicWall appliance and set up an authentication method. Typically, this will be one of the following:
- LDAP + Local Users
- Active Directory Single Sign-On (SSO) using the SonicWall SSO Agent.
Force User Authentication – After configuring authentication, you need to set access rules that require users to authenticate before traffic is allowed through the firewall. For detailed instructions, refer to the SonicWall Knowledge Base article How to Force User Authentication Prior to Allowing Traffic Through the Firewall.
Verify AD SSO is Working – If you’re using Active Directory Single Sign-On, ensure it’s functioning correctly by following the test steps outlined at the end of the SonicWall guide.

By enabling authentication on your SonicWall, Cyfin will be able to log and display usernames, providing more meaningful and detailed reports.

How to Verify SonicWall is Authenticating Users

You can confirm whether SonicWall is logging usernames (independently of Cyfin) by checking SonicWall’s built-in log monitor. Follow these steps:

Step 1: Ensure SonicWall is Logging Internet Usage Events

Go to Log | Settings and expand the Log | Syslog section.
Click the Configure button next to Syslog Website Accessed events.
Ensure that the option Display Events in Log Monitor is enabled and set the display interval to 0 seconds.

Step 2: Investigate Logs for User Authentication

Navigate to Investigate | Event Logs.
Filter the logs by:
- Priority = Inform
- Category = Log
- Source IP = (enter the IP address you want to check, such as your own for testing purposes).
  This will display all web traffic for that IP address.
Click the More Details button (three lines) next to any event to view additional details.

Step 3: Check the Username Field

In the event details, look for the Username field. If this field is blank, it means that the IP address in question is not being authenticated for web traffic.

Additional Support

If you need further help with authentication issues, it’s best to contact SonicWall support. When troubleshooting, show them the issue using the SonicWall log monitor as described above.

Once SonicWall is logging authenticated users, Cyfin Reporter will be able to match usernames with their corresponding Active Directory objects. This allows you to take advantage of features like reporting on Departments and Security Groups. For more information, see our article on SonicWall Reporting on Users, Departments, and AD Security Groups.

Learn More