Modernising Application Access

Replacing F5 with Cloudflare Tunnel & Zero Trust

Solutions Engineering

Today's Agenda

Current State

Architecture review & the challenge with F5 in a Cloudflare world

The Solution

Cloudflare Tunnel, Access & Load Balancing — end state design

Migration & Business Case

Three-phase migration plan, benefits, risks & next steps

Cloudflare Tunnel — outbound-only, no public IP required

Cloudflare Access — identity-aware proxy, Zero Trust policies

Cloudflare Load Balancing — replaces F5 LB with active health checks

Cloudflare SSL/TLS — automated cert management, Universal & Total TLS

Current State

Current Architecture

End Users

Internet

Cloudflare Edge

WAF · DDoS · CDN

CNAME

→ F5 IP

F5 BIG-IP

TLS Term · LB · Proxy

Server Farm

App Servers

Public inbound
F5 has a public IP — origin can be targeted directly if Cloudflare is bypassed

Cert duplication
TLS managed separately on both Cloudflare edge and F5 — two renewal lifecycles

No app-layer auth
No identity-aware access control — anyone reaching F5 hits the app directly

This is the current state. Traffic flows: users hit the internet, passes through the Cloudflare edge which provides WAF, DDoS protection and CDN. The DNS CNAME for each app points to the F5's public IP. F5 terminates TLS, load balances across the server farm, and acts as a reverse proxy. The three warnings at the bottom are the key problems we need to address. First: because F5 has a public IP address, if someone discovers that IP, they can target the origin directly, completely bypassing Cloudflare's security stack. Second: TLS certificates are being managed in two places — on the Cloudflare edge and on the F5. Two renewal cycles, two sets of operational work. Third: there's no application-layer authentication. Any request that gets through Cloudflare WAF will reach the application without any identity verification at the network perimeter.

The Challenge with F5 in a Cloudflare World

Security Gaps

Origin exposure — F5's public IP is discoverable; origin bypass attacks are a real risk
No Zero Trust enforcement — network perimeter model with no per-user, per-device policy
Inbound firewall rules required — open ports expose the server farm to potential attack

Operational Overhead

Dual TLS lifecycle — certificates managed separately on CF edge and F5
F5 licensing cost — ongoing subscription, hardware refresh cycles, specialised skills
Redundant functionality — Cloudflare already proxies traffic; F5 adds latency and complexity for capabilities CF can provide natively

You are already paying for Cloudflare to proxy and protect your traffic — F5 as a middle layer duplicates cost and creates security gaps rather than closing them.

This slide makes the case for change. On the security side: the biggest risk is origin bypass. Once someone discovers the F5's IP — through DNS history tools, certificate transparency logs, or a scan — they can send traffic directly to F5, bypassing Cloudflare's WAF and DDoS entirely. There's also no Zero Trust here: any user who gets through the WAF can access applications without identity verification. The firewall has to have inbound rules open to receive traffic, which is an attack surface. On the operational side: managing TLS in two places means double the renewal work and double the risk of an expiry incident. F5 licensing isn't cheap, and when you already have Cloudflare proxying the traffic, F5 is largely doing things Cloudflare can do natively — adding a hop, adding latency, and adding operational complexity. The pull-quote sums it up: you're paying twice for the same capabilities.

The Solution

Cloudflare Replaces F5 — Component by Component

Cloudflare Tunnel

Replaces F5 reverse proxy & inbound connectivity

cloudflared daemon
outbound-only
no public IP needed

CF Load Balancer

Replaces F5 load balancing & health checks

active-active pools
geo-steering
health monitors

Cloudflare Access

Adds identity-aware auth (replaces F5 APM)

IdP integration
per-app policies
Zero Trust JWT

CF SSL / TLS

Replaces F5 certificate management

Universal SSL (free)
Total TLS
auto-renewal

Net result: F5 is entirely removed from the ingress path. Your server farm is no longer reachable from the public internet — only Cloudflare's network can reach your servers, via outbound tunnel connections your servers initiate.

