Openziti hosted with Cloudflare DNS with WAF

I’m currently facing an issue while trying to enable Cloudflare Proxy for my Ziti Controller endpoint. Here’s a quick breakdown of the situation:

Setup:

  • Ziti Controller
  • Cloudflare Proxy: Trying to enable Proxy mode (Orange Cloud) so we can apply WAF and other Cloudflare security features to the endpoint.
  • Problem: Once Cloudflare Proxy is enabled, the traffic to the Ziti Controller breaks due to SSL issues (likely because the self-signed certificate is not trusted by Cloudflare in Full SSL mode).

What I Need:

I want to enable Proxy mode to take advantage of Cloudflare’s WAF for securing the Ziti Controller’s API endpoint, but the current SSL setup is causing issues.

Questions:

Has anyone successfully used a ziti-controller with Cloudflare Proxy in Full SSL mode, and if so, how was it configured?

I haven't heard of anyone doing this yet. I don't know if CF Proxy will support TLS pass-through or not but that would of course be a requirement. If you get it working, let me and the community know! :slight_smile:

I tried that approach, but it wasn’t working, so I’m not sure where to find the logs. I’ll investigate further. This is primarily to secure an API endpoint that’s currently public, and I want to ensure that endpoint is protected.

In Netfoundry or Openziti how do you protect ziti controller endpoint? you dont enable WAF kind of stuff to the protect public end points?

i think with cloudflare free version, we cant terminate SSL and use tls passthrough, i think i should use only on enterprise plan.

I'm planning to use Cloudflare Tunnel (cloudflared) to secure traffic to the Ziti Controller and enable Cloudflare’s WAF for extra protection. This will prevent the Ziti Controller from being exposed to the internet, helping secure the endpoint itself. I'm not sure if I’m being overly cautious, but I want to ensure the environment is as secure as possible. While the applications are already protected through Ziti, this adds another layer to safeguard the controller’s public entry point.

What risks are you trying to mitigate with the Cloudflare tunnel? Given that the endpoints are mTLS protected, with the exception of the well-known and version endpoints, for good reasons, the value add of a WAF is minimal at best. It won't be able to see into the traffic passing through it. Certainly, you could use it to block addresses you find scanning, etc. but scans are just the price one pays for having anything on the internet. The same thing could be done via ufw on the unit itself. Whitelisting would be painful, as any possible address you want to use for clients, etc. would have to be placed into the list, and dynamic addresses would be out, making operations difficult.

I'm all for applying security in layers where appropriate, but this seems like a layer that adds operational complexity while not providing a strong security gain. Perhaps I am misunderstanding your intent or use case, if I am missing something obvious to you, please let me know.