Creating iRule for Persistence Profile
Dear Community, Could you assist me in creating an iRule for a Persistence Profile requirement related to an SSO application? When users access our application via desktop, they are presented with a QR code for scanning through a mobile app to authenticate and gain access. The issue arises when, after browsing the website from the desktop (with the session routed to one node via F5 LTM), another request from the mobile app after scanning the QR code is routed to a different node. Ideally, both requests should be directed to the same node. To resolve this, the iRule needs to compare the var topic parameter with the QR_AUTHENTICATION_CHANNEL_ID from the mobile request and ensure both are directed to the same node attached is the screenshot of the code and HTML code of the website /*<![CDATA[*/ var endpoint = "\/qr-websocket"; var topic = "80f95f6f-cecf-4ab6-a70b-1196194e4baa"; var prefix = "\/qrtopic"; var stompClient = null; $(function () { var socket = new SockJS(endpoint); stompClient = Stomp.over(socket); stompClient.connect({}, function (frame) { stompClient.subscribe(prefix + '/' + topic + '/verify', function (result) { console.log(result.body); let body = JSON.parse(result.body); if (body.error) { $("#qrerror").show(); } else if (body.success) { stompClient.disconnect(); $("#qrerror").hide(); $("#qrform #token").val(body.token); $("#qrform #deviceId").val(body.deviceId); $("#qrform").submit(); } }); }); }); /*]]>*/ Regards Omran Mohamed
Unable to edit or modify Policy is Case Sensitive Option in F5 WAF
Hello Team, I've encountered an issue with the WAF Case Sensitive Option in Version 16.1.2.2 Build 0.0.28. In the Security Settings under Application Security, specifically within Security Policies, the "Policy is Case Sensitive" setting is enabled, (Login LB > Security > Application Security > Security Policies > Policies List > [XXX Policy] > General Settings >> Policy is Case Sensitive : Yes) Where I am unable to modify it directly. Despite my efforts to resolve this by downloading and re-uploading the policy, the option to change the case sensitivity remains inaccessible. Additionally, I reviewed a related support article which suggested using an iRule as a workaround for case sensitivity issues. The proposed iRule is as follows: when HTTP_REQUEST { HTTP::path [string tolower [HTTP::path]] } While this iRule effectively converts the request path to lowercase, it does not resolve the need to configure case sensitivity within the WAF Policy itself. I seek assistance in either enabling the option to modify the case sensitivity directly within the WAF Policy settings or in finding an alternative method to achieve the desired configuration. Any insights or advanced troubleshooting steps would be greatly appreciated. Thank you.Forward ASM event logs to Virtual server
Greetings. I want to forward the logs coming to ASM Policies to 2 syslog servers for the purpose of Failover Load balancing. For this I created a VS running on port 514 and I send to the pool running on port 514 but it doesn't go. When I send it with a regular log profile, the logs are forwarded to me, but it needs to go from VS as a load balance (fail-over).
Priority Group activation between 10 servers
Hi All, Is it possible to enable the priority group activation between 10 servers- condition is that at a time any one server should up, if it goes down any other one server become active and serve the request. Meaning out of 10 servers 1 should serve the request on F5 LTM.
Script to send an email if Traffic-group failovers on F5
I am using this script to detect the status of a traffic-group and send out an email if it changes its status from Active to Standby, some how i am not getting any email when i flip over the traffic group between active standby boxes. Though i have tested email through CLI and mail works. need experts advice if i am missing any thing? #!/bin/bash # Variables EMAIL_TO="x@x.com" EMAIL_SUBJECT="HLR-STG-LB01 WHARF Traffic-Group Failover Alert" TRAFFIC_GROUP="wharf" CHECK_INTERVAL=60 LOG_FILE="/var/log/failover_notify.log" # Function to send email send_email() { local message=$1 echo -e "To: ${EMAIL_TO}\nSubject: ${EMAIL_SUBJECT}\n\n${message}" | ssmtp ${EMAIL_TO} } # Function to log messages log_message() { local message=$1 echo "$(date): ${message}" >> ${LOG_FILE} 2>&1 } # Function to get the current status of the traffic group get_traffic_group_status() { tmsh show cm traffic-group | grep "${TRAFFIC_GROUP}" } # Initial state previous_status=$(get_traffic_group_status) # Main loop while true; do current_status=$(get_traffic_group_status) if [[ "${previous_status}" != "${current_status}" ]]; then if echo "${current_status}" | grep -qi "standby"; then log_message "Traffic group ${TRAFFIC_GROUP} failed over to standby." send_email "Alert: Traffic group ${TRAFFIC_GROUP} has failed over to standby on another device." elif echo "${current_status}" | grep -qi "active"; then log_message "Traffic group ${TRAFFIC_GROUP} is now active." send_email "Info: Traffic group ${TRAFFIC_GROUP} is now active on this device." fi previous_status=${current_status} fi sleep ${CHECK_INTERVAL} done ~ ~ Added this script to crontab. ensured that script is running #ps aux | grep failover_notify.sh root 23928 0.0 0.0 115208 1500 pts/1 T 12:04 0:00 /bin/bash ./failover_notify.sh root 31495 0.0 0.0 114736 948 pts/1 S+ 12:52 0:00 grep failover_notify.shWAFaaS with SSL Orchestrator
Introduction Note: This article applies to SSL Orchestrator versions prior to 11.0. If using version 11.0 refer to the articleHERE This use case allows you to insert F5 WAF functionality as a Service in the SSL Orchestrator inspection zone. WAFaaS is the ability to insert ASM profiles into the SSL Orchestrator Service Chain for Inbound Topologies.This configuration is specific to a WAF policy running on the SSL Orchestrator device.WAF and SSL Orchestrator consume significant CPU cycles so care should be given when deploying both together.It is also possible to deploy WAF as a service on a separate BIG-IP device, in which case you’d simply configure an inline transparent proxy service.The ability to insert F5’s WAF into the Service Chain presents a significant customer benefit. This guide assumes you already have WAF/ASM profile(s) configured, licensed and provisioned on BIG-IP and wish to add this functionality to an Inbound Topology.In order to run WAF and SSL Orchestrator on the same device you will need an LTM license with SSL Orchestrator as an add-on option.You cannot add a WAF license to an SSL Orchestrator stand-alone license. SSL Orchestrator does not directly support inserting F5 WAF policies into the Service Chain.However, the F5 platform is flexible enough to handle many custom use cases.In this case, the ICAP service configuration exposes a framework that is useful for any number of specialized patterns, including adding a WAF policy to an SSLO service chain.We will configure an ICAP Service and attach the WAF policy to it. Steps: Create ICAP Service Disable Strictness on the Service Disable TCP monitor for the ICAP Pool ICAP Adapt profiles removed from the Virtual Server Application Security Policy enabled and a Policy assigned under Security Step #1: Create ICAP Service Note: These instructions assume an SSL Orchestrator Topology and Service Chain are already deployed and working properly.These instructions simply add WAFaaS to the existing Service Chain.It is entirely possible to create the WAFaaS during the initial Topology creation, in which case you would create the service during the workflow, then make the necessary changes after the topology has been created. From the SSL Orchestrator Guided Configuration click Services then Add Scroll to the bottom, select Generic ICAP Service and click Add Give it a name, WAFaaS in this example For ICAP Devices click Add on the right Enter an IP Address, 198.19.97.1 in this example and click Done. Note:the IP address you use does not have to be the one above.It’s just a local, non-routable address used as a placeholder in the service definition.This IP address will not be used. IP addresses 198.19.97.0 to 198.19.97.255 are owned by network benchmark tests and located in private networks. Scroll to the bottom and click Save & Next. The next screen is the Services Chain List.Click the name of the Service Chain you wish to add WAF functionality to, ssloSC_ServiceChain in this example. Note: The order of the Services in the Selected column is the order in which SSL Orchestrator will pass decrypted data to the device.This can be an important consideration if you want some devices to see, or not see, the actions taken by the WAF Service. Select the WAFaaS Service and click the right arrow to move it to Selected.Click Save. Click Save & Next Click Deploy You should receive a Success message Step #2: Disable Strictness on the Service From the SSL Orchestrator Configuration screen select Services.Click the padlock to Unprotect Configuration. Note:Disabling Strictness on the ICAP Service is needed to modify it and attach the WAFaaS policy.Strictness must remain disabled on this service and disabling strictness on the service has no effect on any other part of the SSL Orchestrator configuration. Click OK to Unprotect the Configuration Step #3: Disable tcp monitor for the ICAP Pool From Local Traffic select Pools > Pool List Select the WAFaaS Pool Under Active Health Monitors select tcp and click >> to move it to Available.This removes the Pool’s Monitor because otherwise it would be marked as down or unavailable. Click Update Note:The Health Monitor needs to be removed because there is no actual ICAP service to monitor. Step #4: ICAP Adapt profiles removed from the Virtual Server From Local Traffic select Virtual Servers > Virtual Server List Locate the WAFaaS ICAP service that ends in “-t-4”virtual server and select it Set the Request Adapt Profile and Response Adapt Profile to None to disable the default ICAP Profiles Click Update Step #5: Application Security Policy enabled and a Policy assigned under Security For the WAFaaS-t-4 Virtual Server click the Security tab Set Application Security Policy to Enabled Select the Security Policy you wish to use.Click Update when done Note: In specific versions of SSL Orchestrator there is one extra configuration item that needs to be modified. This is NOT required in other versions. If this change is made, when performing an upgrade it is not necessarily required to back out this change. Required versions: SSLO version 5.9.15 available on TMOS 14.1.4 SSLO versions 6.0-6.5 available on TMOX 15.0.x Navigate to “Local Traffic››Profiles : Other : Service” Select the Service profile named “ssloS_WAFaaS-service” Change the “Type” from “ICAP” to “F5 Module” Conclusion The configuration is now complete.Using the WAFaaS this way is functionally the same as using it by itself.There are no known limitations to this configuration.Issues with F5 appliance black holeing traffic
Hi wondering if anyone can help or has seen an issue similar to this? 2 tenants on 1 Host One tenant has the issue, the other doesn't. All upstream networks and devices assurance checked and logs analysed. Issue only present on Hostname: dcnn-lb01-int.circlehealthgroup.co.uk Key Info: CPU in the control plane consistently spikes at 100% (5-10 times per min) Outbound traffic is blackholed if session starts during CPU spikes. All outbound traffic types all affected - ICMP from tmos, Node polling, F5 sync messaging, snmp messages....etc If session starts outside of CPU spikes then issue isn't present - ICMP started will run continuously without drops Symptoms last < 2secs per "CPU event". Symptoms present as if the default route drops/changes, gateway is unreachable or traffic is blackholed. Repeating here but essential to note that this is only for newly established sessions during that window. Established sessions (e.g. continuous ICMP from tmos) are not affected during the same blackholing event window where new sessions are. Thanks in advance Dave