This slide maps F5 functionality to Cloudflare equivalents one-for-one. Cloudflare Tunnel replaces F5's role as a reverse proxy and ingress point — but instead of accepting inbound connections, cloudflared daemons on your servers initiate outbound-only connections to Cloudflare. Cloudflare Load Balancer replaces F5's load balancing, including active health checks and traffic steering. Cloudflare Access adds identity-aware authentication — this is something F5 APM can do, but most customers don't have it configured. And Cloudflare SSL/TLS replaces certificate management on F5 — with automated renewal. The key outcome highlighted at the bottom is the most important security improvement: your server farm is no longer reachable from the internet. The tunnel is outbound-only, which means you can drop all inbound firewall rules. Nothing can reach your servers except traffic that flows through Cloudflare's network via the tunnel.

End State Architecture

End Users

Cloudflare Edge

Access

WAF

TLS

Encrypted

Tunnel

cloudflared

outbound only

Server Farm

Private · No public IP

Firewall: ALL inbound BLOCKED · outbound 7844 only

F5 removed — no public IP, no inbound holes, attack surface eliminated

Access enforced at edge — identity checks before traffic reaches your network

Single TLS layer — cert lifecycle fully managed by Cloudflare, auto-renewed

This is the target end state. The architecture is fundamentally different from the current state in one critical way: there are no inbound connections to your server farm at all. The cloudflared daemon on your servers — or on a dedicated proxy host — initiates outbound-only connections to Cloudflare on port 7844. These become the persistent tunnel. All traffic flows over these tunnels, so your firewall can block everything inbound and only allow that single outbound port. The Cloudflare edge now handles everything: WAF, DDoS, the Load Balancer, TLS termination, and Access authentication. Only requests that pass all of these checks are forwarded through the tunnel to your servers. F5 is gone. The three green ticks summarise the outcomes: the attack surface is eliminated, identity is enforced at the edge, and certificate management is consolidated and automated.

Tunnel Topology: Two Deployment Models

Option A

cloudflared on Every Server

svr1

svr2

svr3

→

CF LB

Fine-grained per-server health checks
Session affinity per-server possible
N tunnels to manage — higher ops overhead
Separate UUID per server required for LB affinity

Option B ★ Recommended

Dedicated Proxy Server(s)

cloudflared
replica 1

cloudflared
replica 2

→

server farm

Simplest migration path — mirrors existing F5 topology
Run 2+ replicas for HA — each makes 4 connections to CF
Single tunnel config — all app routes in one place
Replicas on same UUID = single LB endpoint (no per-replica affinity)

Each cloudflared instance creates 4 persistent connections to at least 2 distinct Cloudflare data centres — redundancy is built in.

There are two main ways to deploy cloudflared. Option A puts a cloudflared daemon on every application server. Each server gets its own tunnel UUID. This gives you very granular control — the Cloudflare Load Balancer can health-check each server independently, and you can achieve per-server session affinity. The downside is operational complexity: you have N tunnels to manage, one per server. Option B — which I recommend for initial deployment — uses a dedicated proxy server or pair of servers running cloudflared, mirroring how F5 currently sits in front of the server farm. The cloudflared instances proxy traffic internally to the app servers by private IP or hostname. You run two replicas for HA, each making 4 outbound connections to Cloudflare. The operational model is much simpler, and it's an easy cut-over from F5 since you're just swapping the proxy. The note at the bottom is important: every cloudflared instance, regardless of which option, establishes 4 connections to at least 2 different Cloudflare data centres. This built-in redundancy means that even if a Cloudflare PoP goes down, your tunnel stays up.

Load Balancing: Replacing F5 LTM

How It Works with Tunnel

Tunnel endpoint address

<UUID>.cfargotunnel.com

Host header override — tells cloudflared which app route to serve

Header: Host: app.example.com

DNS CNAME update

app.example.com → lb.example.com (LB hostname)
Previously pointed to F5 IP — now points to CF LB

Capabilities

Active-Active — multiple tunnel UUIDs per pool, traffic distributed across all

Active-Passive failover — primary pool + fallback pool, automatic failover

Health monitors — HTTPS monitors with host-header override per app

Geo-steering & latency routing — route users to nearest healthy origin

TCP monitors not supported for tunnel endpoints — use HTTPS monitor with HTTP_STATUS 200 health-check route

