How Palo Alto firewall logs reach Graylog through a dedicated input
Security and network teams that need PAN-OS traffic, threat and GlobalProtect events searchable in Graylog should use the dedicated Palo Alto Networks inputs rather than a generic syslog listener. Graylog lists a Palo Alto Networks TCP (PAN-OS v11+) listener input, and Graylog 7.1.0 added a Palo Alto Networks UDP (PAN-OS v11+) input. Choosing between them is the first decision: the TCP listener gives the sender a connection, while the UDP input suits firewalls that only send over UDP. Confirm which transport your firewall and any intermediate syslog relay can use, and confirm the PAN-OS version on every firewall that will send logs, because both inputs are labeled for PAN-OS v11 and later.
The firewall must then send syslog in a format the input expects, and the sender, transport, port and TLS settings should be agreed with the network team before the input is created. Keep one input per transport and record which firewalls feed it, so that a later change on one device does not break parsing for the others. Test with a single firewall first and check that traffic, threat and GlobalProtect messages arrive as separate message types in Graylog's search results.
Receiving the raw messages is not the same as having them parsed into fields. Parsing for PAN-OS logs depends on the Illuminate Palo Alto content pack, which needs a Graylog Illuminate license with Enterprise or Security. Ask whether your license covers Illuminate before you plan dashboards or alerts that rely on named fields, and confirm with Graylog which pack version applies to your PAN-OS release, since the Palo Alto 11 pack is the successor noted for the Illuminate content line.
What you need before the firewall sends its first log
Four things have to line up before PAN-OS traffic, threat and GlobalProtect logs arrive in Graylog: the Graylog version and deployment, the PAN-OS release, the network path to the input, and a decision on parsing. Work through these cards in order, because the firewall configuration only makes sense once the receiving side is known.
Graylog version and deployment
The dedicated Palo Alto inputs are documented in the current Graylog docs, which cover version 7.2, and the UDP input was added in Graylog 7.1.0. Confirm which release your cluster runs before you choose TCP or UDP, because an older server may only offer the TCP listener. Check the install method (packages or Docker Compose) and whether the input sits on the Graylog server nodes you plan to expose.
PAN-OS version for the dedicated inputs
The Palo Alto Networks TCP and UDP inputs are labeled for PAN-OS v11 and later. Record the exact PAN-OS release on every firewall, including HA pairs and branch units, because older firmware may format logs differently. If a firewall runs an earlier release, plan a generic syslog input and confirm the field format with a test capture.
Network path to the Graylog nodes
Each firewall needs a route to the input port on every Graylog node that will receive its logs. Confirm the listener port you configure in Graylog, then open the matching rule on the firewall's log-forwarding path, any intermediate firewall and host-based filters. Check whether traffic crosses a load balancer, because a UDP listener and a load balancer that expects TCP will not behave the same way.
Graylog Open versus Illuminate licensing
Graylog Open runs the Palo Alto inputs, so raw logs can arrive and be searched without a paid license. Parsing through the Illuminate Palo Alto content pack needs a Graylog Illuminate license with Enterprise or Security. Decide before go-live whether your team needs that parsing, and ask your Graylog representative to confirm which edition and license covers the content you plan to use.
Syslog format and listener ports
Decide on the syslog format the firewall will send, and confirm that the Graylog input you select matches it. Set the listener port and transport in your own change record, then test with a short burst of logs from one firewall before enabling others. Record who owns the firewall rule, the Graylog input and the port number so changes stay traceable.
Configuring the Palo Alto input and PAN-OS syslog profile
This sequence connects a PAN-OS firewall to a Graylog input so traffic, threat and GlobalProtect logs arrive in search. The work is split between the Graylog administrator, who creates the input and checks ingestion, and the firewall administrator, who configures syslog delivery. Each step closes with a check you can run before moving on.
Confirm PAN-OS version and log types
Start by recording the PAN-OS version on each firewall that will send logs. The dedicated Palo Alto inputs are documented for PAN-OS v11 and later, so confirm the version against the Graylog inputs documentation before you build anything. List the log types you need from each firewall: traffic, threat and GlobalProtect. Check: every firewall reports its version in the device dashboard, and you have a written list of log types for each one.
Choose transport and create the input
Compare the Palo Alto TCP (PAN-OS v11+) listener and the Palo Alto UDP (PAN-OS v11+) input in the Graylog inputs documentation, then pick the transport your firewalls and network path support. The UDP input arrived in Graylog 7.1.0, so older releases do not offer it. In the Graylog web interface, create the input, select the nodes that will listen, and set the bind address and port your firewall will target. Check: the input shows as running on each node that should receive logs.
Create the syslog server profile on the firewall
In PAN-OS, open the server profile settings and add a syslog profile that points to the Graylog node address and the port from your input. Match the transport to the input you created, and confirm the format setting against the Graylog input documentation for your PAN-OS release. Commit the change and record the profile name for the next step. Check: the profile saves without validation errors and appears in the syslog profile list.
Attach log forwarding for each log type
Create a log forwarding profile that sends traffic, threat and GlobalProtect logs to the syslog server profile. Attach it to the security rules and GlobalProtect logging settings that generate those logs, since logs only leave the firewall for objects that reference the profile. Commit the configuration. Check: a review of your security rules shows the profile attached to every rule you expect to produce traffic logs, and the GlobalProtect logging settings reference the same profile.
Generate test traffic and firewall events
Produce known test events on the firewall: a permitted session through a rule with forwarding enabled, a session your rules block so the firewall records a traffic or threat entry, and a GlobalProtect connection if you use it. Note the time and source address of each event so you can find it in Graylog. Check: the firewall's own monitor shows each event locally, which separates firewall configuration issues from Graylog ingestion issues.
Confirm messages arrive in Graylog search
In Graylog search, filter on the firewall source address and the time window from your tests, then look for traffic, threat and GlobalProtect messages. If messages are missing, check the input status on each node, the firewall commit state, network access from the firewall to the node on the chosen port and transport, and whether the messages match any stream rules you have set. Check: each log type you tested returns at least one message from the expected firewall, and those messages land in the stream you planned.
How Illuminate parses PAN-OS logs and what the PAN-OS 11 change means
The Illuminate Palo Alto content pack parses GlobalProtect, threat and traffic logs from PAN-OS 9.1 and later, and using it requires an Illuminate license with Graylog Enterprise or Graylog Security. Before you rely on it, confirm that your firewalls run a supported PAN-OS release, that the log types you need are in the pack's documented scope, and that your Graylog edition includes Illuminate. Check these against the Illuminate Palo Alto content pack documentation, since the pack's coverage is the controlling reference for what gets extracted into fields.
The pack is set to be removed in Illuminate 8.0.0 in favour of the Palo Alto 11 pack. That makes the content pack a version decision, not just a parsing setting. If your firewalls are on PAN-OS 11, plan for the Palo Alto 11 pack and the dedicated TCP or UDP inputs for PAN-OS 11. If you are still on PAN-OS 9.1 or 10.x, the older pack remains the documented path today, but you should confirm with Graylog which pack and input combination it expects for your version before you change anything. Do not assume field names carry over unchanged between the two packs.
Plan the upgrade path in the same change window as the firewall and Graylog upgrades. Inventory every stream, dashboard, search and event definition that references Illuminate-generated fields, then test them against a staging Graylog with sample PAN-OS logs from each firmware version in your estate. Record which Illuminate version is in use, which pack is installed and which PAN-OS release sends each log type, so a later Illuminate or PAN-OS upgrade does not break detections silently.
Which PAN-OS log types map to which Graylog streams and fields
This table compares the traffic, threat and GlobalProtect log types from PAN-OS against the input, stream and field checks each one needs in Graylog. Read each row against your firewall's PAN-OS release and your Graylog version, since the dedicated input and the Illuminate content pack do not cover the same releases. Confirm the field names in a sample message before you build streams or alerts on them.
| Log type | Input and parsing path | What to check before you build |
|---|---|---|
| Traffic logs | Palo Alto Networks TCP (PAN-OS v11+) or UDP (PAN-OS v11+) input, or the Illuminate Palo Alto content pack for PAN-OS 9.1 and later | Confirm the PAN-OS version on the firewall, then compare sample traffic messages against the fields your dashboards expect |
| Threat logs | Same inputs as traffic logs, with threat fields parsed by the input or the content pack | Confirm that threat messages arrive as their own log type and check severity and action fields in a sample before writing event definitions |
| GlobalProtect logs | Parsed by the Illuminate Palo Alto content pack for PAN-OS 9.1 and later, which needs an Illuminate license with Enterprise or Security | Confirm the license, and confirm that the GlobalProtect fields you need appear after the content pack is installed on your Graylog version |
| Stream routing | Streams separate traffic, threat and GlobalProtect messages after parsing | Test each stream rule against live messages, because a rule that matches on a field missing from one PAN-OS release will silently drop events |
| Input settings | Listener port, protocol (TCP or UDP), and TLS settings if the firewall sends over TCP | Confirm the port and protocol match the firewall's syslog profile, and confirm the Graylog input version supports your PAN-OS release |
| Content pack changes | The Illuminate Palo Alto content pack is set to be removed in Illuminate 8.0.0 in favour of the Palo Alto 11 pack | Confirm which pack your Illuminate version ships and plan the migration before you upgrade Illuminate or PAN-OS |
| Timestamps and hosts | Parsing sets the event time and source host, which drive index rotation and search | Compare the device time with the Graylog receive time, and confirm the source field identifies the firewall rather than a relay |
Securing the firewall-to-Graylog log path
Firewall logs carry network topology, user identities and threat detections, so the path from PAN-OS to Graylog needs the same care as the firewall itself. The cards below cover transport protection, listener exposure, administrative access and the firewall log profiles that decide what gets sent.
Encrypt the TCP path where supported
A TCP listener can carry TLS only if both the input version and the firewall's log forwarding configuration support it. Confirm this for your exact Graylog version before you design around it. Where TLS is available, plan certificate issuance, rotation and trust distribution to the firewall, since a expired certificate silently stops log delivery. If TLS is not available on your input version, decide whether the log path stays on a segment that only the firewall and Graylog can reach.
Restrict listener access by source address
Each Palo Alto input listens on a network port that any host able to route to it can attempt to use. Limit the listener to the management or log-forwarding addresses of your firewalls using host firewall rules, network access control lists or the Graylog node's bind configuration. Test the restriction with a known source and a blocked source before go-live, because a rule that is too narrow drops logs without an error on the Graylog side.
Separate Graylog admin and input roles
Changing an input's port, bind address or parsing settings alters what Graylog accepts, so those permissions should sit with a small group of administrators. Give operators read access to the firewall streams and dashboards, and keep input creation and deletion under a named role. Review role membership on a schedule and remove access for people who have moved teams.
Protect the input configuration
Record the settings of each Palo Alto input, including port, protocol, bind address and any TLS options, in a configuration file or export kept under version control. Restrict who can change the Graylog node configuration files on the server, since those files hold the settings that govern all inputs. Compare the live configuration with the recorded version after each upgrade.
Control firewall log profile changes
The log forwarding profiles on the firewall decide which traffic, threat and GlobalProtect events reach Graylog. A quiet change to a profile can stop threat logs or flood the cluster with traffic logs. Route changes through your normal change process, record which log types each rule forwards, and confirm the Graylog stream counts after each change.
Confirm the syslog format after firmware changes
A PAN-OS upgrade can change the fields or format the firewall sends, which can break parsing even when logs keep arriving. Treat a firmware upgrade on the firewall as a change that requires a parsing check in Graylog. Compare a sample of messages before and after the change, and confirm that the input version you run supports the PAN-OS release in use.
Why Palo Alto logs stop, arrive unparsed or fill the journal
This table lists the failures teams most often hit when PAN-OS logs reach Graylog, with the likely cause and the first check for each. Read it top to bottom when logs are missing, arrive as raw text, or the message journal climbs. The main takeaway is that most failures trace back to a mismatch between the firewall's transport and format and the input you created, so check that pairing before anything else.
| Symptom | Likely cause | First check |
|---|---|---|
| No logs arrive at all | Transport mismatch: the firewall sends TCP but the input listens on UDP, or the reverse | Compare the syslog transport set in the firewall server profile with the protocol of the Palo Alto input, and confirm the input is running |
| Logs arrive but the input rejects them or shows no traffic | PAN-OS below v11 sent to the dedicated Palo Alto inputs, which target PAN-OS v11 and later | Confirm the PAN-OS version on the firewall and whether a legacy syslog input is needed for older releases |
| Messages arrive as raw text with no fields | Missing Illuminate license, so the Palo Alto content pack cannot parse GlobalProtect, threat and traffic logs | Check the Graylog license for Illuminate with Enterprise or Security, then confirm the content pack is installed |
| Messages arrive but cannot be found in searches | No stream routes them, or a pipeline rule drops or rewrites them before indexing | Open the input's message sample, then check which stream rules match and whether any pipeline rule discards the message |
| Connection refused or timeouts from the firewall | Blocked port between the firewall management or data interface and the Graylog input | Test reachability from the firewall network to the input port, and review host firewalls and network access lists on the path |
| Journal fills and input throughput drops during traffic spikes | Bursts of traffic or threat logs exceed what the server nodes can index, so the message journal grows | Check journal utilization and indexing rate on each node, and confirm the journal sizing is within the range the system architecture guidance describes |
| Only some firewalls or log types appear | One firewall or log type is sent to a different port or input than expected, or a log forwarding profile is limited to certain categories | Verify the log forwarding profile attached to each rule and the destination port configured on each firewall |
| Timestamps or hosts look wrong | Firewall clock is not synchronized, or the source address is a load balancer or NAT address instead of the firewall | Compare the firewall time with the Graylog node time and confirm the source host field matches the firewall management or data address |
Questions buyers ask before setting up Palo Alto logs in Graylog
What drives the cost of sending Palo Alto logs to Graylog?
The cost depends on the Graylog edition you license, whether you need the Illuminate Palo Alto content pack, the PAN-OS version on each firewall, and how many firewalls send logs and how much volume they produce. Graylog Open is free with no volume limits and community support. According to the Graylog pricing page, Graylog Enterprise starts at 15,000 US dollars per year and Graylog Security starts at 18,000 US dollars per year, each with a minimum of 10 GB per day or 100 Graylog Compute Units, licensed on processed data with no per-user or per-device fees. Your own spend also includes the server, storage and any services work, which are quoted separately from the license.
Does the Illuminate Palo Alto content pack need a paid license?
Yes. The Illuminate Palo Alto content pack needs a Graylog Illuminate license that comes with Enterprise or Security, so it is not included in Graylog Open. The pack parses GlobalProtect, threat and traffic logs from PAN-OS 9.1 and later. Confirm the license terms for your edition with Graylog before you plan around the pack, because the pack is set to be removed in Illuminate 8.0.0 in favour of the Palo Alto 11 pack. Without Illuminate, you can still receive the logs through the Palo Alto inputs, but you will need to build your own field extraction and searches.
Does the PAN-OS version change how Graylog receives the logs?
Yes. Graylog lists a dedicated Palo Alto Networks TCP input for PAN-OS v11 and later, and Graylog 7.1.0 added a Palo Alto Networks UDP input for PAN-OS v11 and later. If your firewalls run older PAN-OS releases, plan for generic syslog inputs and check the parsing with your own test logs. Confirm which input matches each PAN-OS version in your fleet, and check the content pack change before you upgrade Graylog or PAN-OS, since both can alter field names.
How long does a Palo Alto log integration usually take?
Duration depends on scope: the number of firewalls, whether you run both TCP and UDP listeners, how many log types you parse, whether Illuminate is part of the design, and how many approval steps your network needs. A single-site setup with one input and a few searches is a much smaller job than a multi-site rollout with retention rules and dashboards. Ask any provider for a timeline tied to a written scope, and ask which steps depend on your change approvals rather than on technical work.
What must our team provide before the work starts?
Plan to supply administrative access to the firewalls or a firewall administrator who can set the syslog server profile and log forwarding rules, network approvals for the traffic path from each firewall to the Graylog inputs, and a list of the log types you need, such as traffic, threat and GlobalProtect logs. You also need your retention requirements, since they set index sizes and storage. Confirm the expected daily volume with your firewall team so the cluster can be sized correctly.
Can our internal team set this up on its own?
An internal team with Graylog and firewall experience can usually configure a single input, forward a few log types and run basic searches. The harder parts tend to be parsing choices across PAN-OS versions, sizing storage and the journal, handling TCP versus UDP delivery, and designing retention and access for the security team. Fixed-scope work from DeployOpen covers planning, implementation, documentation and handover for systems you run in your own infrastructure. Compare that with the time your staff can commit to the project and the support they would need after go-live.
Which Graylog version should we plan around for firewall logs?
Plan around the version your organization is running or intends to run, and check the current documentation for that version. Graylog's current documentation covers version 7.2, and the compatibility matrix lists the MongoDB and OpenSearch or Data Node versions each release supports. Graylog 7.0 to 7.2 support OpenSearch from 1.1.x up to 3.7.x, and use of OpenSearch 1.x is deprecated since Graylog 7.0 and will be removed in Graylog 8.0. Confirm these requirements in the compatibility matrix before you pick a search backend.
What are the main risks in sending firewall logs to Graylog?
The main risks are dropped or unparsed logs from a mismatched input or PAN-OS version, storage that fills faster than expected because firewall traffic logs are high volume, and unclear ownership of the Illuminate content pack after the planned removal. Security risk also matters: the syslog path should be restricted to approved sources and protected with the controls your network team uses. Test with real traffic from each firewall model before you rely on the logs for alerts or investigations.
How DeployOpen scopes and delivers Palo Alto log integration
DeployOpen plans the Palo Alto log integration as a fixed-scope engagement with written deliverables agreed before any work starts. In practice the scope covers four workstreams: the Graylog input and its network path, the log forwarding profiles on each PAN-OS firewall, the parsing decision (Illuminate content pack or the dedicated input's field extraction, depending on your PAN-OS version and license), and a verification pass that proves events from each firewall role arrive, parse and land in the right stream. Each workstream produces a named artifact, such as the input configuration, the firewall syslog profile settings, a field map for the traffic, threat and GlobalProtect log types, and a test record showing what was checked. The written scope also states which firewalls, which Graylog cluster and which license edition are in play, so that the quote follows from the actual environment rather than a generic template.
Before the scope is signed, ask for a short discovery list that your team can confirm: the PAN-OS version on every firewall in scope, whether any device is on a version earlier than 11 where the Illuminate Palo Alto content pack is the relevant path, the Graylog edition you hold and whether it includes the Illuminate license, and who owns the firewall change window. These answers decide the parsing path and the amount of firewall work, which are the two largest drivers of effort. Ongoing work is handled separately. Support for Graylog, upgrades that change the input or content pack behavior, and periodic re-verification after firewall software upgrades run as a retainer, so the one-time build and the recurring operation are priced and documented apart. Ask for the retainer terms in writing, including what happens when a PAN-OS upgrade changes log formats.
