Along time ago in a land far far away...
I discovered F5 networks, learnt the product suite , taught the training, became an MVP and started an online discussion group in Telegram which was popular back in the day. The world has changed and security has become far more of an issue than it ever was. It seemed the only way to access a resource reliably outside the business was by using the web. So now everthing uses it and its various protocols so pass messaging back and forth around the world. From SAML to OAuth it is all built on the same basic framework and that is why my little commumity had to evolve. I present to you a new space, accessed over the web, cloud backed and accessible to everyone. Complimentary to the user expereience here just more an interactive level. Feel free, feel welcome and enjoy. https://discord.gg/YzDtk9HXXn Only a browser is required for the desktop, choose "Open In Browser". There is an app available for mobile platforms. Feel free to provide any feedback in the suggestions channel on the site or even to this post.AppWorld Berlin 2026 – iRules Contest Winning Results
The second iRules Contest of the year wrapped up at AppWorld Berlin this week. This contest was looking towards the future, challenging participants to write an iRule that goes beyond BIG-IP’s built-in capabilities. The theme, using WebSockets or the Message Routing Framework, inspired iRules preventing abuse and intrusion. At the heart of it, we’ve loved the creative innovation of the iRules written for this years’ contests. The AppWorld Berlin iRules Contest submissions were inspiring. Across the board, judges’ feedback on the top contenders shared a common theme: these solutions are interesting. The winning iRules were well-documented, easy to understand, with clear potential value for production use. Without further ado, we’re proud to announce the winners of the AppWorld Berlin iRules Contest: Grand Prize Winner - Goerle_dev Rule: WS-Exfil-Shield: Catching What WAFs Miss After the 101 Handshake Summary This iRule addresses gaps in traditional WAFs by extending session-level, behavior-based threat detection to WebSocket traffic using real-time inspection within F5 BIG-IP. Detection operates in two stages; an initial timing-based heuristic is followed by payload validation using AI. Malicious actors are either blocked or routed to a honeypot for isolation and further observation. This iRule closes the gap that openly documented by major WAF vendors, post-handshake Websocket blind spot, with a practical, SIEM-ready enforcement. 2nd Place - Injeyan_Kostas Rule: WS-Shield: WebSocket Abuse Detection & Adaptive Enforcement Gateway Summary This iRule addresses securing WebSocket traffic by enabling real-time, behavior-based enforcement in F5 BIG-IP to proportionally mitigate abusive patterns without application changes. It introduces a behavioral enforcement engine designed to secure WebSocket traffic with adaptive, real-time mitigation without requiring application changes. Rather than relying on static thresholds, the system dynamically responds to behavior. Clean traffic naturally recovers, while abusive patterns escalate through enforcement tiers until they are cut off. This allows it to detect subtle, persistent attacks that traditional rate limiting often misses. In testing, the iRule identified and disconnected a bot sending repetitive payloads every half second, without triggering a rate threshold. The iRule adds an extensible, behavior-driven security layer that enables adaptable defenses with minimal investment, despite optional external dependencies. 3rd Place - Robb-Fr Rule: Generic iRule Based on Datagroup Parsing Summary This iRule addresses the complexity of migrating large numbers of Apache virtual hosts by centralizing flexible traffic routing and redirection logic within F5 BIG-IP using simple, extensible datagroups. It turns input into a simple form into a datagroup entry that CREATES iRULES for things like redirects, pools, error pages, rewrites, and more. This iRule is accessible to a wide range of F5 practitioners, as F5 expertise is not required. There are no direct iRule edits, and no way for them to break the device. This iRule lowers operational friction by enabling non-NetOps teams to manage complex traffic flows, improving agility during large-scale migrations. Category Awards The 20 Lines or Less Award - Kai_Wilke In honor of Colin Walker - short on lines, long on legend. The scroll bar never stood a chance. Rule: SUPER-WEBSOCKET-HANDSHAKE-LOGGER™® (SWHL) iRule The Layered Defense Award - ChristianEssel For elegant use of nested virtual servers to solve problems the apps won't. Rule: Layered Virtual ICAP Scanning Solution Gratitude A big thank you to all contestants who participated in the AppWorld Berlin iRules Contest. Your creativity, innovation, and willingness to share your ideas continue to push the community forward. Thank you to our judges: John_Alam Joel_Moses Moe_Jartin Chris_Miller Michael_Waechter dennypayne Kevin_Stewart Marcus-f5 SimonKowallik Sorin_Boiangiu Steve Scott Thank you to the DevCentral community. We learn together, grow together, and inspire each other every day. What's Next? Innovation and Creativity have been a key part of the contest rubric. We’re leaning into it, too. As we plan more contests for the year, we’re looking beyond iRules, with potential to expand to all programmability. The future is coming for us all; let’s greet it and move forward together.Single-click CDN Experience for F5 Distributed Cloud Load Balancers
Fundamentals The modern CDN has evolved well beyond cache and serve. Today’s platforms are intelligent edge fabrics that combine performance optimization, layered security, multicloud routing, and even workload execution at the edge. Few products embody this evolution more completely than F5 Distributed Cloud CDN, and this post explores both why CDNs matter and what sets F5’s newest approach apart. At its core, a CDN is a globally distributed system of edge servers, called PoPs or Regional Edges (RE), that cache content and handle user requests on behalf of the server origin. When a user requests a resource, DNS resolution routes them to the nearest PoP. If the resource is cached there (a “cache hit”), it’s returned immediately. If not (a “cache miss”), the PoP fetches it from the origin, stores it, and returns it to the user. The speed improvement isn’t just perceptual. Reduced Round-Trip Time (RTT) correlates directly with business outcomes. Every page load shaved makes a difference for search rankings, checkout completion, and ad viewability all improve with lower latency. CDNs don’t just make things faster; they make digital businesses more competitive. To put the difference in concrete terms, here’s how a typical 200KB page might deliver across different scenarios. Platform deep dive Traditional CDNs optimize for one thing: getting cached bytes to users fast. Distributed Cloud CDN starts there but doesn’t stop, it's engineered as a unified platform where content delivery, application security, multicloud connectivity, and edge compute converge under a single operational surface. F5’s approach is architecturally distinct Most CDNs are standalone services that organizations integrate with separate security tools, load balancers, and observability stacks. The operational overhead of stitching these together and keeping policies consistent across them is substantial. F5 takes a different approach: CDN is one capability within the broader Distributed Cloud Platform, meaning it inherits the platform’s DNS, load balancing, WAF, observability, and multicloud networking services. The practical result, noted by enterprise users, is that WAF rules, DDoS policies, and CDN configurations all live in the same console. There’s no context switching between vendors, no policy drift between your security tool and your delivery tool, and no blind spots at the handoff between them. In the newest product update, anyone already using a Distributed Cloud Load Balancer can enable CDN acceleration with a single click: no rearchitecting, no new deployments. Built-in cacheability insights estimate performance improvement and cost savings before activation, so teams can make informed decisions without guesswork. Target use cases: Where F5 Distributed Cloud CDN fits best There are three primary use-case families for enabling an integrated CDN: Secure apps everywhere (WAAP + CDN): Organizations that need comprehensive web app and API protection with WAF, DDoS, bot defense, unified content delivery under a single policy plane and management console. Modern digital experiences: Dynamic, personalized applications spanning multiple public clouds, edge locations, and on-premises infrastructure that need consistent delivery regardless of where origin workloads live. Multicloud & edge initiatives: Enterprises migrating workloads across cloud providers or deploying edge compute who need a platform that bridges delivery, security, and service mesh without re-platforming for each environment. Visibility & Control: You can’t optimize what you can’t see F5’s Distributed Cloud Platform ships with unified observability that spans delivery performance and security posture. Real-time dashboards expose traffic patterns, cache efficiency metrics, origin health, and security event timelines, all from the same interface used to configure policies. Cache efficiency isn’t a static attribute either. Distributed Cloud CDN provides granular control over cache keys, TTL values, and path or header-based caching rules, enabling teams to optimize hit rates for specific content types and access patterns. Cacheability insights indicate which web apps are candidates for acceleration. For security operations, the edge generates rich telemetry: request rates, blocked attack types, geographic traffic distribution, and bot classification outcomes. This feeds into the same observability layer as performance data, giving teams a single pane of glass rather than separate dashboards for CDN and security. The recently announced F5 Insight capability extends this further, bringing OpenTelemetry-powered observability across BIG-IP, NGINX, and Distributed Cloud Services, consolidating performance and security intelligence across an organization’s entire F5 footprint into actionable, unified visibility. Demo Walkthrough Final thoughts A CDN is no longer an optimization. It’s table stakes for any organization serving digital experiences to a geographically distributed audience. The question isn’t whether to deploy one, but which platform best aligns with the complexity of your architecture and the ambition of your security posture. For organizations operating at the intersection of multicloud delivery, API-driven applications, and enterprise security requirements, Distributed Cloud CDN represents a compelling architectural choice: a platform that treats performance and security not as separate concerns to be stitched together, but as integrated properties of the same edge fabric. The bytes will always need to get from somewhere to your users. F5 makes that journey faster, safer, and smarter. Additional Resources Product information: https://www.f5.com/products/distributed-cloud-services/cdn Technical documentation: https://docs.cloud.f5.com/docs-v2/content-delivery-network/how-to/cdn-mgmt/conf-cache-lb Feature announcement blog: https://www.f5.com/company/blog/f5-distributed-cloud-cdn-faster-apps-one-click-enablement-lower-costs
Win Big in Vegas: The iRules Contest is back with $5k on the line at AppWorld 2026
Hey there, community, iRules Contest here...did you miss me? Well I’m back in business, baby, in Vegas, no less! At AppWorld 2026, we’re challenging DevCentral community members in attendance to design and build innovative iRules that solve real-world problems, improve performance, and enhance customer experiences. Whether you’re a seasoned iRules veteran or just getting started, we can’t wait to see what you create. Note: participation in this edition of the iRules Contest is limited to AppWorld 2026 attendees. But fear not! We’re hitting the road this year as well. The Challenge Plan out and write an iRule that go beyond BIG-IP’s built-in capabilities. Think of the future: the possibilities are wide open. We’ll drop a couple hints leading up to the event, and you’ll have a final hint in your registration swag bag, so keep your eyes peeled. There might even be a hint in an iRules related article to release this week, who knows? $5,000 to the Grand Prize Winner -- Are You In? Total prize money is $10,000, with the other $5,000 distributed across 2nd place, 3rd place, and five category awards. Place Prize Grand Prize $5,000 2nd Place $2,500 3rd Place $1,000 Five Category Awards $300/ea What Makes for a Winning Entry? The 100-point scale judging criteria for submissions is defined below across five categories: Innovation & Creativity (25 points) Does this solution show original thinking? Consider: Novel use of iRule features or creative problem-solving Fresh perspective on common challenges Unique approach that stands out from typical solutions Business Impact (20 points) Would customers actually use this? Consider: Solves a real operational problem or customer need Practical applicability and potential adoption Clear business value Technical Excellence (25 points) Is it well-built and production-ready? Consider: Works correctly and handles edge cases Performance-conscious (efficient, minimal resource impact) Follows security best practices Clean, readable code Theme & Requirements Alignment (20 points) Does it address the contest theme using required technologies (to be announced at the event)? Consider: Relevance to the specified theme Effective use of required technology How well the chosen technology fits the solution Presentation (10 points) Can you understand what it does and why it matters? Consider: Clear explanation of the problem and solution Quality of demo or presentation Documentation sufficient to implement Important Dates Contest Opens: 6:00PM Pacific Time MARCH 10, 2026 Submission Deadline: 11:59PM Pacific Time MARCH 10, 2026 Winners Announced: MARCH 12, 2026 during general sessions How to Enter Register for AppWorld 2026 — You must be a registered attendee Register for the Contest — Registration will open on the AppWorld event app soon. The contest is open to all f5 partners, customers, and DevCentral members registered for and in attendance at the contest MARCH 10, 2026 at F5 AppWorld 2026, except as described in the Official Rules. Please see the Official Rules for complete terms, including conditions for participation and eligibility. Build and submit — During the 6-hour window on contest night before 11:59PM. Edit your draft entry as much as you like, but once you submit, that’s what we’ll review. There is an example entry pinned at the top of the Contest Entries page you should follow. Make sure to add these tags to your entry: "appworld 2026", "vegas", and "irules" as shown on that example. This contest is BYOD. Bring your own device to develop and submit your iRules submission. However, a lab environment in our UDF platform will be provided if you need a development environment to test your code against. New to iRules? No problem. We welcome participants at all skill levels. If you’re just getting started, check out our Getting Started with iRules: Basic Concepts guide. This contest is a great opportunity to learn by doing. Also, feel free to bring your favorite AI buddy with you to help craft your entry. The goal is innovation and impact, not syntax expertise. Questions? Post any and all of your contest-related questions to the pinned thread in the Contests group on DevCentral. We’ll monitor, but allow for a business day to receive a response leading up to AppWorld. The iRules Contest has a history of surfacing creative solutions from the community. Some of the best ideas we’ve seen came from people who approached problems differently, and we’re looking forward to seeing what you build this year. Register. Prepare. Compete. See you at AppWorld!VMware VKS integration with F5 BIG-IP and CIS
Introduction vSphere Kubernetes Service (VKS) is the Kubernetes runtime built directly into VMware Cloud Foundation (VCF). With CNCF certified Kubernetes, VKS enables platform engineers to deploy and manage Kubernetes clusters while leveraging a comprehensive set of cloud services in VCF. Cloud admins benefit from the support for N-2 Kubernetes versions, enterprise-grade security, and simplified lifecycle management for modern apps adoption. Alike with other Kubernetes platforms, the integration with BIG-IP is done through the use of the Container Ingress Services (CIS) component, which is hosted in the Kubernetes platform and allows to configure the BIG-IP using the Kubernetes API. Under the hood, it uses the F5 AS3 declarative API. Note from the picture that BIG-IP integration with VKS is not limited to BIG-IP´s load balancing capabilities and that most BIG-IP features can be configured using this integration. These features include: Advanced TLS encryption, including safe key storage with Hardware Security Module (HSM) or Network & Cloud HSM support. Advanced WAF, L7 bot and API protection. L3-L4 High-performance firewall with IPS for protocol conformance. Behavioral DDoS protection with cloud scrubbing support. Visibility into TLS traffic for inspection with 3 rd party solutions. Identity-aware ingress with Federated SSO and integration with leading MFAs. AI inference and agentic support thanks to JSON and MCP protocol support. Planning the deployment of CIS for VMware VKS The installation of CIS in VMware VKS is performed through the standard Helm charts facility. The platform owner needs to determine beforehand: Whether the deployment is hosted on a vSphere (VDS) network or an NSX network. It has to be taken into account that on an NSX network, VKS doesn´t currently allow to place the load balancers in the same segment as the VKS cluster. No special considerations have to be taken when hosting BIG-IP in a vSphere (VDS) network. Whether this is a single-cluster or a multi-cluster deployment. When using the multi-cluster option and clusterIP mode (only possible with Calico in VKS), it has to be taken into account that the POD networks of the clusters cannot have overlapping prefixes. What Kubernetes networking (CNI) is desired to be used. CIS supports both VKS supported CNIs: Antrea (default) and Calico. From the CIS point of view, the CNI is only relevant when sending traffic directly to the PODs. See next. What integration with the CNI is desired between the BIG-IP and VKS NodePort mode This is done by making applications discoverable using Services of type NodePort. From the BIG-IP, the traffic is sent to the Node´s IPs where it is redistributed to the POD depending on the TrafficPolicies of the Service. This is CNI agnostic. Any CNI can be used. Direct-to-POD mode This is done by making applications discoverable using the Services of type ClusterIP. Note that the CIS integration with Antrea uses Antrea´s nodePortLocal mechanism, which requires an additional annotation in the Service declaration. See the CIS VKS page in F5 CloudDocs for details. This Antrea nodePortLocal mechanism allows to send the traffic directly to the POD without actually using the POD IP address. This is especially relevant for NSX because it allows to access the PODs without actually re-distributing the PODs IPs across the NSX network, which is not allowed. When using vSphere (VDS) networking, either Antrea’s nodePortLocal or clusterIP with Calico can be used. Another way (but not frequent) is the use of hostNetwork POD networking because it requires privileges for the application PODs or ingress controllers. Network-wise, this would have a similar behavior to nodePortLocal, but without the automatic allocation of ports. Whether the deployment is a single-tier or a two-tier deployment. A single-tier deployment is a deployment where the BIG-IP sends the traffic directly to the application PODs. This has a simpler traffic flow and easier persistence and end-to-end monitoring. A two-tier deployment sends the traffic to an ingress controller POD instead of the application PODs. This ingress controller could be Contour, NGINX Gateway Fabric, Istio or an API gateway. This type of deployment offers the ultimate scalability and provides additional segregation between the BIG-IPs (typically owned by NetOps) and the Kubernetes cluster (typically owned by DevOps). Once CIS is deployed, applications can be published either using the Kubernetes standard Ingress resource or F5’s Custom Resources. This latter is the recommended way because it allows to expose most of the BIG-IPs capabilities. Details on the Ingress resource and F5 custom annotations can be found here. Details on the F5 CRDs can be found here. Please note that at time of this writing Antrea nodePortLocal doesn´t support the TransportServer CRD. Please consult your F5 representative for its availability. Detailed instructions on how to deploy CIS for VKS can be found on this CIS VKS page in F5 CloudDocs. Application-aware MultiCluster support MultiCluster allows to expose applications that are hosted in multiple VKS clusters and publish them in a single VIP. BIG-IP & CIS are in charge of: Discover where the PODs of the applications are hosted. Note that a given application doesn´t need to be available in all clusters. Upon receiving the request for a given application, decide to which cluster and Node/Pod the request has to be sent. This decision is based on the weight of each cluster, the application availability and the load balancing algorithm being applied. Single-tier or Two-tier architectures are possible. NodePort and ClusterIP modes are possible as well. Note that at the time of this writing, Antrea in ClusterIP mode (nodePortLocal) is not supported currently. Please consult your F5 representative for availability of this feature. Considerations for NSX Load Balancers cannot be placed in the same VPC segment where the VMware VKS cluster is. These can be placed in a separate VPC segment of the same VPC gateway as shown in the next diagram. In this arrangement the BIG-IP can be configured as either 1NIC mode or as a regular deployment, in which case the MGMT interface is typically configured through an infrastructure VLAN instead of an NSX segment. The data segment is only required to have enough prefixes to host the self-IPs of the BIG-IP units. The prefixes of the VIPs might not belong to the Data Segment´s subnet. These additional prefixes have to be configured as static routes in the VPC Gateway and Route Redistribution for these must be enabled. Given that the Load Balancers are not in line with the traffic flow towards the VKS Cluster, it is required to use SNAT. When using SNAT pools, the prefixes of these can optionally be configured as additional prefixes of the Data Segment, like the VIPs. Specifically for Calico, clusterIP mode cannot be used in NSX because this would require the BIG-IP to be in the same VPC segment as VMware VKS. Note also that BGP multi-hop is not feasible either because it would require the POD cluster network prefixes to be redistributed through NSX, which is not possible either. Conclusion and final remarks F5 BIG-IPs provides unmatched deployment options and features for VMware VKS; these include: Support for all VKS CNIs, which allows sending the traffic directly instead of using hostNetwork (which implies a security risk) or using the common NodePort, which can incur an additional kube-proxy indirection. Both 1-tier or 2-tier arrangements (or both types simultaneously) are possible. F5´s Container Ingress Services provides the ability to handle multiple VMware VKS clusters with application-aware VIPs. This is a unique feature in the industry. Securing applications with the wide range of L3 to L7 security features provided by BIG-IP, including Advanced WAF and Application Access. To complete the circle, this integration also provides IP address management (IPAM) which provides great flexibility to DevOps teams. All these are available regardless of the form factor of the BIG-IP: Virtual Edition, appliance or chassis, allowing great scalability and multi-tenancy options. In NSX deployments, the recommended form-factor is Virtual Edition in order to connect to the NSX segments. We look forward to hearing your experience and feedback on this article.What's new in BIG-IP v21.0?
Introduction In November of 2025 F5 released the latest version of BIG-IP software, v21.0. This release is packed with fixes and new features that enhance the F5 Application Delivery and Security Platform (ADSP). These changes complement the Delivery, Security and Deployment aspects of the ADSP. Demo Video: New SSL Orchestrator Features SNI Preservation SNI (Server Name Indication) Preservation is now supported for Inbound Gateway Mode. This preserves the client’s original SNI information as traffic passes through the reverse proxy, allowing backend TLS servers to access and use this information. This enables accurate application routing and supports security workflows like threat detection and compliance enforcement. Previous software versions required custom iRules to enable this functionality. Note: SNI preservation is enabled by default. However, if you have existing Inbound Gateway Topologies, you must redeploy them for the change to take effect. iRule Control for Service Entry and Return Previously, iRules were only available on the entry (ingress) side, limiting customization to traffic entering the Inspection Service. iRule control is now extended to the return-side traffic of Inspection Services. You can now apply iRules on both sides of an Inspection Service (L2, L3, HTTP). This enhancement provides full control over traffic entering and leaving the Inspection Service, enabling more flexible, powerful, and fine-grained traffic handling. The Services page will now include configuration for iRules on service entry and iRules on service return. A typical use-case for this feature is what we call Header Enrichment. In this case, iRules are used to add headers to the payload before sending it to the Inspection Service. The headers could contain the authenticated username/group membership of the person who initiated the connection. This information can be useful for Inspection Services for either logging, policy enforcement, or both. The benefit of this feature is that the authenticated username/group membership header can be removed from the payload on egress, preventing it from being leaked to origin servers. New Access Policy Manager (APM) Features Expanded Exclusion Support for Locked Client Mode Previously, APM-locked client mode allowed a maximum of 10 exclusions, preventing administrators from adding more than 10 destinations. This limitation has now been removed, and the exclusion list can contain more than 10 entries. OAuth Authorization Server Max Claims Data Support The max claim data size is set to 8kb by default, but a large claim size can lead to excessive memory consumption. You must allocate the right amount of memory dynamically as required based on claims configuration. New Features in BIG-IP v21.0.0 Control Plane Performance and Scalability Improvements The BIG-IP 21.0.0 release introduces significant improvements to the BIG-IP control plane, including better scalability and support for large-scale configurations (up to 1 million objects). This includes MCPD efficiency enhancements and eXtremeDB scale improvements. AI Data Delivery Optimize performance and simplify configuration with new S3 data storage integrations. Use cases include secure ingestion for fine-tuning and batch inference, high-throughput retrieval for RAG and embeddings generation, policy-driven model artifact distribution with observability, and controlled egress with consistent security and compliance. F5 BIG-IP optimizes and secures S3 data ingress and egress for AI workloads. Model Context Protocol (MCP) support for AI traffic Accelerate and scale AI workloads with support for MCP that enables seamless communication between AI models, applications, and data sources. This enhances performance, secures connections, and streamlines deployment for AI workloads. F5 BIG-IP optimizes and secures S3 data ingress and egress for AI workloads. Migrating BIG-IP from Entrust to Alternative Certificate Authorities Entrust is soon to be delisted as a certificate authority by many major browsers. Following a variety of compliance failures with industry standards in recent years, browsers like Google Chrome and Mozilla made their distrust for Entrust certificates public last year. As such, Entrust certificates issued on or after November 12, 2024, are deemed insecure by most browsers. Conclusion Upgrade your BIG-IP to version 21.0 today to take advantage of these fixes and new features that enhance the F5 Application Delivery and Security Platform (ADSP). These changes complement the Delivery, Security and Deployment aspects of the ADSP. Related Content SSL Orchestrator Release Notes BIG-IP Release Notes BLOG F5 BIG-IP v21.0: Control plane, AI data delivery and security enhancements Press Release F5 launches BIG-IP v21.0 Introduction to BIG-IP SSL Orchestrator
About vlangroup traffic
Hello Expert, I’ve recently been trying out VLAN groups in a test environment. This is my environment. I’ve found that on the F5, there’s no need to configure any Virtual Servers; client(1.1.1.10) can connect successfully to Server:443(1.1.1.20). I set up an ForwardingL2-type virtual server, but no traffic is through the Virtual Server; instead, it goes through the VLAN group. Why isn’t the traffic being routed through the VS?