This slide covers the Load Balancer integration with Cloudflare Tunnel. The important thing to understand is that you can't add app.example.com directly as a Load Balancer endpoint when it's behind a tunnel — instead, you use the tunnel's UUID subdomain on cfargotunnel.com as the endpoint address, and you set the host header to the application hostname. Cloudflare will use the host header to select the correct cloudflared route. On the capabilities side: active-active gives you the equivalent of F5's round-robin across a pool — you need separate tunnel UUIDs for each endpoint in the pool. Active-passive works with a single UUID per pool as primary and fallback. Health monitoring works, but there's one gotcha: TCP monitors are not supported for tunnel endpoints. You need to create a dedicated HTTPS health-check route in cloudflared that returns a 200, and point your monitor at that. This is a simple configuration but easy to miss. Geo-steering and latency-based routing are available as well, which is particularly useful if you have servers in multiple regions.

TLS Management & Zero Trust Access

SSL / TLS Management

Universal SSL — free, auto-issued for your zone. Covers apex + one wildcard level

Total TLS — automatically issues certificates for all subdomain levels. Eliminates manual cert work entirely

Origin certs optional — tunnel traffic is encrypted end-to-end by cloudflared. Origin servers don't need public certificates

Custom cipher suites & min TLS version — configurable per zone for compliance requirements

Cloudflare Access

Identity-aware proxy — policies enforced at the Cloudflare edge before traffic reaches your network

IdP integration — Azure AD, Okta, SAML, OIDC, Google. Single sign-on for all apps

Per-app policies — group membership, device posture, geo, MFA enforcement per application

⚡ Enable "Protect with Access" in Tunnel settings — cloudflared validates the JWT so even misconfigured bypasses are blocked at origin

Two topics on this slide — TLS management and Cloudflare Access. On TLS: Cloudflare's Universal SSL covers most use cases for free. If you have multi-level subdomains (like dev.app.example.com), you'll need Total TLS, which automatically issues certificates for every subdomain. The critical point here is that because cloudflared creates an encrypted tunnel, your origin servers don't need public-facing TLS certificates at all — the encryption is handled by cloudflared on the way to Cloudflare. You can run plain HTTP between cloudflared and your app servers on the LAN if you choose, although best practice is to use Cloudflare Origin CA certificates for the internal leg. On Access: this is where the architecture becomes genuinely superior to F5. Access enforces identity policies at the Cloudflare edge — before any traffic touches your network. You integrate with your existing IdP (Azure AD, Okta, whatever you use), define per-application policies, and users go through SSO. The important tip at the bottom: enable "Protect with Access" in the Tunnel configuration. This makes cloudflared validate the Cloudflare JWT on every request, so even if someone somehow routes traffic directly to cloudflared — perhaps through a network misconfiguration — their request will be rejected at the daemon level.

Migration Plan

Phase 1 — Parallel Deployment Zero Risk

Actions

Deploy cloudflared on dedicated proxy host(s)
Create tunnel with published routes for each application
Configure Cloudflare Load Balancer pools using tunnel UUIDs
Create Access applications and connect IdP
Verify firewall allows outbound port 7844 from cloudflared hosts
Test each app via tunnel UUID directly — <UUID>.cfargotunnel.com

State

Users

CF Edge

Farm

F5 still serves live traffic · Tunnel tested in parallel

Rollback: Nothing to roll back — F5 is untouched. Stop cloudflared and remove test DNS entries.

Phase 1 is entirely non-destructive. You're building the Cloudflare side in parallel while F5 continues to serve all live traffic. Deploy cloudflared on a dedicated host — or two for HA — and configure your tunnel routes for each application. Set up the Cloudflare Load Balancer, create your Access applications and connect your IdP. Before anything goes live, verify the firewall: cloudflared needs outbound TCP port 7844 to reach Cloudflare. Then test each application by accessing it via the tunnel UUID directly — Cloudflare generates a cfargotunnel.com subdomain for each tunnel that you can use for testing without touching DNS. This is the validation phase. If anything isn't working, rollback is trivial: stop cloudflared, there's nothing to revert. F5 has been untouched throughout.

Phase 2 — DNS Cutover Low Risk

Actions

