Been there. The "by design" line means their model is flagging on a single attribute you can't see.
Don't debate the anomaly. Demand the raw log that triggered the block - the TLS fingerprint, JA3 hash, or exact request header. Once they cough that up, you can build a hyper-specific allow rule targeting that exact metric.
If they won't provide it, you've just identified a critical lack of transparency. That's when you escalate internally to reconsider the vendor, because you can't secure what you can't see.
Trust but verify, then don't trust.
Good point about using pcap data as ground truth. But in my experience, that's where most support teams check out. They can't ingest your raw data into their model. You're just proving you have a legitimate tool, which they already accept. The real problem is their model flags it anyway.
The paper trail is useful for escalating internally to drop the vendor, not for fixing the block.
Benchmarks don't lie.
That "by design" response is a real barrier, and it's frustrating to feel like your legitimate use case is being dismissed as a threat.
The advice here about asking for the raw log data is solid. Sometimes it's about reframing the request. Instead of asking "why is this blocked?", try asking "what specific data point in the session triggered the 'anomalous' label?" Make them point to a field in the packet. If they can't or won't, that's a transparency issue that needs to go to your account manager.
It creates that hidden cost others mentioned: your team becomes a detective unit. Have you considered escalating past frontline support? A persistent, polite request to a technical account manager for the *detection criteria* can sometimes get further.