Migrating from Palo Alto Prisma Access to Cloudflare Zero Trust (Access). Ran into immediate issues with legacy app access and visibility.
* The biggest gap: no native TCP forwarding in Cloudflare Access. Palo Alto's App Framework handles this easily. Had to deploy Cloudflare Tunnel daemons (`cloudflared`) on every origin server for non-HTTP/S apps. More overhead.
* Session management is different. Palo's explicit VPN-like sessions vs. Cloudflare's per-request JWT validation. Broke some internal apps that relied on continuous TCP sessions from a known IP range.
* Lost these Palo features:
* In-line IDS/IPS for the encrypted traffic post-auth.
* Granular per-app traffic logs (we get logs, but different detail).
* The unified policy model for both network and app access.
What specific services or app types broke for you? Looking for concrete config gaps.
Our test setup for a simple TCP service via `cloudflared`:
```yaml
# tunnel.yml
tunnel: our-tunnel
credentials-file: /etc/cloudflared/cert.json
ingress:
- hostname: ssh.internal.example.com
service: ssh://localhost:22
- hostname: "*.db.internal.example.com"
service: tcp://localhost:3306
- service: http_status:404
```
- bench_beast
Benchmarks don't lie.
Yeah, the TCP forwarding thing was a real headache for us too. That `cloudflared` daemon sprawl gets messy fast, especially for stateful services like database protocols or old-school file transfer apps.
> Broke some internal apps that relied on continuous TCP sessions from a known IP range.
We hit this with a legacy financial reporting tool that used raw TCP sockets. Cloudflare's per-request validation meant the source IP was always a Cloudflare egress node, not a consistent user IP. We had to add a sidecar proxy just to inject the authenticated user's identity from the JWT into the TCP stream headers, which was a total hack.
And you're right about the logs - you lose the deep packet inspection context. You get "who accessed what" but not "what they sent". We ended up leaning heavier into L7 logging at the origin and shipping those to our SIEM. Not ideal, but it closed the gap a bit.
What did you end up doing for the IDS gap? Just accepting the risk shift?
K8s enthusiast
Yeah, the logging shift you described is exactly the trade-off. You're giving up network-level inspection for identity-aware logs. For us, that meant rethinking our security model entirely.
On the IDS gap - we didn't just accept it. We had to move that security layer *behind* the tunnel. We ended up implementing a host-based IDS (like Wazuh) on the origin servers themselves. It's more to manage, but it catches the "what they sent" part Cloudflare can't see once the traffic is decrypted.
It feels like moving from a single fortified gate to securing every individual room inside. More pieces to monitor, but you do get that user-to-action audit trail you mentioned.
✌️
We lost direct access to our mainframe terminal service (TN3270) and a proprietary manufacturing control protocol that uses persistent raw TCP sockets. Both broke immediately with the per-request JWT model.
The config gap wasn't just about the tunnel YAML. We had to build a mapping layer. Since Cloudflare presents a single egress IP, our on-prem firewall rules for "allowed source IPs" became useless. We had to replace IP-based auth with the JWT `cf-access-token` and a small proxy that validated it before forwarding the raw TCP stream. Adds latency and another point of failure.
You also lose the ability to do any traffic shaping or QoS at the perimeter for those TCP streams. Palo's policy could throttle a specific app's bandwidth; Cloudflare Tunnel is just a pipe.
Right-size or die
You're not even scratching the surface of the overhead yet. The cloudflared daemon is the tip of the iceberg. Wait until you have to manage and rotate the credentials-file across all those servers. One breached host with that JSON file can expose your entire tunnel, not just that one app.
The "unified policy model" loss is the real killer. You're now managing access in Cloudflare and network rules somewhere else. It's two places to screw up. Vendors love that. Doubles the consulting hours.
Your stack is too complicated.