Update DNS CNAMEs — change from F5 IP to CF Load Balancer hostname
Monitor application logs and CF analytics for any errors
Validate Access policies — confirm users authenticate correctly
Test all application endpoints and critical user journeys
Keep F5 live and accessible — it is the rollback target
Run in this state for a defined soak period (e.g. 1–2 weeks)

Before: app.example.com → 10.x.x.x (F5 IP)
After: app.example.com → lb.example.com (CF LB)

State

Users

CF Edge

F5 (standby)

LIVE

Farm

Tunnel carries live traffic · F5 on standby as instant rollback

Rollback: Single DNS change — revert CNAMEs back to F5 IP. <60 second TTL recommended during cutover window.

Phase 2 is the actual cutover, but it's a single DNS change. You update the CNAME records for each application from the F5 IP address to the Cloudflare Load Balancer hostname. DNS TTL should be lowered to 60 seconds before the change so propagation is fast. After the change, live traffic flows through Cloudflare Tunnel. F5 stays fully configured and operational — it's your instant rollback. If anything goes wrong, one DNS change rolls you back within 60 seconds. Monitor application logs, Cloudflare analytics, and run through critical user journeys. Validate that Access policies are working — users should be prompted to authenticate with your IdP. Run in this state for a soak period before proceeding to Phase 3. I recommend at least one to two weeks to be confident before decommissioning F5.

Phase 3 — Decommission F5 Final State

Actions

Confirm zero residual traffic hitting F5 — check F5 access logs
Tighten server farm firewall — block ALL inbound, allow only outbound 7844
Remove F5 from DNS entirely and revoke public IP allocation
Cancel F5 licensing / maintenance contracts
Remove F5 TLS certificates and certificate renewals from runbooks
Repurpose or decommission F5 hardware / VM

Final State

Users

CF Edge

Tunnel

Private · No public IP

F5 decommissioned · Zero inbound attack surface

F5 licensing
✓ Cancelled

Manual cert renewals
✓ Eliminated

Phase 3 is decommissioning. Before you touch F5, verify it's receiving zero traffic — check the F5 access logs and confirm the numbers are zeroed out. Then tighten the server farm firewall: drop all inbound rules and allow only outbound TCP 7844 from the cloudflared hosts. This is the security win — your origin is now completely unreachable from the public internet. Remove F5 from DNS, revoke the public IP, cancel the licensing and maintenance contracts, and remove the cert renewal runbooks. What you're left with is the final state diagram on the right: a clean, simple architecture with no F5, no public IP, no inbound attack surface. The two tiles at the bottom remind you of the immediate operational wins: F5 licensing is cancelled, and manual certificate renewals are gone. Both of those represent real cost and toil savings.

Business Case

Pros & Cons

Advantages

Zero inbound attack surface — servers are not reachable from the internet at all. Eliminates origin bypass attacks.

Identity-aware access control — Zero Trust policies enforced at edge, per-app, per-user, per-device

Reduced operational complexity — one platform to manage (Cloudflare), no F5 iRules, no dual cert lifecycle

Cost reduction — F5 licensing, hardware refresh and specialist skills eliminated

Safe, reversible migration — three phases, F5 live as fallback, DNS rollback <60 seconds

Considerations

CF Load Balancer is a paid add-on — cost must be evaluated against F5 licensing savings (almost always net positive)

Complex F5 iRules need review — most standard rules map to CF Rules, but bespoke logic requires individual assessment

Session affinity constraints — per-host affinity requires separate tunnel UUIDs, adds management overhead

Multi-level subdomain certs — require Advanced Certificates (not covered by Universal SSL free tier)

cloudflared dependency — a new daemon to operate and keep updated on cloudflared hosts

