Journey Step 3 Visual Guide — Palo Alto Networks PAN-OS Syslog Configuration

Audience: your organization's firewall administrator, managing a Palo Alto Networks firewall (VM-Series or hardware) running PAN-OS 10.2, 11.1, or 11.2.

When you need this guide. You are on Step 3 of the 4-step collector setup you are running from /client/settings/data-sources in the JawaSec portal:

1. Prepare the collector machine — a small Linux host on your network.
2. Run the command on that machine — the portal detects this automatically.
3. Tell the firewall where to send its logs — this guide.
4. Tell us how it went and save — the intake form back in the portal.

Everything this guide needs, and where to get it:

Substitute your own values wherever the examples appear.

Wherever a screenshot involves something to click or verify, a red box marks it. Screenshots without a box show a state to compare against.

---

How it works

Your firewall sends its logs via syslog (TCP) to the Linux machine you provisioned in Step 1. That machine runs the Elastic Agent the Step-2 command installed, with the Palo Alto Networks (panw) integration; the agent forwards parsed events on to the JawaSec platform over an outbound HTTPS connection. Nothing on your network accepts inbound connections from the internet.

---

What you are about to configure

Getting logs out of a PAN-OS firewall takes four legs, in this order:

1. Server Profile — where logs go: the syslog server's address, port, transport, and format.
2. Log Forwarding Profile — what gets sent: which log types (Traffic, Threat) forward to that server.
3. Attach the Log Forwarding profile to every Security rule whose traffic you want to see, including your Deny rules.
4. Commit — nothing above reaches the firewall until this runs.

---

Before you start

Confirm the syslog port is free on the collector machine. The collector listens on that port itself once it is activated (see the note at the end of this guide about when that listener actually starts). If another service already holds the port — a pre-existing rsyslog or syslog-ng listener is the usual culprit — the collector cannot bind to it later and no data will ever arrive.

Run this on the collector machine:

sudo ss -lntup | grep 9001

Output from anything other than the collector process means a conflict. Stop or reconfigure that service before continuing.

Also confirm your firewall's time zone, at Device → Setup → Management → General Settings → Time Zone, before you configure anything — see the note below about why this matters.

You also need:

• A PAN-OS account that can edit Server Profiles, Log Forwarding profiles, and Security policy.
• Network reachability from the firewall to the collector on the syslog port (the connection itself will not succeed until Step 4 is complete — see below).
• A Threat Prevention license if you want Threat logs. Without it you still get Traffic logs; no amount of policy tuning substitutes for the license.

---

Part 1 — Create the Syslog Server Profile

1.1 Log in

1.2 Confirm you are on the right device

1.3 Open Server Profiles → Syslog

Select the Device tab in the top navigation bar. In the left-hand tree, expand Server Profiles and click Syslog.

With no profile yet, the list is empty. Click Add at the bottom.

1.4 Name the profile and add a server row

In the Syslog Server Profile dialog, type a profile Name — something recognizable for this collector. On the Servers tab, click the Add button inside the dialog, not the one on the page behind it. This adds one row to the servers grid.

1.5 Fill the server row

Click each cell to edit it:

Click OK.

Why IETF and not BSD. The collector's TCP input expects PAN-OS to send syslog messages using the IETF (RFC 5424) format, with RFC 6587 framing (octet counting) — the collector's TCP input enables this by default. BSD format over TCP will parse badly or not at all.

1.6 Confirm the profile

This is what a correct profile looks like — server address, TCP, your syslog port, IETF, LOG_USER:

---

Part 2 — Create the Log Forwarding Profile

Where: Objects → Log Forwarding

The server profile only says where to send. This step says what to send.

1. Select the Objects tab, then Log Forwarding in the left tree.
2. Click Add.
3. Name the profile.
4. Add two match-list entries, one per log type:

For each: click Add in the match list, give it a name, pick the Log Type, leave the Filter as All Logs, then under Forward Method → Syslog click Add and select your server profile.

5. Click OK.

Add only the log types you actually intend to consume. Every extra type is volume you pay to ship, store, and eventually filter back out. traffic alone is usually the highest-volume class on a real perimeter.

---

Part 3 — Attach the profile to your Security rules

Where: Policies → Security

This is the step most often missed. A log forwarding profile that is not referenced by any rule forwards nothing, and the firewall reports no error whatsoever.

