We've been running a ZTNA overlay (Cloudflare Zero Trust, specifically) for about eight months now for our developer and admin teams, and the general experience has been positive for web apps and SSH. However, we've hit a persistent and frankly baffling roadblock with thick-client applications, specifically the SAP GUI for Java and SAP GUI for Windows.
The architecture is standard: the ZTNA proxy (Cloudflare daemon) runs on user endpoints, traffic for specific domains is routed through it, and access is gated by our IdP (Okta). The connection establishes, and we can even reach the SAP application servers' FQDNs. The SAP GUI client initiates its DIAG or RFC communication, but then we experience one of two failure modes:
1. **Intermittent Connection Drops:** The GUI will connect and function for 2-5 minutes, after which the session freezes and is terminated. Packet captures on the client side show a clean TCP RST from the server side, but the server-side logs indicate a timeout from an unknown source (the proxy IP, not the user IP).
2. **Protocol-Specific Handshake Failures:** For some RFC connections, the initial handshake fails entirely. The error messages from SAP are generic (`RFC_ERROR_COMMUNICATION`).
We've ruled out basic network issues. Non-proxied, direct connections (via VPN) work flawlessly. This points squarely to the ZTNA proxy's handling of long-lived, stateful, non-HTTP TCP streams.
My hypothesis is that the proxy's TCP multiplexing, idle timeouts, or MTU/MSS adjustments are incompatible with SAP's protocols, which are notoriously sensitive to latency and packet manipulation. The ZTNA provider's documentation is, unsurprisingly, silent on legacy thick-client application support beyond "it should work."
Has anyone else successfully navigated this? I'm looking for concrete, implementable details:
* **Specific ZTNA Vendor & Configuration:** Are you using Cloudflare, Zscaler, Netskope, or another? What explicit settings (e.g., `tcp.keepalive`, `proxy.buffer`, any "raw TCP" vs. "optimized" tunnels) did you adjust?
* **SAP GUI Version & Connection Type:** Are you using DIAG, RFC over TCP/IP, or HTTP? Specific SAP GUI patches?
* **Required Architectural Compromise:** Did you have to create a bypass rule for the SAP traffic, effectively taking it out of Zero Trust? If so, how do you justify that from a security posture perspective?
Our current workaround is a split-tunnel VPN just for SAP, which completely undermines the ZTNA principle for these critical systems. The goal is a true Zero Trust access model. I'll start by sharing our failing proxy configuration snippet for the SAP application subdomain:
```yaml
# Cloudflare Zero Trust App Config (failing)
applications:
- domain: sap-apps.corp.example.com
type: tcp
session_duration: "24h"
# Attempted adjustments with no success:
# ip_rule: false
# tls_intercept: false
```
-- alex