F5 breaking Exchange authentication
We have Exchange 2016 going through our F5 BigIP. It works nicely. When we add our new Exchange 2019 server, clients are unable to authenticate using the desktop version of Outlook. Auth works fine without the F5 in the loop. Thanks in advance for any thoughts you might offer as our team as well as F5 support are stumped.
Disastser Recovery
Hello everyone, need to implement a Disaster recovery solution for a customer. I read the solution K39543431 but there are some points that are not clear for me. In order to build it, I need to configure the same vlans that are present on active/stand-by to disaster recovery devices, so that I needs to configure, for each vlan, only self ip. To sum up: the disaster and recovery device needs to reach all vlan configurated on the active/stand by device . it needs to be add as peer and configured as part of traffic group - in this way is possible to sync everything. Is it correct ? Someone knows if there is a guide or tutorial that is possible to download for having major information about how to do it ? Many thanks everyone for your time and consideration. Awaiting news. Rgds,The State Of HTTP/2 With F5 LTM
In this article, I will attempt to summarize the known challenges of an HTTP/2 full proxy setup, point out possible solutions, and document known bugs and incompatibilities. Most major browsers had added HTTP/2 support by the end of 2015. However, I hardly ever see F5 LTM setups with HTTP/2 full proxy configured.F5 BIG-IP Multi-Site Dashboard
A comprehensive real-time monitoring dashboard for F5 BIG-IP Application Delivery Controllers featuring multi-site support, DNS hostname resolution, member state tracking, and advanced filtering capabilities. A 170KB modular JavaScript application runs entirely in your browser, served directly from the F5's high-speed operational dataplane. One or more sites operate as Dashboard Front-Ends serving the dashboard interface (HTML, JavaScript, CSS) via iFiles, while other sites operate as API Hosts providing pool data through optimized JSON-based dashboard API calls. This provides unified visibility across multiple sites from a single interface without requiring even a read-only account on any of the BIG-IPs, allowing you to switch between locations and see consistent pool, member, and health status data with almost no latency and very little overhead. Think of it as an extension of the F5 GUI: near real-time state tracking, DNS hostname resolution (if configured), advanced search/filtering, and the ability to see exactly what changed and when. It gives application teams and operations teams direct visibility into application pool state without needing to wait for answers from F5 engineers, eliminating the organizational bottleneck that slows down troubleshooting when every minute counts. https://github.com/hauptem/F5-Multisite-DashboardSimplifying Application Health Monitoring with F5 BIG-IP
A simple agreement between BIG-IP administrators and application owners can foster smooth collaboration between teams. Application owners define their own simple or complex health monitors and agree to expose a conventional /health endpoint. When a /health endpoint responds with an HTTP 200 request, BIG-IP assumes the application is healthy based on the application owners' own criteria. The Challenge of Health Monitoring in Modern Environments F5 BIG-IP administrators in Network Operations (NetOps) teams often work with application teams because the BIG-IP acts as a full proxy, providing services like: TLS termination Load balancing Health monitoring Health checks are crucial for effective load balancing. The BIG-IP uses them to determine where to send traffic among back-end application servers. However, health monitoring frequently causes friction between teams. Problems with the Traditional Approach Traditionally, BIG-IP administrators create and maintain health monitors ranging from simple ICMP pings to complex monitors that: Simulate user transactions Verify HTTP response codes Validate payload contents Track application dependencies This leads to several issues: Knowledge Gap: NetOps may not fully grasp each application's intricacies. Change Management Overhead: Application updates require retesting monitors, causing delays. Production Risk: Monitors can break after application changes, incorrectly marking services as up/down. Team Friction: Troubleshooting failed health checks involves tedious back-and-forth between teams. A Cloud-Native Solution The cloud-native and microservices communities have patterns that elegantly solve these problems. One widely used pattern is the [health endpoint], which adapts well to BIG-IP environments. The /health Endpoint Convention Cloud-native applications commonly expose dedicated health endpoints like /health, /healthy, or /ready. These return standard status codes reflecting the application's state. The /health endpoint provides a clear contract between NetOps and application teams for BIG-IP integration. Implementing the Contract This approach establishes a simple agreement: Application Team Responsibilities: Implement /health to return HTTP 200 when the application is ready for traffic Define "healthy" based on application needs (database connectivity, dependencies, etc.) Maintain the health check logic as the application changes BIG-IP Team Responsibilities: Configure an HTTP monitor targeting the /health endpoint Treat 200 as "healthy", anything else as "unhealthy" Benefits of This Approach Aligned Expertise: Application teams define health based on their knowledge. Less Friction: BIG-IP configuration stays stable as applications evolve. Better Reliability: Health checks reflect true application health, including dependencies. Easier Troubleshooting: The /health endpoint can return detailed diagnostic info, but this is ignored by the BIG-IP and used strictly for troubleshooting. Implementation Examples F5 BIG-IP Health Monitor Configuration ltm monitor http /Common/app-health-monitor { defaults-from /Common/http destination *:* interval 5 recv 200 recv-disable none send "GET /health HTTP/1.1\r\nHost: example.com\r\nConnection: close\r\n\r\n" time-until-up 0 timeout 16 } Node.js Health Endpoint Implementation const express = require('express'); const app = express(); const port = 3000; app.get('/', (req, res) => { res.send('Application is running'); }); app.get('/health', async (req, res) => { try { const dbStatus = await checkDatabaseConnection(); const serviceStatus = await checkDependentServices(); if (dbStatus && serviceStatus) { return res.status(200).json({ status: 'healthy', database: 'connected', services: 'available', timestamp: new Date().toISOString() }); } res.status(503).json({ status: 'unhealthy', database: dbStatus ? 'connected' : 'disconnected', services: serviceStatus ? 'available' : 'unavailable', timestamp: new Date().toISOString() }); } catch (error) { res.status(500).json({ status: 'error', message: error.message, timestamp: new Date().toISOString() }); } }); async function checkDatabaseConnection() { // Check real database connection return true; } async function checkDependentServices() { // Check required service connections return true; } app.listen(port, () => { console.log(`Application listening at http://localhost:${port}`); }); Adopting this health check pattern can greatly reduce friction between NetOps and application teams while improving reliability. The simple contract of HTTP 200 for healthy provides the needed integration while letting each team focus on their expertise. For apps that can't implement a custom /health endpoint, BIG-IP admins can still use traditional ICMP or TCP port monitoring. However, these basic checks can't accurately reflect an app's true health and complex dependencies. This approach fosters collaboration and leverages the specialized knowledge of both network and application teams. The result is more reliable services and smoother operations.
Failed to execute iptable cmd: ," CMD="iptables -A SSH_ALLOW_RULES error
Hi Mates, After upgrading rseries F5 OS to 1.5.4, I observed the below error and I am unable to do SSH for my F5 OS machine version 1.5.4 from the network: 10.54.7.0/24. Rest all the networks are working fine and we are able to do SSH to the same F5 OS machine. Is it something that device was unable to update this entry into iptables. Do we have to manually re-configure this rule? ys-host-config[11678]: priority="Err" version=1.0 msgid=0x7001000000000062 msg="Failed to execute iptable cmd: ," CMD="iptables -A SSH_ALLOW_RULES -s 10.54.7.0/24 -p tcp -m state --state NEW --dport 22 -j ACCEPT -w &>/dev/null" ERR="EXITINFO: 4".Identify which virtual servers are using a specific SSL certificate
We use a wildcard SSL certificate for our QA sites. There are many of them. I am renewing the SSL cert but have no idea which Virtuals are using it. Is there an easy way to determine this other than checking each and every virtual, listing the Client-ssl profile and then looking up the profile to see what certificate is being used?
Users account sessions mixed up..
Hi < I have been asked to look into a very strange issue. And not sure from where to start. I dont think it is happening due to Big IP. But could someone please provide a insight. Only persistence cookie is sent by big ip. Session and auth cookie is sent by back end servers. Although Big IP just add 'secure' parameter into all those cookies. Summary of the issue is below. We need your help on this critical matter. A user has reported that for some reason, her sessions got mixed up. That is, she logged under Username JFSM first and went to My Billing page to perform a function. Then she logged as JSMIREZ and was going to the My Billing Page for the new account. Instead, of getting to right page, she was directed to the previous log-in’s Account Summary page. Now, she confirmed she was only using one browser session. Is there any chance that sessions can get mixed up from the big ip for the same browser? That is, somehow a prior page request can be re-sent to the current session? I know am grasping at straws here but I am not sure what are the possibilities. I do have to note that the way the site has been working is that when I open up a browser and log-in to a User Account, let’s call Account A. Then on the same browser, I open up a new window and try to log-in as Account B; I would still get the information for Account A. The reason being, that this is considered as the same session/browser and considers Account A as still active for this session and not Account B even if the requests were made from different windows/tabs. One thing for sure though, if there are multiple users hitting the servers from different browsers, is there any chance at all where their requests can get mixed up? That is, you can have Users A, B, and C all hitting the website at the same time. And each of them are using separate browsers from different ip addresses. Is there any chance that the load balancer would ever mix up their sessions where User A’s page requests will be returned to User C and User C’s requests are returned to User B enabling them to see someone else’s account?
