Built a custom Grafana dashboard pulling data from our Check Point R81.20 management API and Palo Alto Panorama. Goal: compare Check Point's rule hit counts against Palo Alto's App-ID classification for the same traffic flows over a week.
Key finding: Palo Alto's App-ID consistently tagged 15-20% of our east-west traffic as "unknown-tcp" or "unknown-udp" where Check Point simply showed rule hits by port/IP. However, for known web traffic (ports 80/443), Palo Alto's application granularity (e.g., "ssl > google-docs") provided better context, but Check Point's rule hits were more accurate for our custom internal apps that Palo Alto couldn't dissect.
Dashboard uses these queries (simplified):
```javascript
// Check Point rule hits per service (simplified)
| where Source in (internal_subnets)
| where Dest in (target_servers)
| stats sum(Hits) by RuleName, Service
```
```sql
-- Palo Alto traffic log query
application = 'unknown-tcp' and action = 'allow'
| stats count by src_ip, dest_ip, dest_port
```
Takeaway: If you rely on L7 visibility for standard SaaS apps, Palo Alto wins. For environments with heavy custom protocols or where port-based logging is sufficient, Check Point's data is cleaner and faster to query. The "unknown" traffic from Palo Alto required extra DECODER tuning we didn't need with Check Point.
Benchmarks or bust.
SRE lead at a fintech with about 300 hosts, we run both Palo Alto VM-300s at the edge and Check Point 1600s for internal segmentation. I see this data mismatch weekly.
* **App-ID vs. Simplicity** - Palo Alto's App-ID needs clear protocol fingerprints. Internal gRPC or custom binary protocols on ephemeral ports default to 'unknown'. We see 10-15% unknown on east-west, matching your data. Check Point logs the rule and port, which is often enough for internal network ACL auditing.
* **Management Overhead** - Palo Alto's Panorama is a single pane for policy. Check Point's SmartConsole feels like a legacy client; API is clunky but functional. Initial rule migration from another vendor to Palo Alto took us 3 weeks. To Check Point, 2 weeks.
* **Cost Realities** - Palo Alto's premium is in the subscriptions (Threat Prevention, WildFire, DNS Security). List adds ~40% to hardware cost. Check Point's support renewal is the shocker, typically 25-30% yearly, and they audit for compliance.
* **Failure Mode** - Under sustained load (we push 1.8 Gbps through a VM-300), App-ID inspection fails first, defaulting to port-based. The box still passes traffic. Check Point under similar load will start dropping packets if IPS features are enabled.
I'd pick Palo Alto for any internet-facing segment or if your security team writes L7 rules. Pick Check Point if your internal controls are port/IP based and your team already knows the CLI. Tell us your team's size and whether you manage these yourself or through a MSSP.
Five nines? Prove it.
Your note about App-ID failing under sustained load before the box passes traffic is critical. We observed the same at 2.1 Gbps on VM-500s, documented during our annual performance validation. The inspection bypass isn't always clean, it can create a "blip" in our time-series threat logs where events vanish for 45-60 seconds.
I'd push back slightly on the Check Point support cost comparison. While their renewal is 25-30%, that typically includes all software updates. Palo Alto's ~40% subscription add-on is mandatory for the App-ID and Threat Prevention databases themselves. If you let that lapse, the box effectively becomes a stateful firewall. The total three-year TCO, in our benchmarking, came within 5% for equivalent throughput tiers when you factor that in.
Have you quantified the operational risk of that inspection failure? We built a simple canary that alerts when "unknown-tcp" traffic spikes correlate with a drop in App-ID decoded flows, indicating potential load shedding.
—chris
That 5% TCO delta you found is interesting, but I think it masks the real procurement trick. The "equivalent throughput tier" is where they get you. Vendor spec sheets for both are, charitably, aspirational fiction. You're probably comparing a Palo Alto "threat prevention throughput" number to a Check Point "firewall throughput" baseline, which are apples to oranges.
On the operational risk of the inspection blip, quantifying it is the easy part. The harder sell is getting the security team to accept that their shiny "application-aware" firewall occasionally becomes a dumb packet filter during peak loads. Our canary triggers maybe twice a quarter, and each time it's a 15-minute debate whether it's a real threat or just the box sweating.
So that 5% savings might just be the price of admitting you need over-provisioned hardware to get the consistent inspection you paid for.
Trust but verify.
You're dead on about the throughput specs being fiction. The real procurement trick isn't just comparing apples to oranges, it's that the fruit is plastic. You have to size based on the lowest number on the spec sheet, which for Palo Alto is usually "Threat Prevention" and for Check Point is "IPS."
That 5% TCO delta becomes a 40% hardware premium the moment you realize you need the next model up to handle your actual traffic mix with all features turned on. So the "savings" is just paying for breathing room they should have baked into the SKU.
And yes, the security team never budgets for the "occasionally dumb" tax. They bought a sports car but complain when it can't haul gravel.
Show me the bill
You're right about sizing to the lowest spec. The practical consequence we measured is that "IPS" or "Threat Prevention" throughput assumes a single, worst-case traffic profile, usually small packet size with all inspection features on. Real traffic is a mix, which causes wildly variable performance. Our Palo Alto VM-300's CPU would spike to 80% on a 700 Mbps mix of web and database traffic, even though the spec sheet claimed 1 Gbps threat prevention.
This creates that hidden 40% premium. You're not buying more throughput, you're buying CPU headroom to handle the variance they don't advertise. Check Point's IPS number is slightly more conservative in our tests, but they still assume optimal conditions. The only reliable sizing method is a PoC with your actual traffic.
Data never lies.
Good data, but you're measuring the wrong thing. The 15-20% 'unknown' traffic is a cost, not just a visibility gap. Every byte of that traffic is still being inspected by the Palo Alto, chewing CPU cycles you paid for with the App-ID premium. Check Point's port-based logging on the same traffic uses less CPU.
Your dashboard could show the real trade-off: map unknown traffic volume to the Palo Alto's CPU utilization. I bet the 'unknown' traffic is your cheapest to process, but you're paying for the most expensive inspection to fail at classifying it.
show the math