v11: RDP Access via BIG-IP APM - Part 1
I wrote an article several months back on auto-launching Remote Desktop sessions with APM. With the introduction of BIG-IP APM v11, there is a new built-in capability to support a full webtop. This means that server, desktop, or other resources can be placed on the webtop for users to select once logging in. In this first example, I’ll set up a static internal resource for users to connect to after logging in. Create the Webtop After logging in to the BIG-IP, open up the Access Policy tab and select Webtops->Webtop List and then click Create (or you can hit the “+” circled to the right of the Webtop List.) Give the Webtop a meaningful name and the type needs to be Full as show in Figure 1. Create the RDP Resource Still in the Access Policy tab, click Application Access->Remote Desktops->Remote Desktops and then click Create. There are a number of fields here, but for this example the only ones that need to be set are the Type (RDP), the Destination (Server or Desktop hostname or IP), and Auto Logon (Enable). When Auto Logon is selected, the username, password, and domain source variable fields are shown. I accepted the defaults. Create the Access Policy Now that the two custom objects for the RDP Webtop are created, I’ll create the access policy (and virtuals) with the Network Access Setup Wizard for Remote Access under the Wizards tab. I create all my access policies this way, the wizard is very thorough and eliminates my tendency to overlook an object or misconfigure one, not to mention the time savings. In the first screen, I disabled AV checks (though in production I wouldn’t recommend this) as shown in Figure 3 below. Next I create a new authentication resource (you can select existing if this is not a new installation), utilizing my test active directory server. Next I configure the lease pool. It’s just me in my test lab, so I only create a single client address, but you’ll likely need to choose the IP address range. The next step is for network access configuration. Corporate policies will dictate whether all traffic is forced through the tunnel or if split-tunneling is appropriate. For this example, I stuck with forcing all traffic through the tunnel to minimize the necessary configuration to show the features. I only have one name server, my ad01 directory server, so I enter that and leave the rest blank. Next I’ll enter the VIP address and leave the http->https redirect virtual enabled. At this point, I review the configuration and click next. If there are any errors, you can return to previous steps in the wizard and make corrections. Before clicking Finished in the next screen, I need to edit the access policy. Once in the policy editor, click on the Logon Page object and set Field 3 from none to text and use domain as the post and session variable name. Then below in the Logon Page Input Field #3 text box, enter Domain. Next, click on the Resource Assign object and then click Add/Delete in the expression. I need to replace the webtop the network access wizard created and I need to select the RDP Resource I created. Close out the policy and then click Finished in the Setup Summary screen. For my configuration I need to snat the traffic, so I enabled snat-automap on the virtual created by the wizard. Because I made changes to the policy, I need to re-apply it, so in the Access Policy tab I clicked on Access Profiles and then selected my profile and clicked Apply Access Policy. That completes the configuration steps. Now it’s time to test. Testing the Configuration First I open a browser and navigate to my vip, https://10.10.20.30. After login, my RDP resource is shown on my Webtop, along with my network access. After clicking the rdptest icon, I am logged in automatically to my server. It seems like a lot of steps, but I configured this in less than five minutes, which is far more efficient and far less error-prone than the previous solution. The video below shares the same steps covered here in screen captures. BIG-IP APM RDP Webtop Conclusion This solution introduces a full Webtop environment for BIG-IP APM in version 11, which I took advantage of for statically configuring RDP resources for clients. In part 2, I’ll introduce a dynamic option for the RDP resource.Simplifying and Securing Network Segmentation with F5 Distributed Cloud and Nutanix Flow
Introduction Enterprises often separate environments—such as development and production—to improve efficiency, reduce risk, and maintain compliance. A critical enabler of this separation is network segmentation, which isolates networks into smaller, secured segments—strengthening security, optimizing performance, and supporting regulatory standards. In this article, we explore the integration between Nutanix Flow and F5 Distributed Cloud, showcasing how F5 and Nutanix collaborate to simplify and secure network segmentation across diverse environments—on-premises, remote, and hybrid multicloud. Integration Overview At the heart of this integration is the capability to deploy a F5 Distributed Cloud Customer Edge (CE) inside a Nutanix Flow VPC, establish BGP peering with the Nutanix Flow BGP Gateway, and inject CE-advertised BGP routes into the VPC routing table. This architecture provides full control over application delivery and security within the VPC. It enables selective advertisement of HTTP load balancers (LBs) or VIPs to designated VPCs, ensuring secure and efficient connectivity. By leveraging F5 Distributed Cloud to segment and extend networks to remote location—whether on-premises or in the public cloud—combined with Nutanix Flow for microsegmentation within VPCs, enterprises achieve comprehensive end-to-end security. This approach enforces a consistent security posture while reducing complexity across diverse infrastructures. In our previous article (click here) , we explored application delivery and security. Here, we focus on network segmentation and how this integration simplifies connectivity across environments. Demo Walkthrough The demo consists of two parts: Extending a local network segment from a Nutanix Flow VPC to a remote site using F5 Distributed Cloud. Applying microsegmentation within the network segment using Nutanix Flow Security Next-Gen. San Jose (SJ) serves as our local site, and the demo environment dev3 is a Nutanix Flow VPC with an F5 Distributed Cloud Customer Edge (CE) deployed inside: *Note: The SJ CE is named jy-nutanix-overlay-dev3 in the F5 Distributed Cloud Console and xc-ce-dev3 in the Nutanix Prism Central. On the F5 Distributed Cloud Console, we created a network segment named jy-nutanix-sjc-nyc-segment and we assigned it specifically to the subnet 192.170.84.0/24: eBGP peering is ESTABLISHED between the CE and the Nutanix Flow BGP Gateway in this segment: At the remote site in NYC, a CE named jy-nutanix-nyc is deployed with a local subnet of 192.168.60.0/24: To extend jy-nutanix-sjc-nyc-segment from SJ to NYC, simply assign the segment jy-nutanix-sjc-nyc-segment to the NYC CE local subnet 192.168.60.0/24 in the F5 Distributed Cloud Console: Effortlessly and in no time, the segment jy-nutanix-sjc-nyc-segment is now extended across environments from SJ to NYC: Checking the CE routing table, we can see that the local routes originated from the CEs are being exchanged among them: At the local site SJ, the SJ CE jy-nutanix-overlay-dev3 advertises the remote route originating from the NYC CE jy-nutanix-nyc to the Nutanix Flow BGP Gateway via BGP, and installs the route in the dev3 routing table: SJ VMs can now reach NYC VMs and vice versa, while continuing to use their Nutanix Flow VPC logical router as the default gateway: To enforce granular security within the segment, Nutanix Flow Security Next-Gen provides microsegmentation. Together, F5 Distributed Cloud and Nutanix Flow Security Next-Gen deliver a cohesive solution: F5 Distributed cloud seamlessly extends network segments across environments, while Nutanix Flow Security Next-Gen ensures fine-grained security controls within those segments: Our demo extends a network segment between two data centers, but the same approach can also be applied between on-premises and public cloud environments—delivering flexibility across hybrid multicloud environments. Conclusion F5 Distributed Cloud simplifies network segmentation across hybrid and multi-cloud environments, making it both secure and effortless. By seamlessly extending network segments across any environment, F5 removes the complexity traditionally associated with connecting diverse infrastructures. Combined with Nutanix Flow Security Next-Gen for microsegmentation within each segment, this integration delivers end-to-end protection and consistent policy enforcement. Together, F5 and Nutanix help enterprises reduce operational overhead, maintain compliance, and strengthen security—while enabling agility and scalability across all environments. This integration is coming soon in CY2026. If you’re interested in early access, please contact your F5 representative. Related URLs Delivering Secure Application Services Anywhere with Nutanix Flow and F5 Distributed Cloud | DevCentral https://www.f5.com/products/distributed-cloud-services https://www.nutanix.com/products/flow
Delivering Secure Application Services Anywhere with Nutanix Flow and F5 Distributed Cloud
Introduction F5 Application Delivery and Security Platform (ADSP) is the premier solution for converging high-performance delivery and security for every app and API across any environment. It provides a unified platform offering granular visibility, streamlined operations, and AI-driven insights — deployable anywhere and in any form factor. The F5 ADSP Partner Ecosystem brings together a broad range of partners to deliver customer value across the entire lifecycle. This includes cohesive solutions, cloud synergies, and access to expert services that help customers maximize outcomes while simplifying operations. In this article, we’ll explore the upcoming integration between Nutanix Flow and F5 Distributed Cloud, showcasing how F5 and Nutanix collaborate to deliver secure, resilient application services across hybrid and multi-cloud environments. Integration Overview At the heart of this integration is the capability to deploy a F5 Distributed Cloud Customer Edge (CE) inside a Nutanix Flow VPC, establish BGP peering with the Nutanix Flow BGP Gateway, and inject CE-advertised BGP routes into the VPC routing table. This architecture provides us complete control over application delivery and security within the VPC. We can selectively advertise HTTP load balancers (LBs) or VIPs to designated VPCs, ensuring secure and efficient connectivity. Additionally, the integration securely simplifies network segmentation across hybrid and multi-cloud environments. By leveraging F5 Distributed Cloud to segment and extend the network to remote locations, combined with Nutanix Flow Security for microsegmentation within VPCs, we deliver comprehensive end-to-end network security. This approach enforces a consistent security posture while simplifying segmentation across environments. In this article, we’ll focus on application delivery and security, and explore segmentation in the next article. Demo Walkthrough Let’s walk through a demo to see how this integration works. The goal of this demo is to enable secure application delivery for nutanix5.f5-demo.com within the Nutanix Flow Virtual Private Cloud (VPC) named dev3. Our demo environment, dev3, is a Nutanix Flow VPC with a F5 Distributed Cloud Customer Edge (CE) named jy-nutanix-overlay-dev3 deployed inside: *Note: CE is named jy-nutanix-overlay-dev3 in the F5 Distributed Cloud Console and xc-ce-dev3 in the Nutanix Prism Central. eBGP peering is ESTABLISHED between the CE and the Nutanix Flow BGP Gateway: On the F5 Distributed Cloud Console, we created an HTTP Load Balancer named jy-nutanix-internal-5 serving the FQDN nutanix5.f5-demo.com. This load balancer distributes workloads across hybrid multicloud environments and is protected by a WAF policy named nutanix-demo: We advertised this HTTP Load Balancer with a Virtual IP (VIP) 10.10.111.175 to the CE jy-nutanix-overlay-dev3 deployed inside Nutanix Flow VPC dev3: The CE then advertised the VIP route to its peer via BGP – the Nutanix Flow BGP Gateway: The Nutanix Flow BGP Gateway received the VIP route and installed it in the VPC routing table: Finally, the VMs in dev3 can securely access nutanix5.f5-demo.com while continuing to use the VPC logical router as their default gateway: F5 Distributed Cloud Console observability provides deep visibility into applications and security events. For example, it offers comprehensive dashboards and metrics to monitor the performance and health of applications served through HTTP load balancers. These include detailed insights into traffic patterns, latency, HTTP error rates, and the status of backend services: Furthermore, the built-in AI assistant provides real-time visibility and actionable guidance on security incidents, improving situational awareness and supporting informed decision-making. This capability enables rapid threat detection and response, helping maintain a strong and resilient security posture: Conclusion The integration demonstrates how F5 Distributed Cloud and Nutanix Flow collaborate to deliver secure, resilient application services across hybrid and multi-cloud environments. Together, F5 and Nutanix enable organizations to scale with confidence, optimize application performance, and maintain robust security—empowering businesses to achieve greater agility and resilience across any environment. This integration is coming soon in CY2026. If you’re interested in early access, please contact your F5 representative. Related URLs Simplifying and Securing Network Segmentation with F5 Distributed Cloud and Nutanix Flow | DevCentral https://www.f5.com/products/distributed-cloud-services https://www.nutanix.com/products/flow/networking
Introducing F5 AI Red Team
F5 AI Red Team simulates adversarial attacks such as prompt injection and jailbreaks at unprecedented speed and scale, allowing for continuous assessment throughout the application lifecycle, providing insights into threats and integrating with F5 AI Guardrails to convert these insights into security policies.
Hands-On Quantum-Safe PKI: A Practical Post-Quantum Cryptography Implementation Guide
Updated 01.16.26 for FrodoKEM/BIKE/HQC alternate algorithms Is your Public Key Infrastructure quantum-ready? Remember way back when we built the PQC CNSA 2.0 Implementation guide in October 2025? So long ago! Due to popular request, we've expanded the lab to now include THREE distinct learning paths: NIST FIPS standards, NSA CNSA 2.0 compliance, AND alternative post-quantum algorithms for those wanting diversity or international compliance options.. The GitHub lab guide walks you through building quantum-resistant certificate authorities using OpenSSL with hands-on exercises. Why learn and implement post-quantum cryptography (PQC) now? While quantum computing is a fascinating area of science, all technological advancements can be misused. Nefarious people and nation-states are extracting encrypted data to decrypt at a later date when quantum computers become available, a practice you better know by now called "harvest now, decrypt later." Close your post-quantum cryptographic knowledge gap so you can get secured sooner and reduce the impact(s) that may not surface until after it's too late. Ignorance is not bliss when it comes to cryptography and regulatory fines, so let's get started. The GitHub lab provides step-by-step instructions to create: Quantum-resistant Root CA using ML-DSA-87 (FIPS and CNSA 2.0) Algorithm flexibility based on your compliance needs Quantum-safe server and client certificates OCSP and CRL revocation for quantum-resistant certificates TLS 1.3 key exchange testing with ML-KEM and hybrid modes Alternative algorithm exploration (FrodoKEM, BIKE, HQC) for TLS/KEM usage Access the Complete Lab Guide on GitHub → At A Glance: OpenSSL Quantum-Resistant CA Learning Paths Select the path that aligns with your requirements: FIPS 203/204/205 CNSA 2.0 Alt. Algorithms Target Audience Commercial organizations Government contractors, classified systems Researchers, international compliance, defense-in-depth Compliance Standard NIST FIPS standards NSA CNSA 2.0 Non-NIST algorithms, international standards Algorithm Coverage ML-DSA, ML-KEM, SLH-DSA, Hybrid ML-DSA-65/87, ML-KEM-768/1024 FrodoKEM, BIKE, HQC Use Case General quantum-resistant infrastructure National security systems Algorithm diversity, conservative security 📚 Learning Path 1: NIST FIPS 203/204/205 For commercial organizations implementing quantum-resistant cryptography using NIST standards. This path uses OpenSSL 3.5.x's native post-quantum cryptography support—no external quantum library providers required. So nice, so easy. Modules Module Description 00 - Introduction Overview of FIPS 203/204/205, prerequisites, and lab objectives 01 - Environment Setup Verifying OpenSSL with PQC support 02 - Root CA Building a Root CA with ML-DSA-87 03 - Intermediate CA Creating an Intermediate CA with ML-DSA-65 04 - Certificates Issuing end-entity certificates for servers and users 05 - Revocation Implementing OCSP and CRL certificate revocation 06 - Hybrid Methods IETF hybrid PQC methods (X25519MLKEM768, composite signatures) Algorithms Covered ML-DSA-44/65/87 (FIPS 204) - Lattice-based signatures ML-KEM-512/768/1024 (FIPS 203) - Lattice-based key encapsulation X25519MLKEM768 - Hybrid TLS 1.3 key exchange 📚 Learning Path 2: NSA CNSA 2.0 For government contractors and organizations requiring CNSA 2.0 compliance. This path uses OpenSSL 3.2+ with Open Quantum Safe (OQS) providers for strict CNSA 2.0 algorithm compliance. Modules Module Description 01 - Introduction Overview of CNSA 2.0 requirements and compliance deadlines 02 - Root CA Building a Root CA with ML-DSA-87 03 - Intermediate CA Creating an Intermediate CA with ML-DSA-65 04 - Certificates Issuing CNSA 2.0 compliant certificates 05 - Revocation Implementing OCSP and CRL certificate revocation CNSA 2.0 Approved Algorithms Algorithm Type Approved Algorithms NIST Designation Digital Signatures ML-DSA-65, ML-DSA-87 FIPS 204 Key Establishment ML-KEM-768, ML-KEM-1024 FIPS 203 Hash Functions SHA-384, SHA-512 FIPS 180-4 Note: CNSA 2.0 currently does NOT support ML-DSA-44, SLH-DSA, or Falcon algorithms. 📚 Learning Path 3: Alternative PQC Algorithms (NEW!) For researchers, organizations requiring algorithm diversity, and those interested in international PQC implementations. This path explores post-quantum algorithms outside the primary NIST standards, providing options for defense-in-depth strategies and understanding of the broader PQC landscape. Perfect for organizations wanting to hedge against potential future vulnerabilities in current adopted standards. Modules Module Description 00 - Introduction Overview of non-NIST algorithms, international standards, use cases 01 - Environment Setup OpenSSL and modifying OQS provider configuration 02 - FrodoKEM Conservative unstructured lattice KEM (European recommended: BSI, ANSSI) 03 - BIKE and HQC Code-based KEMs (HQC is NIST-selected backup to ML-KEM) 04 - International PQC EU, South Korean, and Chinese algorithm standards 05 - Performance Analysis Comparing algorithms, latency impacts, use cases, nerd stats Algorithms Covered Algorithm Type Mathematical Basis Key Characteristic FrodoKEM KEM Unstructured lattice (LWE) Conservative security, European endorsed (BSI, ANSSI) BIKE KEM Code-based (QC-MDPC) NIST Round 4 candidate, smaller keys than HQC HQC KEM Code-based (Quasi-cyclic) NIST-selected backup to ML-KEM (standard expected 2027) Why Alternative Algorithms Matter Algorithm Diversity: If a vulnerability is found in lattice-based cryptography (ML-KEM), code-based alternatives provide a backup International Compliance: European agencies (BSI, ANSSI) specifically recommend FrodoKEM for conservative security Future-Proofing: HQC will become a FIPS standard in 2027 as NIST's official backup to ML-KEM Research & Testing: Understand the broader PQC landscape for informed decision-making What This Lab Guide Achieves Complete PKI Hierarchy Implementation The lab walks through building an internal PKI infrastructure from scratch, including: Root Certificate Authority: Using ML-DSA-87 providing the highest quantum-ready NIST security level Intermediate Certificate Authority: Intermediate CA using ML-DSA-65 for operational certificate issuance End-Entity Certificates: Server and user certificates with comprehensive Subject Alternative Names (SANs) for real-world applications Revocation Infrastructure: Both Certificate Revocation Lists (CRL) and Online Certificate Status Protocol (OCSP) implementation TLS 1.3 Key Exchange Testing: Hands-on testing with ML-KEM, hybrid modes, and alternative algorithms Security Best Practices: Restrictive Unix file permissions, secure key storage, and backup procedures throughout Key Takeaways After completing one or more of the labs, you will: Understand ML-DSA Cryptography: Gain hands-on experience with both ML-DSA-65 (Level 3 security) and ML-DSA-87 (Level 5 security) algorithms Explore Algorithm Diversity: Understand when and why to use alternative algorithms like FrodoKEM, BIKE, and HQC Configure Modern PKI Features: Implement SANs with DNS, IP, email, and URI entries, plus both CRL and OCSP revocation mechanisms Test TLS 1.3 Key Exchange: Hands-on experience with ML-KEM and hybrid key exchange in real TLS sessions Troubleshoot Effectively: Learn to diagnose and resolve common issues with opensl and oqsproviders for PQC compatibility Prepare for Migration: Start the practical steps needed to transition existing PKI infrastructure to quantum-resistant algorithms Access the Complete Lab Guide on GitHub → About This Guide We built the first guide for NSA Suite B in the distant past (2017) to learn ECC and modern cipher requirements. It was well received enough to built a new guide for CNSA 2.0 but it's quite specific for US federal audiences. That lead us to build a NIST FIPS PQC guide which should apply to more practical use cases. And now we've added alternative algorithms because things are only going to get a bit more complicated moving forward. In the spirit of Learn Python the Hard Way, it focuses on manual repetition, hands-on interactions and real-world scenarios. It provides the practical experiences needed to implement quantum-resistant PKI in production environments. By building it on GitHub, other PKI fans can help where we may have missed something; or simply to expand on it with additional modules or forks. Have at it! Frequently Asked Questions (FAQs) Q: What is CNSA 2.0? A: CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) is the NSA's updated cryptographic standard requiring quantum-resistant algorithms. Q: When do I need to implement quantum-resistant cryptography? A: The NSA and NIST mandate CNSA 2.0 and FIPS 203/204/205 implementation by 2030. Organizations should begin now due to "harvest now, decrypt later" attacks where adversaries collect encrypted data today for future quantum decryption. Q: What is ML-DSA (Dilithium)? A: ML-DSA (Module-Lattice Digital Signature Algorithm), formerly known as Dilithium, is a NIST-standardized quantum-resistant digital signature algorithm specified in FIPS 204. Q: What is ML-KEM (Kyber)? A: ML-KEM (Module-Lattice Key Encapsulation Mechanism), formerly known as Kyber, is a NIST-standardized quantum-resistant key encapsulation mechanism specified in FIPS 203. ML-KEM-768 provides roughly AES-192 equivalent security. Q: What are the alternative algorithms and why should I care? A: FrodoKEM, BIKE, and HQC are non-NIST-primary algorithms that provide algorithm diversity. If a vulnerability is discovered in lattice-based cryptography (which ML-KEM and ML-DSA use), code-based alternatives like HQC could provide a backup. HQC is actually NIST's selected backup to ML-KEM and will become a FIPS standard in 2027. Q: What's the difference between BIKE and HQC? A: Both are code-based KEMs. BIKE has smaller key sizes but wasn't selected by NIST. HQC has larger keys and was selected as NIST's official backup to ML-KEM. Q: Why do European agencies recommend FrodoKEM? A: FrodoKEM uses unstructured lattices (standard LWE) rather than the structured lattices used in ML-KEM. This provides more conservative security assumptions at the cost of larger key sizes. Germany's BSI and France's ANSSI specifically recommend FrodoKEM for high-security applications. Q: Is this guide suitable for production use? A: NOPE. While the guide teaches production-ready techniques and compliance requirements, always use Hardware Security Modules (HSMs) and air-gapped systems for production Root CAs (cold storage too). The lab is great for internal environments or test harnesses where you may need to test against new quantum-resistant signatures. ALWAYS rely on trusted public PKI infrastructure for production cryptography. 🤓 Happy PKI'ing! Reference Links NIST Post-Quantum Cryptography Standards - Official NIST PQC project page FIPS 203: ML-KEM Standard - Module-Lattice Key Encapsulation Mechanism FIPS 204: ML-DSA Standard - Module-Lattice Digital Signature Algorithm FIPS 205: SLH-DSA Standard - Stateless Hash-Based Digital Signature Algorithm NSA CNSA 2.0 Algorithm Requirements - NSA's official CNSA 2.0 announcement Open Quantum Safe Project - Home of the OQS provider for alternative algorithms OQS Provider for OpenSSL 3 - GitHub repository for OQS provider HQC Specification - Official HQC algorithm documentation BIKE Specification - Official BIKE algorithm documentation OpenSSL 3.5 Documentation - Comprehensive OpenSSL documentationFine-Tuning F5 NGINX WAF Policy with Policy Lifecycle Manager and Security Dashboard
Introduction Traditional WAF management often relies on manual, error-prone editing of JSON or configuration files, resulting in inconsistent security policies across distributed applications. F5 NGINX One Console and NGINX Instance Manager address this by providing intuitive Graphical User Interfaces (GUIs) that replace complex text editors with visual controls. This visual approach empowers SecOps teams to manage security at all three distinct levels precisely: Broad Protection: Rapidly enabling or disabling entire signature sets to cover fast but broad categories of attacks. Targeted Tuning: Fine-tuning security by enabling or disabling signatures for a specific attack type. Granular Control: Defining precise actions for specific user-defined URLs, cookies, or parameters, ensuring that security does not break legitimate application functionality. Centralized Policy Management (F5 NGINX One Console) This video illustrates the shift from manually managing isolated NGINX WAF configurations to a unified, automated approach. With NGINX One Console, you can establish a robust "Golden Policy" and enforce it consistently across development, staging, and production environments from a single SaaS interface. The platform simplifies complex security tasks through a visual JSON editor that makes advanced protection accessible to the entire team, not just deep experts. It also prioritizes operational safety; the "Diff View" allows you to validate changes against the active configuration side-by-side before going live. This enables a smooth workflow where policies are tested in "Transparent Mode" and seamlessly toggled to "Blocking Mode" once validated, ensuring security measures never slow down your release cycles. Operational Visibility & Tuning (F5 NGINX Instance Manager) This video highlights how NGINX Instance Manager transforms troubleshooting from a tedious log-hunting exercise into a rapid, visual investigation. When a user is blocked, support teams can simply paste a Support ID into the dashboard to instantly locate the exact log entry, eliminating the need to grep through text files on individual servers. The console’s new features allow for surgical precision rather than blunt force; instead of turning off entire security signatures, you can create granular exceptions for specific patterns—like a semicolon in a URL—while keeping the rest of your security wall intact. Combined with visual dashboards that track threat campaigns and signature status, this tool drastically reduces Mean-Time-To-Resolution (MTTR) and ensures security controls don’t degrade the application experience. Conclusion The F5 NGINX One Console and F5 NGINX Instance Manager go beyond simplifying workflows—they unlock the full potential of your security stack. With a clear, visual interface, they enable you to manage and resolve the entire range of WAF capabilities easily. These tools make advanced security manageable by allowing you to create and fine-tune policies with precision, whether adjusting broad signature sets or defining rules for specific URLs and parameters. By streamlining these tasks, they enable you to handle complex operations that were once roadblocks, providing a smooth, effective way to keep your applications secure. Resources Devcentral Article: https://community.f5.com/kb/technicalarticles/introducing-f5-waf-for-nginx-with-intuitive-gui-in-nginx-one-console-and-nginx-i/343836 NGINX One Documentation: https://docs.nginx.com/nginx-one-console/waf-integration/overview/ NGINX Instance Manager Documentation: https://docs.nginx.com/nginx-instance-manager/waf-integration/overview/F5 Threat Report - January 14th, 2026
Knownsec Leak Reveals China's Industrialized Cyber-Espionage Ecosystem A significant data leak from the Chinese company Knownsec in November 2025 exposed its true nature as a state-aligned cyber contractor deeply integrated into China's national security, intelligence, and military objectives, rather than a conventional cybersecurity vendor. Knownsec's internal documents reveal a sophisticated, industrialized cyber-espionage ecosystem, including tools like ZoomEye for global internet-wide scanning and the Critical Infrastructure Target Library (TargetDB) which maps millions of foreign IPs, domains, and organizations by strategic value across 26 regions, with a strong focus on Taiwan, Japan, South Korea, and India. The company also maintains a massive `"o_data_*"` data lake of global breach data for identity correlation and deanonymization, enabling targeted social engineering. Its offensive toolkit comprises GhostX for browser exploitation, routing manipulation, and credential theft; Un-Mail for covert email account takeover and exfiltration across major global providers; and Passive Radar for reconstructing internal network topologies from PCAP data. Knownsec's organizational structure, including the 404 Security Lab and Military Products Division, mirrors a defense integrator, with primary clients being Public Security Bureaus, defense research institutes, and state-owned enterprises like State Grid and China Mobile, indicating a vertically integrated espionage stack for reconnaissance, exploitation, collection, and persistence in support of both domestic surveillance and foreign intelligence operations. Severity: Critical Sources https://dti.domaintools.com/the-knownsec-leak-yet-another-leak-of-chinas-contractor-driven-cyber-espionage-ecosystem/ https://www.hendryadrian.com/the-knownsec-leak-yet-another-leak-of-chinas-contractor-driven-cyber-espionage-ecosystem-domaintools-investigations-dti/ Threat Details and IOCs Malware: GhostX, GhostX Framework, GhostX RAT, Un-Mail CVEs: CVE-2012-0158, CVE-2015-1641, CVE-2017-0199, CVE-2017-11882, CVE-2018-0171, CVE-2018-13379, CVE-2019-19781, CVE-2019-3396, CVE-2020-10189, CVE-2021-26855, CVE-2021-27065, CVE-2021-44207, CVE-2021-44228 Technologies: Check Point Security Gateway, Fortinet FortiGate, Google Gmail, Microsoft Outlook, Microsoft Windows, Sophos Firewall, Yahoo Mail Threat Actors: 404Lab, APT31, APT41, MUSTANGPANDA Attacker Countries: China Attacker IPs: 103.21.60.3, 210.242.194.198, 219.80.43.14, 220.130.186.202, 220.130.186.203, 61.65.236.240 Attacker Emails: anyh@knownsec.com, chenc6@knownsec.com, chenh4@xm.knownsec.com, chenjz@xm.knownsec.com, chenrl@xm.knownsec.com, evp@knownsec.com, hey5@knownsec.com, liuj13@knownsec.com, liwc@xm.knownsec.com, mas@knownsec.com, niexy2@knownsec.com, raosh@knownsec.com, suig@knownsec.com, wangcp2@knownsec.com, wangl8@xm.knownsec.com, wangll@xm.knownsec.com, xuc2@knownsec.com, yangwh2@knownsec.com, zhanghj@knownsec.com, zouxy2@knownsec.com Attacker Domains: creategroup.cn, ittc.sh.cn, knownsec.com, knownsec.com.hk, rusnod.ru, seebug.org, telderi.ru, www.knownsec.com.hk, xm.knownsec.com, zoomeye.aigithub.com Attacker URLs: github.com/Knownsec404team, http://creategroup.cn, https://github.com/zoomeye-ai, https://www.knownsec.com.hk, https://www.knownsec.com.hk/, https://www.linkedin.com/company/上海国际技贸联合有限公司, http://www.ittc.sh.cn, www.linkedin.com/company/knownsec-hong-kong/, zhuanlan.zhihu.com/p/21881117943, zoomeye.aigithub.com/zoomeye-ai Victim Industries: Automotive, Cloud Infrastructure, Defense, Education, Energy, Financial Services, Government, Healthcare, Industrials, Multimedia, Retail, Social Media, Technology Hardware, Telecommunications, Transportation Victim Countries: Brazil, China, India, Japan, Russia, South Africa, South Korea, Taiwan, United States, Vietnam Mitigation Advice Add the IP addresses listed in Appendix A (210.242.194.198, 219.80.43.14, 220.130.186.202, 220.130.186.203, 103.21.60.3, 61.65.236.240) to the firewall blocklist. Immediately audit and apply all available security patches to internet-facing Fortinet devices. Immediately audit and apply all available security patches to internet-facing Sophos devices. Immediately audit and apply all available security patches to internet-facing Check Point devices. Audit all network routers and firewalls for any recently created or unauthorized administrator-level accounts. Review internal and external DNS server configurations and forwarders to ensure they point only to authorized and expected IP addresses. Add all specific email addresses and the domains @knownsec.com and @xm.knownsec.com listed in the article to the email gateway's blocklist. Compliance Best Practices Prioritize and enforce the rollout of phishing-resistant multi-factor authentication (MFA) across all externally accessible services, including VPN, email, and cloud applications. Develop and implement a network segmentation strategy to isolate critical servers from user workstations and restrict east-west traffic based on the principle of least privilege. Deploy and tune an Endpoint Detection and Response (EDR) solution to create detection rules for suspicious browser process behavior, command-line execution patterns, and attempts to extract credentials from memory. Implement a Web Application Firewall (WAF) to protect all public-facing web applications and portals against common attacks like Cross-Site Scripting (XSS). Implement a network detection and response (NDR) tool to establish baseline traffic patterns and create alerts for anomalous activity, such as large outbound data transfers over FTP or SSH from non-standard servers. Establish a recurring security awareness training program that educates employees on identifying and reporting sophisticated phishing attacks that may leverage their personal or professional information found in data breaches. OWASP CRS Flaw Lets Encoded Attacks Slip Past WAFs A critical vulnerability, identified as CVE-2026-21876 with a CVSS score of 9.3, has been discovered in the OWASP Core Rule Set (CRS), allowing encoded Cross-Site Scripting (XSS) attacks to bypass Web Application Firewalls (WAFs). This flaw affects CRS versions 3.3.x through 3.3.7 and 4.0.0 through 4.21.0, specifically impacting rule 922110 in Apache ModSecurity, ModSecurity v3, and Coraza environments. The bypass occurs because rule 922110, designed to detect dangerous character encodings like UTF-7 in multipart form requests, only validates the final segment of such requests. Attackers can exploit this by embedding a malicious UTF-7 encoded JavaScript payload in an earlier part of a multipart request, followed by benign UTF-8 content in the final segment, thereby evading WAF detection. To mitigate this risk, immediate upgrades to CRS version 4.22.0 or 3.3.8 are essential, alongside verifying WAF configurations, restricting accepted character encodings to UTF-8, implementing custom WAF rules for mixed charset declarations, strengthening application-layer defenses with robust input validation and Content Security Policy headers, and enhancing monitoring and incident response capabilities. This incident underscores the necessity for continuous validation and updating of security controls, moving away from "set-and-forget" approaches towards principles of continuous verification. Severity: Critical Sources https://cyberpress.org/owasp-crs-vulnerability/ https://gbhackers.com/owasp-crs-vulnerability/ https://www.esecurityplanet.com/threats/owasp-crs-flaw-lets-encoded-attacks-slip-past-wafs/ https://www.thehackerwire.com/owasp-crs-bypass-multipart-request-charset-validation-flaw-cve-2026-21876/ Threat Details and IOCs Malware: Archer RAT, RUSTRIC, RustyWater CVEs: CVE-2026-21876 Technologies: ModSecurity, OWASP Coraza, OWASP Core Rule Set Victim Industries: E-commerce, Financial Services, Government, Healthcare, Technology Hardware Mitigation Advice Identify all Web Application Firewall (WAF) instances using OWASP Core Rule Set (CRS) and upgrade them to a patched version, either 4.22.0 or 3.3.8, to fix the vulnerability. Analyze WAF and web server logs for evidence of exploitation, specifically looking for multipart form requests that contain non-standard character encodings like UTF-7 or have mixed charsets across different parts. Configure all public-facing web servers, such as Apache or Nginx, to only accept UTF-8 character encoding and explicitly reject requests with other encodings, especially UTF-7 and UTF-16. If patching the OWASP Core Rule Set cannot be done immediately, create a custom WAF rule to inspect all parts of a multipart request for dangerous character encodings, not just the final part. Compliance Best Practices Establish a secure coding program to enforce strict, server-side input validation on all user-supplied data across all web applications to prevent XSS attacks at the source. Mandate the use of context-aware output encoding libraries and practices in all web application development to neutralize any malicious scripts before they are sent to the user's browser. Develop and deploy a restrictive Content Security Policy (CSP) across all web applications to limit the impact of potential XSS vulnerabilities by controlling script execution sources. Improve security monitoring capabilities by creating specific alerts for anomalous HTTP traffic patterns, such as multipart requests with unusual or mixed character set declarations, to detect novel bypass techniques. Schedule and conduct regular incident response tabletop exercises that simulate a WAF bypass and subsequent web application compromise to test and improve your team's detection and response procedures. CVE-2026-21858 aka Ni8mare: Critical Unauthenticated Remote Code Execution Vulnerability in n8n Platform A critical unauthenticated remote code execution vulnerability, tracked as CVE-2026-21858 and dubbed Ni8mare, has been identified in the n8n AI workflow automation platform, carrying a maximum CVSS score of 10.0. This flaw, affecting all n8n versions up to and including 1.65.0, stems from a weakness in the platform's webhook request parsing and file handling logic. Specifically, when a crafted HTTP request is sent to a Forms Webhook node with a deliberately misstated "Content-Type" header (other than `multipart/form-data`), the `parseBody()` function can be exploited to overwrite the `req.body.files` variable with attacker-controlled data. This allows an attacker to specify arbitrary file paths on the local system, leading to the `copyBinaryFile()` function copying these specified local files into persistent storage without verifying their origin. Exploitation of Ni8mare can grant unauthenticated attackers full control over exposed n8n instances, potentially leading to sensitive data exposure, workflow manipulation, and credential compromise. With over 26,500 internet-accessible n8n hosts reported globally, the potential attack surface is substantial. The vulnerability was reported on November 9, 2025, and addressed in version 1.121.0, released on November 18, 2025; users are strongly advised to upgrade immediately, and temporary mitigations include restricting or disabling publicly accessible webhook and form endpoints. Severity: Critical Sources https://arcticwolf.com/resources/blog/cve-2026-21858/ https://buaq.net/go-386499.html https://buaq.net/go-386542.html https://buaq.net/go-387142.html https://cyberpress.org/ni8mare-vulnerability/ https://cyberscoop.com/n8n-critical-vulnerability-massive-risk/ https://horizon3.ai/attack-research/attack-blogs/the-ni8mare-test-n8n-rce-under-the-microscope-cve-2026-21858/ https://infosecwriteups.com/critical-n8n-security-vulnerability-cve-2026-21858-demands-immediate-action-c4bd95b5d93c?source=rss----7b722bfd1b8d---4 https://orca.security/resources/blog/cve-2026-21858-n8n-rce-vulnerability/ https://securityonline.info/public-exploit-released-critical-n8n-flaw-cve-2026-21858-exposes-100k-servers/ https://socprime.com/blog/cve-2026-21858-vulnerability/ https://socradar.io/blog/ni8mare-flaw-n8n-cve-2026-21858/ https://sploitus.com/exploit?id=329E5BE3-360F-5C2E-8422-B4D96C9C6E68 https://thecyberexpress.com/cve-2026-21858-n8n-webhook-vulnerability/ https://thehackernews.com/2026/01/critical-n8n-vulnerability-cvss-100.html https://www.bleepingcomputer.com/news/security/max-severity-ni8mare-flaw-lets-hackers-hijack-n8n-servers/ https://www.cyberkendra.com/2026/01/how-100000-automation-servers-became.html https://www.hendryadrian.com/max-severity-ni8mare-flaw-lets-hackers-hijack-n8n-servers/ https://www.infosecurity-magazine.com/news/maximum-severity-ni8mare-bug/ https://www.securityweek.com/critical-vulnerability-exposes-n8n-instances-to-takeover-attacks/ https://www.techzine.eu/news/security/137741/ni8mare-vulnerability-affects-n8n-platform-with-a-score-of-10-0/ https://www.thehackerwire.com/n8n-unauth-file-read-via-workflow-execution/ https://www.theregister.com/2026/01/08/n8n_rce_bug/ Threat Details and IOCs CVEs: CVE-2025-68613, CVE-2025-68668, CVE-2026-21858, CVE-2026-21877 Technologies: Docker, Linux, n8n, OpenAI, SQLite Attacker Countries: Bangladesh, Myanmar Victim Industries: Advertising Services, Airlines & Aviation, Artificial Intelligence, Construction, Customer Service, E-commerce, Education, Financial Services, Food and Beverage Services, Food & Beverage, Healthcare, Hospitals and Health Care, Human Resources, Information Technology, IT Services, Legal Services, Logistics, Manufacturing, Marketing & Advertising, Media and Entertainment, Professional Services, Real Estate, Retail, Sales & Marketing, Software, Software as a Service (SaaS), Supply Chain, Technology Hardware, Telecommunications, Transportation Equipment Manufacturing, Venture Capital & Private Equity Victim Countries: Australia, Brazil, Canada, Denmark, Finland, France, Germany, Iceland, India, Israel, Italy, Netherlands, Norway, Singapore, Spain, Sweden, Ukraine, United Arab Emirates, United Kingdom, United States, Vietnam Mitigation Advice Immediately upgrade all n8n instances to version 1.121.0 or later to patch the CVE-2026-21858 vulnerability. Immediately scan the network and review software inventories to identify all instances of the n8n platform in use within the organization. If you cannot immediately upgrade n8n, restrict access to or disable all publicly accessible webhook and form endpoints to prevent unauthenticated exploitation. Hunt for exploitation attempts by reviewing web server and application logs for requests to n8n webhook endpoints where the 'Content-Type' header is not 'multipart/form-data' but the request body contains file path definitions. Compliance Best Practices Develop and enforce a policy to place internal services like n8n behind a VPN or other authenticated access controls, and formally review all requests for public internet exposure. Implement network segmentation to isolate servers running workflow automation platforms like n8n from other critical internal network segments, limiting the potential impact of a successful compromise. Deploy or configure a Web Application Firewall (WAF) to inspect and block anomalous HTTP requests to web applications, including rules that detect mismatched 'Content-Type' headers and body content. Review and strengthen the vulnerability management program to ensure timely identification, prioritization, and patching of critical vulnerabilities in all third-party software, with specific focus on internet-facing applications. Trend Micro Apex Central RCE Flaw Scores 9.8 CVSS in On-Prem Windows Versions Trend Micro has issued security updates for multiple vulnerabilities affecting on-premise versions of Apex Central for Windows, specifically those below Build 7190. The most severe, CVE-2025-69258, is a Remote Code Execution (RCE) flaw with a CVSS score of 9.8. This LoadLibraryEX vulnerability enables an unauthenticated remote attacker to load a controlled DLL into the MsgReceiver.exe component by sending a specific message (0x0a8d, `"SC_INSTALL_HANDLER_REQUEST"),` resulting in code execution with SYSTEM privileges. Two additional Denial-of-Service (DoS) vulnerabilities, CVE-2025-69259 and CVE-2025-69260, both rated 7.5 CVSS, were also patched. These DoS flaws, stemming from a message unchecked NULL return value and a message out-of-bounds read, respectively, can be exploited by an unauthenticated remote attacker sending a specially crafted message (0x1b5b, `"SC_CMD_CGI_LOG_REQUEST")` to the MsgReceiver.exe process on TCP port 20001. Tenable is credited with discovering and reporting these vulnerabilities in August 2025. Organizations are advised to apply the necessary security updates and to review remote access to critical systems, ensuring that security policies and perimeter defenses are current. Severity: Critical Sources https://buaq.net/go-386777.html https://cyberpress.org/trend-micro-apex-central-vulnerabilities-enable-remote-code-execution-attacks/ https://cyberveille.esante.gouv.fr/alertes/trendmicro-cve-2025-69258-2026-01-09 https://gbhackers.com/trend-micro-apex-central-flaw/ https://securityonline.info/public-exploit-released-critical-trend-micro-flaw-grants-system-access/ https://thehackernews.com/2026/01/trend-micro-apex-central-rce-flaw.html https://www.esecurityplanet.com/threats/trend-micro-apex-central-flaws-enable-remote-code-execution/ https://www.helpnetsecurity.com/2026/01/08/trend-micro-apex-central-cve-2025-69258-rce-poc/ https://www.techzine.eu/news/security/137798/trend-micro-closes-critical-vulnerabilities-in-apex-central/ https://www.thehackerwire.com/trend-micro-apex-central-rce-via-loadlibraryex/ Threat Details and IOCs CVEs: CVE-2022-26871, CVE-2025-69258, CVE-2025-69259, CVE-2025-69260 Technologies: Microsoft Windows, Trend Micro Apex Central Victim Industries: Automotive, Cloud Infrastructure, Education, Energy, Financial Services, Government, Healthcare, Information Technology, Manufacturing, Oil & Gas, Retail Victim Countries: France, Japan, United States Mitigation Advice Identify all on-premise Trend Micro Apex Central for Windows instances and immediately apply the security updates to upgrade them to Build 7190 or a later version. Implement a firewall rule to block all inbound traffic to TCP port 20001 on Trend Micro Apex Central servers from untrusted networks and allow access only from required endpoints and management stations. On Trend Micro Apex Central servers, use endpoint security tools to monitor the `MsgReceiver.exe` process for the loading of unusual or unsigned DLLs and for spawning unexpected child processes. Scan network traffic logs for connection attempts to TCP port 20001 on Apex Central servers, investigating any connections from unexpected or external IP addresses. Compliance Best Practices Establish and enforce a formal patch management policy that defines specific timelines for applying security updates based on their severity, ensuring critical vulnerabilities are addressed within 72 hours. Implement network segmentation to create a secure management zone for critical infrastructure servers, including Trend Micro Apex Central, restricting all inbound and outbound traffic to only what is explicitly authorized. Develop and maintain a comprehensive software asset inventory that includes application names, versions, and owners, enabling rapid identification of systems vulnerable to newly disclosed threats. Conduct quarterly reviews of firewall rules and access control lists for critical servers to ensure they adhere to the principle of least privilege and that all access is documented and approved. ZDI-26-034 / CVE-2026-0768: 0-Day Code Injection RCE Vulnerability in Langflow A critical code injection remote code execution vulnerability, identified as ZDI-26-034 and CVE-2026-0768, affects installations of Langflow. This flaw, assigned a CVSS score of 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), allows unauthenticated remote attackers to execute arbitrary code. The vulnerability stems from insufficient validation of a user-supplied string within the `code` parameter provided to the `validate` endpoint, which is subsequently used to execute Python code. Successful exploitation grants an attacker the ability to execute code in the context of root. The vulnerability was reported on July 18, 2025, and publicly disclosed as a 0-day on January 9, 2026. The only salient mitigation strategy is to restrict interaction with the product. This vulnerability was discovered by Peter Girnus, William Gamazo Sanchez, and Alfredo Oliveira. Severity: High Sources https://www.zerodayinitiative.com/advisories/ZDI-26-034/ Threat Details and IOCs CVEs: CVE-2026-0768 Technologies: Langflow, Linux Victim Industries: Customer Service, Financial Services, Human Resources, Logistics, Manufacturing, Marketing & Advertising, Sales & Marketing Mitigation Advice Immediately conduct an inventory of all assets to identify any running instances of the Langflow application. Configure perimeter firewalls to deny all inbound internet traffic to any identified Langflow instances. Hunt for compromise by searching web server and application logs for requests to the '/validate' endpoint, particularly any requests containing a 'code' parameter. If Langflow must remain accessible, configure a Web Application Firewall (WAF) to block any HTTP requests targeting the '/validate' URI path. Compliance Best Practices Enforce the principle of least privilege by reconfiguring all production and development services, including Langflow, to run using dedicated, unprivileged service accounts instead of as the 'root' user. Implement a comprehensive software asset management program to maintain a real-time inventory of all applications deployed in the environment. Adopt a network segmentation strategy that isolates internal-facing tools and development environments from the public internet, requiring VPN access for remote users. Incorporate CVE-2026-0768 into the vulnerability management watchlist and ensure the official patch from the Langflow vendor is applied to all affected systems as soon as it is released. Stay updated on emerging threats: sign up for the F5 Threat Report to receive the Weekly Threat Report in your inbox.F5 BIG-IP SSL Orchestrator Layer 2 Services with rSeries & VELOS
Introduction F5 rSeries & VELOS are rearchitected, next-generation hardware platforms that scale application delivery performance and automate application services to address many of today’s most critical business challenges. F5 rSeries & VELOS are key components of the F5 Application Delivery and Security Platform (ADSP). rSeries & VELOS rely on a Kubernetes-based platform layer (F5OS) that is tightly integrated with F5 TMOS software. Going to a microservice-based platform layer allows rSeries & VELOS to provide additional functionality that was not possible in previous generations of F5 BIG-IP platforms. The introduction of a new tenant-based architecture changes many things, including how you configure BIG-IP. Some of these changes affect the network configuration for Inline Layer 2 Services. By default, BIG-IP tenants only have a small set of internal MAC addresses available to them. However, Layer 2 Services (or Bridging) require additional MAC addresses. You must assign an adequate number of MAC addresses to what is called a “MAC pool”. A single Layer 2 Service requires two unique MAC addresses. The MAC Pool must have sufficient MAC addresses based on the number of Layer 2 Services you need. The following KB articles contain additional information on configuring MAC Pools on a BIG-IP rSeries or VELOS platform: K000133655: MAC address assignment in VELOS and rSeries systems K000135389: Configure the MAC Block Size for an existing BIG-IP tenant on the VELOS and rSeries systems Demo Video F5OS Configuration Let’s review the Network configuration on F5OS for a BIG-IP Tenant. From Network Settings select VLANs. Here you can see I have 6 Interfaces configured with VLANs. There’s a Lan VLAN for connectivity from the internal network to the BIG-IP. A Wan VLAN for connectivity from the BIG-IP to the internet. Then there are 4 “L2” VLANs configured to support two Inline Layer 2 Services with SSL Orchestrator. From the Interfaces screen you can associate the VLANs with the physical Interfaces. Next, allocate the VLANs to your BIG-IP Tenant. This is also where you configure the MAC Pool Size for your current BIG-IP Tenant. The MAC Pool can only be changed when the Tenant is not running. From Tenant Management > Tenant Deployments, you can stop the current Tenant if it is already running. Do this with caution during a change window or prior to deployment. Check the box next to the name of the Tenant you wish to configure, “big-ip-kevin” in this example. Then click Configure. Click OK to stop the Tenant When it’s stopped click the name of the Tenant to edit the configuration. Note the VLANs that are allocated to this BIG-IP Tenant: Find the section on MAC Data/MAC Block Size. Set the allocation to Small (8), Medium (16), or Large (32) depending upon your needs. I set mine to Medium. A Small allocation would be sufficient for this deployment but I want to leave room to add more Layer 2 Services in the future. Click Save & Close Click OK to update the configuration You can Deploy the Tenant now that the changes have been made Click OK to Deploy F5 BIG-IP Configuration Minimal configuration is needed on the BIG-IP since F5OS handles the underlying physical interfaces and VLANs. Check the status of the VLANs from Network > VLANs. From here we can see the VLAN configuration from F5OS is reflected in the BIG-IP. Define any Self IPs from Network > Self IPs Now we’re ready to configure SSL Orchestrator. In the interest of time, I will skip to the Network and Services configuration. From Services List click Add Service Double-click on Generic Inline Layer 2 Under Network Configuration click Add Select the L2 VLANs for this Inline L2 Service. Click Done. Click Add again and select the L2 VLANs for this Inline L2 Service. Click Done. It should look like the following: Click Save at the bottom For the Interception Rule select the Lan VLAN under Ingress Network and move it to the right. Click Save & Next at the bottom The Network configuration is now complete. SSL Orchestrator is configured with a Generic Inline Layer 2 Service that contains two Layer 2 “servers” Conclusion F5 rSeries & VELOS are hardware platforms that scale application delivery performance and automate application services to address many of today’s most critical business challenges. They are key components of the F5 Application Delivery and Security Platform (ADSP). In this article, you learned how to configure MAC Pools on rSeries and VELOS in order to create Layer 2 Inline Services with SSL orchestrator. Related Content K000133655: MAC address assignment in VELOS and rSeries systems K000135389: Configure the MAC Block Size for an existing BIG-IP tenant on the VELOS and rSeries systems SSL Orchestrator CloudDocs: Creating an Inline Layer 2 Service F5 rSeries: Next-Generation Fully Automatable Hardware F5 VELOS: A Next-Generation Fully Automatable Platform
