In high-throughput enterprise architectures, F5 BIG-IP Local Traffic Manager (LTM) functions as the application delivery backbone. As cryptographic requirements evolved from RSA to elliptic curves (ECDHE) and TLS 1.3, managing TLS termination, inspection, and backend offloading became a critical discipline for network security engineers.
Unlike cloud proxies designed strictly for outbound user inspection, F5 BIG-IP operates inside datacenters and hybrid clouds to optimize inbound application traffic across three core operational models: SSL Offload (Termination), SSL Bridging (Re-encryption), and SSL Passthrough (Layer 4 Forwarding).
F5 BIG-IP SSL Handshake Architecture
Switch between SSL Offload, Bridging, and Passthrough to simulate handshake flows
10.0.0.55
203.0.113.1:443
192.168.1.10:80
Client SSL Profile
Attached to VIP. Terminates client TLS handshake, negotiates ciphers (TLS 1.3 / ECDHE), and manages SSL offloading.
Server SSL Profile
Used in SSL Bridging. F5 acts as a TLS client, establishing a new encrypted session to backend servers with optional cert verification.
Virtual Server (VIP)
The primary traffic listener IP:Port. Applies iRules, HTTP profiles, and persistence records upon connection establishment.
iRules Event Engine
Executes TCL event triggers (CLIENTSSL_HANDSHAKE, HTTP_REQUEST) for header enrichment and dynamic pool routing.
The Three Core F5 SSL Architectures
1. SSL Offload (SSL Termination)
In SSL Offload, F5 handles all computational crypto operations at hardware speed. The client negotiates an encrypted TLS session with F5's Virtual Server (VIP). F5 decrypts the payload and delivers unencrypted HTTP (port 80) across the trusted internal datacenter LAN to backend pool members.
- CPU Relief: Web servers save up to 40% CPU overhead previously spent performing RSA/ECDHE key exchanges.
- Header Enrichment: F5 inserts
X-Forwarded-For: [Client-IP]andX-Forwarded-Proto: httpsso backends retain full client visibility. - Content Inspection: F5 Advanced WAF (ASM) can inspect plaintext HTTP requests before forwarding to web pools.
2. SSL Bridging (Two-Legged Re-Encryption)
In regulated sectors (banking, healthcare, PCI-DSS, HIPAA), corporate security policies prohibit unencrypted plaintext traversal even across private VLANs. SSL Bridging establishes two separate TLS sessions:
- Session 1 (Client ↔ F5 VIP): Handled by the Client SSL Profile with public enterprise certificates.
- Session 2 (F5 ↔ Backend Server): Handled by the Server SSL Profile with internal CA certificates on port 443.
This allows F5 to inspect Layer 7 traffic and run iRules in RAM while guaranteeing zero-plaintext exposure across internal network links.
3. SSL Passthrough (Layer 4 Forwarding)
When the backend application manages proprietary TLS certificates, or requires mutual authentication (mTLS) where F5 does not possess private keys, F5 operates in SSL Passthrough mode.
Traffic is forwarded at Layer 4 without decryption. However, using F5's clientssl peek iRule feature, F5 can parse the unencrypted Server Name Indication (SNI) from the ClientHello packet to route traffic to the appropriate backend pool without terminating the TLS session.
F5 vs Zscaler: Architectural Comparison
F5 BIG-IP is an inbound application delivery controller engineered for server offloading, high availability, and localized WAF protection. Zscaler ZIA is an outbound cloud proxy engineered for zero-trust endpoint protection, threat intelligence, and data loss prevention.
Production Best Practices for F5 Administrators
- ✓ Always Configure HTTP Profile with X-Forwarded-For: Ensures backend logs record real client IP addresses instead of the F5 Self-IP.
- ✓ Harden Cipher Suites: Disable legacy SSLv3, TLS 1.0, TLS 1.1, and CBC ciphers; prioritize GCM and CHACHA20-POLY1305 with Forward Secrecy.
- ✓ Implement SSL Session ID / Ticket Caching: Speeds up reconnections by skipping full cryptographic handshakes for returning clients.