Let's be balanced here. On the advantages: the security improvement is substantial and hard to overstate — your origin servers disappear from the internet entirely. Zero Trust access via Cloudflare Access is a capability most customers don't currently have on F5 (F5 APM is an additional licence that many don't use). Operational simplicity is real — one platform to manage instead of two. Cost savings from eliminating F5 licensing. And the migration is genuinely low-risk. On the considerations: CF Load Balancing is a paid add-on — pricing is per origin per month, so you need to model the cost against F5 savings. In virtually every case I've seen, the net is strongly positive. Complex iRules are the area most likely to require custom work — if you have bespoke traffic manipulation logic in F5, we need to audit those and map them to Cloudflare Rules equivalents. Session affinity is solvable but requires separate tunnel UUIDs per origin, which adds some management complexity. Multi-level subdomains need an Advanced Certificate. And cloudflared is a new daemon to manage — it needs to be kept updated, monitored, and included in your patching process.

Business Benefits

Reduced Security Risk

Origin servers become unreachable from the internet. Zero Trust policies enforce identity and device trust on every request. Eliminates a category of attack entirely.

Cost Savings

Eliminate F5 licensing, maintenance contracts, hardware refresh cycles, and specialist F5 engineering costs. Consolidate spend into Cloudflare.

Operational Simplicity

One platform, one dashboard, one support contract. TLS certificates auto-renew. No iRule maintenance. Faster onboarding of new applications.

Compliance & Audit

Cloudflare Access creates a full audit trail of who accessed which application, when, from which device. Strengthens posture for SOC 2, ISO 27001, and similar frameworks.

Performance

Remove a hop from the traffic path. Cloudflare's Anycast network routes users to the nearest PoP. Argo Smart Routing available for further optimisation.

Scalability

Cloudflare's global network absorbs traffic growth and DDoS attacks at scale. No hardware capacity planning for load balancers. Add new applications in minutes.

Six business benefits to call out. Security: this is the headline. Moving to outbound-only tunnel with Zero Trust access represents a fundamental improvement in security posture — it's not an incremental improvement, it's a category change. Cost: F5 BIG-IP licensing is significant. Combined with hardware, maintenance, and the cost of specialist F5 engineers, the savings from elimination are substantial. Model this specifically for your environment — in most cases it fully pays for the Cloudflare Zero Trust licences with money to spare. Operational simplicity: instead of managing F5 + Cloudflare as two separate platforms, your team manages one. Certificate expiry incidents go away because Cloudflare handles renewal automatically. Compliance: Cloudflare Access creates a detailed access log that maps directly onto requirements in SOC 2, ISO 27001, NIST, and similar frameworks. This is evidence you can present to auditors without any additional tooling. Performance: removing F5 as a hop reduces latency. Cloudflare's 300+ PoP network means users are served from a PoP close to them. Scalability: Cloudflare's network is effectively elastic — you're not capacity-planning for F5 hardware anymore.

F5 → Cloudflare: Feature Replacement Matrix

F5 Capability	Cloudflare Equivalent	Coverage
L7 Load Balancing	Cloudflare Load Balancing	✓ Full
SSL/TLS Termination	Universal SSL / Advanced Certs	✓ Full
Reverse Proxy / Ingress	Cloudflare Tunnel (cloudflared)	✓ Full + Better
Application Auth (APM)	Cloudflare Access	✓ Full + Better
WAF / DDoS	CF WAF / DDoS (already active)	✓ Already in place
Health Checks	CF LB Monitors (HTTPS)	~ HTTPS only*
Session Persistence	CF LB Session Affinity	~ Separate UUIDs req'd
Geo / Latency Routing	CF LB Traffic Steering	✓ Full
Certificate Management	Total TLS / Cert Manager	✓ Full + Auto-renew
iRules / Traffic Scripting	CF Rules / Transform Rules	~ Review required

* TCP monitors not supported for tunnel endpoints — use HTTPS health-check route in cloudflared

This is the at-a-glance feature parity table. Green ticks mean full replacement, amber tildes mean partial or with caveats. L7 load balancing, TLS termination, reverse proxy/ingress, application auth, WAF/DDoS, geo routing, and certificate management are all fully covered. The three amber items to discuss: Health checks are HTTPS-only for tunnel endpoints — you set up a dedicated health-check route in cloudflared, it's a small config task but needs to be planned. Session persistence works but requires separate tunnel UUIDs per origin if you need per-host affinity. iRules are the main variable — standard redirect, header manipulation, and routing rules map directly to Cloudflare Transform Rules and Page Rules. If you have complex custom iRules, we'd need to audit those in a discovery workshop and map each one to a Cloudflare Rules equivalent. In my experience the vast majority can be replaced, but some very complex ones may require Cloudflare Workers for equivalent logic.

Key Risks & Gotchas

Session Affinity & Replicas

Replicas sharing a tunnel UUID = single LB endpoint. Separate UUIDs required per server for per-host affinity. Plan this upfront.

Port 7844 Firewall Rule

cloudflared requires outbound TCP 7844. Verify connectivity before Phase 1 using CF's pre-check tool. Blocking this port = no tunnel.

Multi-Level Subdomain Certs

dev.app.example.com style hostnames require Advanced Certificates (paid). Universal SSL covers only one subdomain level.

Access Token Bypass

Always enable "Protect with Access" in Tunnel settings. This makes cloudflared validate the CF JWT — blocking requests that bypass Access via network misconfiguration.

Anycast Local Preference

cloudflared prefers serving requests via PoPs in the same region. With geographically distributed endpoints, traffic imbalances can occur — review LB steering policies.

Create Access App Before Tunnel Route

If you publish a tunnel route before creating the Access application, the app is publicly accessible to anyone. Always configure Access policies first.

Six gotchas to be aware of — all manageable with planning. Session affinity: if your applications require users to stick to a specific server, you need separate tunnel UUIDs per server and then use Cloudflare LB session affinity. This is solvable but needs to be designed upfront. Port 7844: this is the most common deployment blocker. Test outbound TCP 7844 before anything else. Cloudflare has a connectivity pre-check command in cloudflared — run it on your intended cloudflared hosts during Phase 1 planning. Multi-level subdomains: if any of your apps use more than one level of subdomain, for example dev.api.example.com, order an Advanced Certificate before Phase 2 cutover. The Access token bypass: this is a security best practice, not optional. Enable "Protect with Access" in the Tunnel configuration so cloudflared double-checks the JWT. Anycast local preference: if you have cloudflared replicas in different geographic locations, Cloudflare's Anycast routing may send disproportionate traffic to the nearest PoP. Monitor your LB analytics and tune traffic steering policies accordingly. And finally — always create your Access application before publishing the tunnel route. If you do it the other way around, there's a window where the application is live on the internet with no authentication.

Recommended Next Steps

iRules Discovery Workshop

Audit all F5 iRules and Virtual Server configs. Map each to a Cloudflare Rules equivalent. Identify any requiring custom Workers logic.

Application Inventory

List all applications behind F5, their hostnames, subdomain structure, and any session affinity requirements. This drives tunnel and LB design.

IdP Integration Planning

Identify your identity provider (Azure AD, Okta, etc.) and plan the Cloudflare Access integration. Define initial access policies per application.

Firewall & Connectivity Verification

Verify outbound TCP 7844 is permitted from the intended cloudflared hosts. Run Cloudflare's connectivity pre-check tool on each host.

Proof of Concept

Deploy cloudflared in a non-production environment. Validate tunnel connectivity, LB health checks, Access authentication, and application routing end-to-end.

Cloudflare SE-Led PoC

We can run a structured PoC — Cloudflare provides technical resources to validate all requirements before any production commitment.

Six concrete next steps to get moving. Step 1 — iRules discovery. Before any deployment work, we need to understand what F5 is actually doing with traffic beyond basic load balancing. An iRules audit is the most important pre-work item. Step 2 — application inventory. Document every app behind F5: the hostname, subdomain depth, whether it needs session affinity, what protocol it uses. This is the input to the tunnel and LB design. Step 3 — IdP planning. Figure out what identity provider you're connecting to Cloudflare Access, and start planning access policies. This can run in parallel with the technical deployment. Step 4 — firewall verification. Run cloudflared's connectivity pre-check on your intended cloudflared hosts before Phase 1. This takes 5 minutes and eliminates the most common deployment blocker. Step 5 — PoC. Spin up cloudflared in a non-production environment, validate the full stack end-to-end before touching production. Step 6 — and this is the call to action — Cloudflare can run a formal PoC alongside you. We provide technical resources, documentation, and support throughout. There's no production commitment required to run a PoC. I'd suggest starting with Steps 1 and 2 as homework from this meeting, and we can schedule a discovery workshop to go through the findings together and build the detailed design.

Download PDF