Alright, I've hit a classic NGFW head-scratcher and I'm sure I'm not the first. My PA-850 is supposed to be logging threats, but the threat log is a ghost town. The security profiles are definitely applied to the policy allowing the traffic. I can see the traffic hitting the session browser, but the threat log? Nada.
Here's the setup:
* **Security Profile Group** attached to the policy rule: `strict-profile-group`
* That group includes a `strict-virus` profile (with blocking actions) and a `strict-vulnerability` profile.
* I've even run some blatant test traffic known to trigger these (EICAR for AV, old HTTP exploits for vuln). Traffic flows (or gets blocked, depending on the action), but still **zero** entries in Monitor > Threats.
My first thought was a log-forwarding issue, but the traffic logs are fine. This feels like a profile-to-logging pipeline disconnect. Before I dive into a packet capture debug spiral, has anyone else benchmarked this specific failure mode?
Checked the obvious:
- Log forwarding settings are enabled for threats.
- Profile actions are set to `block` or `alert` (not `default`).
- No funky log filters applied.
- Commit succeeded, no warnings.
Is this a known bug in certain PAN-OS versions (I'm on 10.1.9), or am I missing a hidden toggle? The session browser shows the policy and the profile group name, so the rule is definitely matching.
benchmarks or bust
Yeah, the session browser showing traffic but threats staying empty is a classic sign. Since you've already checked the big items, I'd look at two specific spots:
First, double-check that the threat log *type* is actually enabled. Even if log forwarding is on, sometimes the individual log types (virus, vulnerability, spyware) in the profile need their own "log setting" configured. It's a separate dropdown from the action, and it can default to "default" which might point to a log setting with no actual forwarding.
Second, have you verified the profile is hitting the exact traffic path? I've been burned before where asymmetrical routing meant my test traffic hit a different policy on the return path. The session browser will show the egress rule, but the threat inspection might happen on the ingress side with a different, profile-less rule.
If those are fine, maybe run a `debug log-collector` trace while generating the test traffic? It's a pain but it usually shows exactly where the log drops off.
Good point on the log setting dropdown, that one's bitten me more than once. But I'm less convinced about the asymmetrical routing angle for a basic lab test.
If they're running EICAR from a single client to a single server on a PA-850, odds are the session is symmetric. The bigger pitfall I've seen is when people forget that a *decryption* profile is also in play. If the traffic is being decrypted, the threat inspection happens on the decrypted stream, but the log visibility can get weird if the decryption profile isn't tied to the same threat profiles.
Did you check if a decryption policy is matched before the security policy? That can silently redirect the inspection context.
The decryption point is valid, but I've seen the opposite cause logs to vanish too. If you have a decryption policy that *doesn't* match the traffic, it bypasses inspection entirely. The security rule still shows a session hit, but the data skips threat scanning.
Also, check if the profile group is applied to both intrazone and interzone policies. Sometimes test traffic stays in the same zone, and you've only attached the profiles to rules between zones.
Don't pay list price