F5 not sending traffic to Web pool
Hello All, I am having issues with a new configured F5 big-IP that everything works fine as follows. traffic from the client is coming to the firewall which is then natted to the private network. (works) the Load balancer ( Virtual server) IP is accessible and request is sent to the virtual server. and from the big ip to the pool is not sent. connection between the F5 to the pool is fine and vice versa and pool and nodes are available (green). connection between web-server and F5 is through Https (443). configuration F5 as follows: F5 Virtual IP : 192.168.1.41 self IP: int 1 : 10.10.10.14 self IP int 2 : 192.168.1.41 web server pool : 10.10.10.X range with class c subnet. SSL is configured between the client to F5 as clientssl and between the server and F5 as serverssl. source address translation is automap. I am having trouble why it doesn't work and is trying to find out the problem.F5 Partners join us for Partner Connect Quarterly Update: May 21 & 22
We are excited to invite you to the F5 Partner Connect Quarterly Update, an exclusive event designed to empower our partners with cutting-edge insights and strategic direction. Join us on May 21st and 22nd for a deep dive into F5's transformation journey and the unlocking of API security potential. May 21 12pm SGT: Asia Pacific, China, and Japan May 22: 2pm BST: Europe, Middle East, and Africa 11am PDT: Americas We will revisit F5’s evolution and reinforce our stance on API security, spotlighting our strategic acquisitions of WIB and Heyhack. Chuck Herrin, Senior Principal Product Manager for Security and former CTO at WIB, will delineate F5's forward-thinking approach in the application and API security landscape. Josh Goldfarb, Global Solutions Architect for Security will present 10 actionable best practices. These insights will help you, our valued partners, to maximize profitability and leverage F5’s innovative solutions for unparalleled market opportunities. Do not miss this chance to connect with F5 leaders and stay at the forefront of the security domain. Together, let's transform challenges into opportunities and elevate API security to new heights. Register Now!How To Run Ollama On F5 AppStack With An NVIDIA GPU In AWS
If you're just getting started with AI, you'll want to watch this one, as Michael Coleman shows Aubrey King, from DevCentral, how to run Ollama on F5 AppStack on an AWS instance with an NVIDIA Tesla T4 GPU. You'll get to see the install, what it looks like when a WAF finds a suspicious conversation and even a quick peek at how Mistral handles a challenge differently than Gemma.
Action Items in OMB Memorandum M-22-09 “Moving the U.S. Government Toward Zero Trust...”
Purpose On January 26, 2022, OMB issued Memorandum M-22-09 for “Moving the U.S. Government Toward Zero Trust Cybersecurity Principles” listing a series of action items. This blog is to provide an overview of F5 capabilities and where they fit within those action items. Milestone Dates January 26, 2022 Issuance of M-22-09 “Moving the U.S. Government Toward Zero Trust Cybersecurity Principles” February 25, 2022 Agencies to designate and identify a zero trust strategy implementation lead for their organization March 27, 2022 Submit to OMB and CISA an implementation plan for FY22-FY24 May 27, 2022 Chief Data Officers to develop a set of initial categorizations for sensitive electronic documents within their enterprise January 26, 2023 Public-facing agency systems that support MFA must give users the option of using phishing-resistant authentication January 26, 2023 Each agency must select at least one FISMA Moderate system that requires authentication and make it Internet accessible August 27, 2022 Agencies must reach the first event logging maturity level (EL-1) as described in Memorandum M-21-31 End of FY2024 Agencies to achieve specific zero trust security goals Requirements to F5 Capability Mapping Page Requirements F5 Capabilities F5 Products 6 Section A.1 “Enterprise identity management must be compatible with common applications and platforms. As a general matter, users should be able to sign in once and then directly access other applications and platforms within their agency’s IT infrastructure. Beyond compatibility with common applications, an agency identity management program should facilitate integration among agencies and with externally operated cloud services; the use of modern, open standards often promotes such integration.” Proxies and transforms client side authentication method to adapt to application’s native authentication method. Modern authentication can now be applied to legacy web application without any changes. BIG-IP APM NGINX 7 Section A.2 Agencies must integrate and enforce MFA across applications involving authenticated access to Federal systems by agency staff, contractors, and partners. MFA, including PIV, can be applied to any applications, whether legacy or modern, without changes. BIG-IP APM 7 Section A.2 MFA should be integrated at the application layer MFA, including PIV, can be applied to any applications, whether legacy or modern, without changes. BIG-IP APM 7 Section A.2 guessing weak passwords or reusing passwords obtained from a data breach Finds compromised credentials in real-time, identifies botnets, and blocks simulation software. F5 Distributed Cloud Services 7 Section A.2 many approaches to multi-factor authentication will not protect against sophisticated phishing attacks, which can convincingly spoof official applications and involve dynamic interaction with users. Users can be fooled into providing a one-time code or responding to a security prompt that grants the attacker account access. These attacks can be fully automated and operate cheaply at significant scale. Finds compromised credentials in real-time, identifies botnets, and blocks simulation software. F5 Distributed Cloud Services 9 Section A.3 every request for access should be evaluated to determine whether it is appropriate, which requires the ability to continuously evaluate any active session After a session starts, a per-request policy runs each time the client makes an HTTP or HTTPS request. A per-request policy must provide the logic for determining how to process web-bound traffic. It must determine whether to allow or reject a URL request and control whether or not to bypass SSL traffic. BIG-IP APM NGINX 10 Section A.3 Agency authorization systems should work to incorporate at least one device-level signal alongside identity information about the authenticated user when regulating access to enterprise resources High-efficacy digital fingerprinting identifies returning web client patterns from new edge devices. F5 Distributed Cloud Services 12 Section C.1 Agencies should make heavy internal use of recent versions of standard encryption protocols, such as TLS 1.3 Regardless of your TLS version, you need to have visibility into encrypted threats to protect your business. SSL/TLS based-decryption devices that allow for packet inspection can intercept encrypted traffic, decrypt, inspect, and re-encrypt untrusted TLS traffic entering or leaving the network. BIG-IP LTM BIG-IP SSLO NGINX 13 Section C.1 agencies should plan for cryptographic agility in their network architectures, in anticipation of continuing to adopt newer versions of TLS Organizations don’t want to reconfigure hundreds of servers just to offer these new protocols. This is where transformational services become cipher agility. Cipher agility is the ability of an SSL device to offer multiple cryptographic protocols such as ECC, RSA2048, and DSA at the same time—even on the same virtual server. BIG-IP SSLO 13 Section C.2 agency DNS resolvers must support standard encrypted DNS protocols (DNS-over-HTTPS or DNS-over-TLS) NOTE: DNSSEC does not encrypt DNS data in transit. DNSSEC can be used to verify the integrity of a resolved DNS query, but does not provide confidentiality. DoH proxy—A passthrough proxy that proxies the client’s DoH request to a backend DoH server and the backend DoH server’s response back to the DoH client. DoH server—The server translates the client’s DoH request into a standard DNS request and forwards the DNS request using TCP or User Datagram Protocol (UDP) to the configured DNS server, such as the BIG-IP named process and the BIG-IP DNS cache feature. When the BIG-IP system receives a response from the configured DNS server, it translates the DNS response into a DoH response before sending it to the DoH client. BIG-IP DNS 14 Section C.3 Zero trust architectures—and this strategy— require agencies to encrypt all HTTP traffic, including within their environments. Handle SSL traffic in load balancing scenario and meet most of the security requirements effectively. The 3 common SSL configurations that can be set up on LTM device are: -SSL Offloading -SSL Passthrough -Full SSL Proxy / SSL Re-Encryption / SSL Bridging / SSL Terminations BIG-IP LTM BIG-IP SSLO NGINX 18 Section D.4 Making applications internet-accessible in a safe manner, without relying on a virtual private network (VPN) or other network tunnel Proxy-based access controls deliver a zero-trust platform for internal and external application access. That means applications are protected while extending trusted access to users, devices, and APIs. BIG-IP LTM BIG-IP APM 18 Section D.4 require agencies to put in place minimum viable monitoring infrastructure, denial of service protections, and an enforced access-control policy Integrate with SIEM for agency wide monitoring or use F5 management platform for greater visibility. On-prem DDOS works in conjunction with cloud service to protect from various attack strategies. BIG-IQ BIG-IP AFM BIG-IP ASM F5 Distributed Cloud DDOS 19 Section D.6 Automated, immutable deployments support agency zero trust goals Built-in support for automation and orchestration to work with technologies like Ansible, Terraform, Kubernetes and public clouds. BIG-IP NGINX 20 Section D.6 Agencies should work toward employing immutable workloads when deploying services, Built-in support for automation and orchestration to work with technologies like Ansible, Terraform, Kubernetes and public clouds. BIG-IP NGINX 24 Section F.1 Agencies are undergoing a transition to IPv6, as described in OMB Memorandum M-21- 07, while at the same time migrating to a zero trust architecture The BIG-IP device is situated between the clients and the servers to provide the applications the clients use. In this position—the strategic point of control—the BIG-IP device provides virtualization and high availability for all application services, making several physical servers look like a single entity behind the BIG-IP device. This virtualization capability provides an opportunity to start migrating either clients or servers—or both simultaneously—to IPv6 networks without having to change clients, application services, and both sides of the network all at once. BIG-IP LTM NGINX 24 Section F.2 OMB Memorandum M-19-1735 requires agencies to use PIV credentials as the “primary” means of authentication used for Federal information systems PIV authentication can be applied to any applications, whether legacy or modern, without changes. BIG-IP APM 25 Section F.3 Current OMB policies neither require nor prohibit inline decryption of enterprise network traffic SSL Orchestrator is designed and purpose-built to enhance SSL/TLS infrastructure, provide security solutions with visibility into SSL/TLS encrypted traffic, and optimize and maximize your existing security investments. BIG-IP SSLO 25 Section F.4 This memorandum expands the scope of M-15-13 to encompass these internal connections. NOTE: M-15-13 specifically exempts internal connections, stating, “[T]he use of HTTPS is encouraged on intranets, but not explicitly required.” SSL Orchestrator delivers dynamic service chaining and policy-based traffic steering, applying context-based intelligence to encrypted traffic handling to allow you to intelligently manage the flow of encrypted traffic across your entire security stack, ensuring optimal availability. BIG-IP LTM BIG-IP SSLO NGINX Your F5 Account Team Can Help Every US Federal agency has a dedicated F5 account team to support the mission. They are ready to discuss F5 capabilities and help provide further information for your Zero Trust implementation plan. Please contact your F5 account team directly or use this contact form.
TESTING / ARTICLE SAVE - 002LEZ
This post is to go over some of my thoughts on ASM/WAF management, and some custom solutions I've made to make it easier and more accurate. This will be highly technical and will apply to most use-cases. Written based on TMOS v15 software, but will be mostly applicable to all recent TMOS versions. Automatic Learning Informational Automatic Learning will automatically accept most Learning Suggestions that hit 100% confidence Fully Automatic Learning will automatically accept all Learning Suggestions that hit 100% confidence If your application open to the public, it will likely get scanned a lot. Some of the Learning Suggestions will be to loosen your policies based on scanner traffic it sees, like this one that would've accepted a SQL injection attack suggestion from traffic that's clearly from a Veracode scanner Tips Reduce scanner traffic that hits ASM policy: Apply an iRule to your VIPs that have ASM policies that drops external IP-based requests. A lot of scanner traffic hits your VIPs by IP address instead of by hostname, and iRules process before ASM policies. So dropping IP-based traffic via iRule will drastically reduce the amount of bad ASM Learning Suggestions you get I use the attached iRule "irule_all_asm_VIPs" on all ASM VIPs. It has a line to increment the "triggered" field in a Statistics profile named "asm_irule_triggered," so you'll have to create the Statistics profile with the "triggered" field and attach it to the VIP before it will let you attach the iRule to the VIP. This makes sure you don't lose track of how many bad requests are hitting the device If ASM VIP has an existing iRule, irule_all_asm_VIPs must be attached first in order. See below for an automated way to attach this iRule to all ASM VIPs. Ongoing Maintenance Tasks:Q/A with itacs GmbH's Kai Wilke - DevCentral's Featured Member for February
Kai Wilke is a Principal Consultant for IT Security at itacs GmbH – a German consulting company located in Berlin City specializing in Microsoft security solutions, SharePoint deployments, and customizations as well as classical IT Consulting. He is also a 2017 DevCentral MVP and DevCentral’s Featured Member for February! For almost 20 years in IT, he’s constantly explored the evens and odds of various technologies, including different operating systems, SSO and authentication services, RBAC models, PKI and cryptography components, HTTP-based services, proxy servers, firewalls, and core networking components. His focus in these areas has always been security related and included the design, implementation and review of secure and high availability/high performance datacenters. DevCentral got a chance to talk with Kai about his work, life and mastery of iRules. DevCentral: You’ve been a very active contributor to the DevCentral community and wondered what keeps you involved? Kai: Working with online communities has always been an important thing for me and it began long time ago within the good old Usenet and the predecessor of the Darknet. Before joining the F5 community, I was also once an honored member of the Microsoft Online Community and was five times awarded as a Microsoft MVP for Enterprise Security and Microsoft-related firewall/proxy server technologies. My opinion is that if you want to become an expert for a certain technology or product, you should not just learn THE-ONE straight-forward method fetched from manuals, guides or even exams. Instead, you have to dive deeply into all of those edge scenarios and learn all the uncountable ways to mess the things up. And dealing with questions and problems of other peers is probably the best catalyst to gain that kind of experience. Besides of that, the quality of the DevCentral content and the knowledge of other community members are absolutely astonishing. It makes simply a lot of fun for me to work within the DevCentral community and to learn every day a little bit more… DC: Tell us a little about the areas of BIG-IP expertise you have. KW: Over the years, I successfully implemented BIG-IP LTM, APM, ASM, and DNS Service deployments for our customers. Technologically, I internalized TMOS and its architecture very well and I pretty much learned how to write simple but also somewhat complex iRules to control the delivery of arbitrary data on their way from A to B in any possible fashion. DC: You are a Principal Consultant for IT Security at itacs GmbH - a German consulting company. Can you describe your typical workday? KW: Because of my history with Microsoft related infrastructures, my current workload is pretty versatile. Many of my current projects are still settled in the Microsoft / Windows system environment and are covering the design and review of security related areas. Right now, I’m working with several DAX companies and also LaaS, PaaS and SaaS service providers to analyze their Active Directory and System Management infrastructures and to design and implement a very unique, fundamental and comprehensive security concept to counter those dreaded PtH (Pass-the-Hash) and APT (Advance Persistent Threat) attacks we are facing these days. Over the last years, my F5 customer base has periodically grown so I would say my work is a 50:50 mix right now. I do F5 workshops, designs, implementations, second and third level support as well as configuration reviews and optimization of existing environments. I work with some big web 2.0 customers that have the demand to pretty much exhaust all the capabilities of an F5. This challenges me as a network architect and as an ADC developer. I realize every day that working with F5 products makes so much more fun than any Microsoft product I have ever dealt with. So in the future, I will even more put my focus on F5! DC: Describe one of your biggest BIG-IP challenges and how DevCentral helped in that situation. KW: In my opinion, the F5 products themselves are not that challenging – but sometimes the underlying technologies and the detailed project requirements are. But as long as those requirements can be drawn and explained on a sheet of paper, I am somewhat confident that the BIG-IP platform is able to support the requirements – thanks to the F5 developers who have created a platform which is not purely scenario driven but rather supports a comprehensive list of RFC standards which can be combined as needed. For an example, one of my largest customers operates an affiliate resource tracking system with three billion web requests per day with a pretty much aggressive session setup rate during peak hours. I have designed and implemented their BIG-IP LTM platform to offload SSL-encryption and the TCP-connection handling to various backend systems using well selected and performance optimized settings. Other scenarios require slightly more complex content switching, the selective use of pre-authentication and/or combination with IDS/IPS systems. To support those requirements, I developed a very granular and scalable iRule administration framework which is able to simplify the configuration by using rather easy-to-use iRule configuration files (operated by non TCL developers) which will then trigger the much more complex iRule code (written and tested by TCL developers) as needed. The latest version of my iRule administration framework (which is currently under testing/development) will be able to support a couple thousand websites on a single Virtual Server, where each websites can trigger handcrafted TCL code blocks as needed, but without adding linear or even exponential overhead to the system as the regular iRule approaches would do. The core and the configuration files of the latest version are heavily based on TCL procedures to create a very flexible code base and also conditional control structures, but completely without calling any TCL procedures during runtime to boost the performance dramatically. Sounds interesting? Then stay tuned, I am sure I will publish this framework to the CodeShare once it’s stable enough… 😉 DC: Lastly, if you weren’t an IT admin – what would be your dream job? Or better, when you were a kid – what did you want to be when you grew up? KW: I was typing my first assembler code out of a C64 magazine at the age of 10, so I really wanted to be a developer and/or IT admin since then. But besides of my current job, I can also imagine being a racecar driver. I really have petrol in my blood and pretty much enjoy driving on the German Autobahn. As an alternative, I could also imagine being a cook. I really love cooking and enjoy awesome food! DC: Thanks Kai! Just don't fire up that sterno while shifting gears!! Check out all of Kai’s DevCentral contributions and check out their blog websites: ops365.de, flow365.de and brandmysharepoint.de.What is BIG-IP Next?
BIG-IP Next LTM and BIG-IP Next WAF hit general availability back in October, and we hit the road for a tour around North America for its arrival party! Those who attended one of our F5 Academy sessions got a deep-dive presentation into BIG-IP Next conceptually, and then a lab session to work through migrating workloads and deploying them. I got to attend four of the events and discuss with so many fantastic community members what's old, what's new, what's borrowed, what's blue...no wait--this is no wedding! But for those of us who've been around the block with BIG-IP for a while, if not married to the tech, we definitely have a relationship with it, for better and worse, right? And that's earned. So any time something new, or in our case "Next" comes around, there's risk and fear involved personally. But don't fret. Seriously. It's going to be different in a lot of ways, but it's going to be great. And there are a crap-ton (thank you Mark Rober!) of improvements that once we all make it through the early stages, we'll embrace and wonder why we were even scared in the first place. So with all that said, will you come on the journey with me? In this first of many articles to come from me this year, I'll cover the high-level basics of what is so next about BIG-IP Next, and in future entries we'll be digging into the tech and learning together. BIG-IP and BIG-IP Next Conceptually - A Comparison BIG-IP has been around since before the turn of the century (which is almost old enough to rent a car here in the United States) and this year marks the 20 year anniversary of TMOS. That the traffic management microkernel (TMM) is still grokking like a boss all these years later is a testament to that early innovation! So whereas TMOS as a system is winding down, it's heart, TMM, will go on (cue sappy Celine Dion ditty in 3, 2, 1...) Let's take a look at what was and what is. With TMOS, the data plane and control plane compete for resources as it's one big system. With BIG-IP, the separation of duties is more explicit and intentionally designed to scale on the control plane. Also, the product modules are no longer either completely integrated in TMM or plugins to TMM, but rather, isolated to their own container structures. The image above might convey the idea that LTM or WAF or any of the other modules are single containers, but that's just shown that way for brevity. Each module is an array of containers. But don't let that scare you. The underlying kubernetes architecture is an abstraction that you may--but certainly are not required to--care about. TMM continues to be its awesome TMM self. The significant change operationally is how you interact with BIG-IP. With TMOS, historically you engage directly with each device, even if you have some other tools like BIG-IQ or third-party administration/automation platforms. With BIG-IP Next, everything is centralized on Central Manager, and the BIG-IP Next instances, whether they are running on rSeries, VELOS, or Virtual Edition, are just destinations for your workloads. In fact, outside of sidecar proxies for troubleshooting, instance logins won't even be supported! Yes, this is a paradigm shift. With BIG-IP Next, you will no longer be configuration-object focused. You will be application-focused. You'll still have the nerd-knobs to tweak and turn, but they'll be done within the context of an application declaration. If you haven't started your automation journey yet, you might not be familiar with AS3. It's been out now for years and works with BIG-IP to deploy applications declaratively. Instead of following a long pre-flight checklist with 87 steps to go from nothing to a working application, you simply define the parameters of your application in a blob of JSON data and click the easy button. For BIG-IP Next, this is the way. Now, in the Central Manager GUI, you might interact with FAST templates that deliver a more traditional view into configuring applications, but the underlying configuration engine is all AS3. For more, I hosted aseries of streams in December to introduce AS3 Foundations, I highly recommend you take the time to digest the basics. Benefits I'm Excited About There are many and you can read about them on the product page on F5.com. But here's my short list: API-first. Period. BIG-IP had APIs with iControl from the era before APIs were even cool, but they were not first-class citizens. The resulting performance at scale requires effort to manage effectively. Not only performance, but feature parity among iControl REST, iControl SOAP, tmsh, and the GUI has been a challenge because of the way development occurred over time. Not so with BIG-IP Next. Everything is API-first, so all tooling is able to consume everything. This is huge! Migration assistance. Central Manager has the JOURNEYS tool on sterroids built-in to the experience. Upload your UCS, evaluate your applications to see what can be migrated without updates, and deploy! It really is that easy. Sure, there's work to be done for applications that aren't fully compatible yet, but it's a great start. You can do this piece (and I recommend that you do) before you even think about deploying a single instance just to learn what work you have ahead of you and what solutions you might need to adapt to be ready. Simplified patch/upgrade process. If you know, you know...patches are upgrades with BIG-IP, and not in place at that. This is drastically improved with BIG-IP Next! Because of the containerized nature of the system, individual containers can be targeted for patching, and depending on the container, may not even require a downtime consideration. Release cycle. A more frequent release cadence might terrify the customers among us that like to space out their upgrades to once every three years or so, but for the rest of us, feature delivery to the tune of weeks instead of twice per year is an exciting development (pun intended!) Features I'm Excited About Versioning for iRules and policies. For those of us who write/manage these things, this is huge! Typically I'd version by including it in the title, and I know some who set release tags in repos. With Central Manager, it's built-in and you can deploy iRules and polices by version and do diffs in place. I'm super excited about this! Did I mention the API? On the API front...it's one API, for all functionality. No digging and scraping through the GUI, tmsh, iControl REST, iControl SOAP, building out a node.js app to deploy a custom API endpoint with iControl LX, if even possible with some of the modules like APM or ASM. Nope, it's all there in one API. Glorious. Centralized dashboards. This one is for the Ops teams! Who among us has spent many a day building custom dashboards to consume stats from BIG-IPs across your org to have a single pane of glass to manage? I for one, and I'm thrilled to see system, application, and security data centralized for analysis and alerting. Log/metric streaming. And finally, logs and metrics! Telemetry Streaming from the F5 Automation Toolchain doesn't come forward in BIG-IP Next, but the ideas behind it do. If you need your data elsewhere from Central Manager, you can set up remote logging with OpenTelemetry (see the link in the resources listed below for a first published example of this.) There are some great features coming with DNS, Access, and all the other modules when they are released as well. I'll cover those when they hit general availability. Let's Go! In the coming weeks, I'll be releasing articles on installation and licensing walk-throughs for Central Manager and the instances, andcontent from our awesome group of authors is already starting to flow as well. Here are a few entries you can feast your eyes on, including an instance Proxmox installation: For the kubernetes crowd, BIG-IP Next CNF Solutions for RedHat Openshift Installing BIG-IP Next Instance on Proxmox Remote Logging with BIG-IP Next and OpenTelemetry Are you ready? Grab a trial licensefrom your MyF5 dashboard and get going! And make sure to join us in the BIG-IP Next Academy group here on DevCentral. The launch team is actively engaged there for next-related questions/issues, so that's the place to be in your early journey! Also...if you want the ultimate jump-start for all things BIG-IP Next, join usatAppWorld 2024 in SanJose next month!
Maintenance Page
currently if all 4 servers go down all requests are routed to a 5th server that will display a user friendly page notifying the user that there is a technical problem and we are working on it. My question, is there a better way to do this?? Is there some built in way in the F5 to send a user friendly message that there is a technical issue without using another server?? Steve Albrecht