1. Select the Policies tab, then Security.
2. Click the name of a rule that carries the traffic you want to observe.

3. Go to the Actions tab.
4. Under Log Setting:
   • Tick Log at Session End.
   • Leave Log at Session Start unticked.
   • Set Log Forwarding to your profile.
5. Click OK.
6. Repeat for every rule that covers traffic you care about — including any explicit Deny rules, which on a real perimeter are usually the single largest source of events.

Why not Log at Session Start. Enabling both emits two records per session — one at start and one at end — roughly doubling volume while adding no verdict. The session-end record is the one that carries bytes, duration, application, and action. Turn on session-start only when you are specifically debugging session establishment.

---

Part 4 — Commit

1. Click Commit at the top right, then Commit again in the dialog.
2. Wait for the job to reach 100% and report Configuration committed successfully.

Nothing you configured above is live until this finishes. A commit on a VM-Series takes roughly one to two minutes.

---

A note on time zone

PAN-OS stamps syslog messages using the firewall's configured local time zone, found at Device → Setup → Management → General Settings → Time Zone.

If the firewall runs in a local zone while your collector and every other log source run in UTC, PAN-OS events land on the timeline offset by that many hours. Nothing errors. Dashboards populate. Correlation against other sources silently produces nothing, and every time-window query you write is wrong.

Two valid resolutions — pick one deliberately:

Whichever applies, tell your onboarding contact which one — it needs to be on record for anyone debugging a time-window query later.

---

Important — the collector is not listening yet

Committing finishes the firewall's half of the job, but that alone does not make the collector reachable. The collector's syslog listener on port 9001 does not open when your machine enrolls in Step 2 — it opens when Step 4 (the intake form) is submitted and JawaSec's activation completes. Enrollment only registers the machine with our Fleet management; the syslog input itself is a separate configuration that is attached to your machine automatically once both your enrollment and your Step-4 submission are in.

Practically: if you test connectivity from the firewall to the collector's port before you finish Step 4, the connection will fail — by design, not because something is wrong on your side. Complete Steps 1-4 in order, including saving the intake form, before drawing any conclusion from a failed connectivity test.

You also never need to re-run the Step-2 install command after this guide. The syslog listener is delivered to your already-enrolled machine as a policy update pushed by Fleet — the same mechanism Step 2's agent already checks in through — not by reinstalling anything.

---

Verification

On the collector machine, confirm the firewall is connecting (only meaningful after Step 4 has completed and activation has run — see the box above):

ss -tn state established '( sport = :9001 )'

Established connections from the firewall's IP mean the transport works.

If you want to prove the firewall is trying even before the collector is ready, watch the packets directly:

sudo tcpdump -ni any "port 9001 and src host <firewall-ip> and greater 100" -A -s0 -c 6

A well-formed message from a correctly configured firewall carries an RFC 6587 octet-count prefix followed by the RFC 5424 header and the log body — for example 812 <14>1 2026-08-28T13:42:35-07:00 .... If you see that on the wire, the firewall is doing its job and any remaining problem is downstream. If you don't, the problem is profile or policy configuration (Parts 1-3).

In the JawaSec portal, the Step-3 card flips to done once you tick the confirmation checkbox and the Step-4 intake form is submitted; the source itself goes Active once JawaSec's automatic activation detects the first real events arriving from your collector — this does not happen instantly at Save.

If nothing arrives after Step 4

Each of these produces the same symptom — no data — so check them all before concluding the firewall is at fault.

---

Notes

• The Syslog Server field in the Server Profile dialog is a plain text field — enter your collector's address or FQDN directly.
• Multiple syslog servers are supported within one profile. To keep a raw local copy of the logs alongside the collector, add a second syslog server entry on a different port of the same host and have a local syslog daemon write that port to a file.
• One collector machine can receive both a Palo Alto and a Cisco FTD integration at once, one per port (9001 Palo Alto, 9002 Cisco by convention) — each keeps its own state in the portal.
• A "Welcome to PAN-OS!" modal can appear on first login and blocks every click behind it, including the top navigation. Close it first.
• The Add button appears twice when a dialog is open — once inside the dialog, once on the page behind it. Clicking the wrong one silently does nothing useful.

---

Questions

Direct any questions about this guide or the firewall change to your JawaSec onboarding contact.