Wednesday, 4 February 2026

Palo Alto Case Study: URL Still Blocked Even After Allow



I received a request from the application team to allow a specific URL on the firewall.

I added the URL into our custom URL category with action = Allow and shared the update.

A few minutes later, the app team came back:

“Still not able to access the URL.”
So we jumped into a troubleshooting call.
What we saw during troubleshooting
URL logs were clearly showing Action = Deny
But in the configuration, I could see the URL was explicitly allowed
At first glance, everything looked correct.
Allow was configured, policy was hit, but traffic was still blocked.

The real root cause
After digging deeper, I realized:
👉 The same exact URL was already present in another custom category
👉 That category was configured with Action = Deny
👉 Both categories were part of the same security profile

Palo Alto behavior (the key insight)
Palo Alto uses most-restrictive logic for URL filtering:
If a URL matches multiple categories,
the firewall enforces the most restrictive action
So:
Deny > Continue > Alert > Allow

Lesson learned (the hard way)
This wasn’t a firewall issue.
It was a governance and design mistake.
Practical takeaway for engineers

Before adding any “quick allow”:
Search the URL across all custom categories
Remove conflicting entries
Maintain a single source of truth for URL exceptions
Otherwise, you may end up debugging a problem that you unknowingly created yourself.

Architect mindset:
In security systems, restriction always overrides permission.

No comments:

Post a Comment

Why do many Palo Alto engineers open a TAC case immediately… without checking anything first?

A production issue happens. Application team says “network issue.” Users say “firewall problem.” And within minutes someone says: “Let’s ope...