I’m running a web service on Fly that I want behind a WAF. Is using a Cloudflare Tunnel the only practical way to avoid direct-to-origin bypasses?
My understanding:
If I just expose the app publicly and point DNS at it, attackers can hit the Fly hostname/IP directly and bypass the WAF.
I could run my own reverse proxy on Fly and try to hard-allowlist the WAF’s IPs (or mTLS), but that seems more complex and still leaves the proxy’s public listener as a DDoS target unless there’s a real firewall/ACL in front.
Is there a simpler or built-in Fly approach to get “only traffic from the WAF reaches the app,” or is a tunnel (cloudflared or similar) the recommended pattern?
I’ve not done this, but I’d guess a WAF could add a request header with a secret, and then your app listener returns 500 if that secret is missing. Web servers like Apache or Nginx almost certainly could do that. What listener do you have?
Your app should parse the X-Forwarded-For header and allow only clients from trusted reverse proxies (a WAF is a reverse proxy). Most application frameworks should allow you to do that with minimal added code and you shouldn’t need yet another reverse proxy in front.
DDoS is not a direct concern (for you) since Fly Proxy terminates the TCP connections, so any DDoS traffic is going to hit Fly Proxy first. If they do not establish a real TCP connection, then that attack ends at us, not your machines; if it does establish real TCP connections (which will be a much more expensive attack and unlikely to overwhelm Fly Proxy or your app), then a policy that only allows trusted reverse proxies should block those connections as well.
We do have plans to eventually support the ability for you to “program” the proxy to only accept connections that match a certain pattern, but no ETA on that yet
