F5OS cloud-init on 21.1 does tenants come with DO and AS3 RPM installed?
Hello Everyone, This great new feature https://techdocs.f5.com/en-us/bigip-21-1-0/big-ip-f5os-cloud-init-support-velos-rseries/cloud-init-support-velos-rseries.html is not very well described. I think F5 making a demo session or a Guide with pictures will be helpful. For example do the F5os Tenants come with RPM AS3 and DO installed by default for this to work ? Other than that it is mentioned that the DO yaml file needs to be hosted on F5OS ? Where exactly ?
F5 DO - gui text and management firewall config
Hello Guys, Hope you all are doing well. I am provisioing a standalone F5 in azure using declarative onboarding. I was able to configure most of the parameters using the json declaration, but I was not able to find a configuration for the following 2, 01 - for gui security banner text configuration 02 - management security firewall configuration to mitigate the api access vulnerablilty. If any of you were able to find a config for the above 2 scenarios, would you be kind enough to share it with me.
Need help with DO declaration resource provisioning
Hi I am trying to setup a big-ip vCPM guest using DO declation using postman and below is the script I am using. Script-1 "myProvisioningltm": { "class": "Provision", "ltm": "nominal" }, "Provisioningavr": { "class": "Provision", "avr": "nominal" }, "myProvisioningaasm": { "class": "Provision", "asm": "nominal" } } script-2 "myProvisioning": { "class": "Provision", "ltm": "nominal", "avr": "nominal", "asm": "nominal" }, I get a 200 OK response from the device and after the initial reboot device will open provision ltm module as shown below }, "currentProvision": { "afm": "none", "am": "none", "apm": "none", "asm": "none", "avr": "none", "dos": "none", "fps": "none", "gtm": "none", "ilx": "none", "lc": "none", "ltm": "nominal", "swg": "none", "urldb": "none", "class": "Provision" }, is their anything wrong with the script?F5 Automation Toolchain Upload
Problem this snippet solves: This script uploads, installs, and verifies the three toolchain components: declarative onboarding, as3, and telemetry streaming. Note: bip.py in BIGREST must be modified to allow 202 response codes. The author will have this fixed in the next release, but you will need to modify line 183 in big.py: if response.status_code != 200 and response.status_code != 201 and response.status_code != 202: How to use this snippet: python toolchain_prep.py 10.0.2.26 admin admin Instantiating BIG-IP (host 10.0.2.26) Uploading packages Uploading f5-declarative-onboarding-1.20.0-2.noarch.rpm Uploading f5-appsvcs-3.27.0-3.noarch.rpm Uploading f5-telemetry-1.19.0-3.noarch.rpm Installing packages Installing f5-declarative-onboarding-1.20.0-2.noarch.rpm Installing f5-appsvcs-3.27.0-3.noarch.rpm Installing f5-telemetry-1.19.0-3.noarch.rpm Quick break to register packages... Verifying packages f5-declarative-onboarding-1.20.0-2.noarch.rpm installed and verified f5-appsvcs-3.27.0-3.noarch.rpm installed and verified f5-telemetry-1.19.0-3.noarch.rpm installed and verified ---complete--- Tested this on version: No Version Found
Log the TLS version of a client connecting to a TCP VIP with no HTTP or client-ssl Profile
Hello, I have a TCP VIP on port 995 with no HTTP Profile or client-ssl profile. There are several clients that makes SSL connections to this VIP. I need to know the client SSL/TLS version. I tried to apply the below irule and it threw me the following error.. when CLIENTSSL_HANDSHAKE { if { [info exists logged] && $logged == 1 }{ #Do nothing. Already logged for this connection } else { set logged 1 log "WAARDE TLS1.0 check, from [IP::remote_addr] to vip [IP::local_addr] Cipher [SSL::cipher name]:[SSL::cipher version]:[SSL::cipher bits] " } } 01070394:3: CLIENTSSL_HANDSHAKE event in rule (/Common/TLS-Version-2) requires an associated CLIENTSSL profile on the virtual server (/Common/vs_exchange-2016_pop3_MWDC). I really need an irule to help me log the incoming client TLS versions Please help. Thanks :)Manage BIG-IPs in Azure using Terraform Cloud
Introduction In this article I’ll outline a suite of demonstration resources designed to help you and your IT team explore the possibilities of applying DevOps practices in your own environments. The demonstration resources described below show how tools like Git, HashiCorp Terraform, HashiCorp Sentinel, Chef Inspec and F5's Automation Toolchain can be used to introduce some of the practices listed above to F5 BIG-IPs and the IT services they help deliver. By following along with the README in the demonstration repository and the video walk-throughs listed below, you should be able to run this demonstration on your own. Software Delivery Key Practices IT Industry research, such as Accelerate, shows improving a company's ability to deliver software has a significant positive benefit to their overall success. The following practices and design principles are cornerstones to that improvement. Version control of code and configuration Automation of Deployment Automation of Testing and Test Data Management "Shifting Left" on Security Loosely Coupled Architectures Pro-active Notification Caveats These repositories use simplifying demonstration shortcuts for password, key, and network security. Production-ready enterprise designs and workflows should be used in place of these shortcuts. DO NOT ASSUME THAT THE CODE AND CONFIGURATION IN THESE REPOSITORIES IS PRODUCTION-READY The particular source control approach shown in this demonstration is one of many. Before using this approach to support your Infrastructure as Code and Configuration Management assets and workflows, you should learn about different patterns of source code management and determine what best fits your team's needs. A variety of tools are used in this demonstration. In most cases they are not exclusively required and can be replaced with other similar tools. The demonstration uses a licensed version of Terraform Cloud in order to demonstrate the capabilities of HashiCorp Sentinel. If you are using the free version of Terraform Cloud you won't be able to try the policy compliance use-cases, and the rest of the demonstration code should work as expected. Setting up your demonstration automation host Before running the demonstration code, you'll need to set up the IDE host and the Azure account. Instructions for those steps are here Video walk-throughs Fork the repository and open it in Visual Studio Code (1m36s) Once the tools are installed, you can create your own copy of the repository and open it in your IDE. In the videos, Visual Studio Code is used as the IDE. In order to follow along, you'll need to create your own repository in order to set up the Terraform Cloud configuration and make your own adjustments to build configuration (e.g. the number of application servers deployed) Set up a Terraform Cloud workspace (1m38s) Before running the Terraform Cloud workflow, a Terraform Cloud workspace is required. This video steps you through manually configuring the workspace and linking it to your cloned repository. Programmatically set up Terraform Cloud workspaces for production, test, and development (10m40s) Setting up the workspaces programmatically has the benefits of rapid consistent results and executable knowledge in the form of scripts and configuration files. In this video we step you through programmatically building workspaces for production, test, and development environments using this repository. We also programmatically configure simple source-controlled compliance Sentinal policies. Initial build of production, test, and development (7m59s) Everything should be ready for the first build of your production, test, and development environments. In this video, we step you through manually triggering Terraform Cloud builds. In addition, we'll see the impact of Sentinel policies in use, how to override policies that have been triggered, and the audit trail that results. Automated testing of production (4m18s) Once your environment builds have completed, it's critical to validate that they are fit for use. In this video, we step you through a simple set of tests that validate the readiness of the F5 BIG-IPs built by the Terraform Cloud workflow. These tests are not comprehensive, but demonstrate the benefits of an executable "definition of done." The source of an updated version of the Inspec tests used in the demonstration is here. Manual inspection of production (2m45s) In this video, we walk through the BIG-IPs that were built in the production environment. We inspect the virtual servers and their associated pools, noting the number of application servers that were built and joined to the pool. Programmatically add application servers and include them in the BIG-IP virtual server (8m6s) In this video, we explore the use-case of expanding the pool in the previously built production environment, using a simple change in source control. We'll see the Terraform Cloud workflow automatically trigger a new build based on a merge commit to your cloned repository. New application servers will be built and automatically added to the pool by F5's Service Discovery iApp. Update WAF from a source control repository (no video walk-through) We leave it as an exercise for the reader (or possibly an updated video) to look for the WAF deployed with the virtual server. The WAF is retrieved from source control here. In addition, you can experiment with changing the version of the WAF in the AS3 template in the stanza shown below. Usable values for versions are 0.1.0, 0.1.1, 0.2.0, and 0.2.1. If you choose to do this, follow the same workflow shown in the previous video about scaling the number of application servers. "ASM_Policy": { "class": "WAF_Policy", "url": "https://github.com/mjmenger/waf-policy/raw/0.1.1/asm_policy.xml", "ignoreChanges": false } What's next? If you've followed along through the all of the use-cases in the demonstration repository, you have seen the following: Source-controlled build of an application environment, including BIG-IPs, virtual servers, pools, and WAF policies. Managed changes with logging of authoring and approvals. Automated scaling of application resources and BIG-IP configuration. Automated updates to BIG-IP WAF policies. If you want to realize the benefits of these practices for your IT service delivery, please reach out to your F5 account team.Lightboard Lessons: F5 Automation Toolchain
In this episode of Lightboard Lessons, Jason introduces the F5 Automation Toolchain, a suite of tools that enable programmatic declarative interfaces for BIG-IP device onboarding, application services, and telemetry for integration into your CI/CD flows. Resources F5 Automation Toolchain (F5.com introduction) F5 Declarative Onboarding (Clouddocs) F5 Application Services (Clouddocs) F5 Telemetry Streaming (Clouddocs) How Does F5 AS3 Really Work Under the Hood (article) F5 Services in a CI/CD Pipeline (demo) Automate Application Delivery with F5 Hashicorp Terraform and Consul (article)
iRule - http_req sideband request rejected by IIS Backend - Invalid Hostname
Hi I've got an irule performing two consecutive sideband http request to a single IIS backend (1 pool member). This backend has multiple API listening over HTTPS 443 with specific hostname (https://api1, https://api2) and SNI activation. Based on the client request /api/route1 or /api/route2, I'm changing the hostname on the fly as the SSO kerberos to request token for the good hostname, set ws_status [call /Common/HSSR::http_req -state hstate -uri $ws_uri -method [HTTP::method] -type "application/json" -headers $sb_headers -debug 1 -rbody ws_resp_body -userid $userName #do something call /Common/HSSR::http_close hstate set ws_status [call /Common/HSSR::http_req -state hstate -uri $ws_uri2 -method [HTTP::method] -type "application/json" -headers $sb_headers -debug 1 -rbody ws_resp_body -userid $userName #do something call /Common/HSSR::http_close hstate And in the sideBand iRule, I've got this in HTTP_REQUEST if { [HTTP::uri] starts_with "/api/v1/route1"} { HTTP::header replace Host $static::EV2_SIDEBAND_HOSTNAME_DCO WEBSSO::select sso-kerberos-1 } elseif { [HTTP::uri] starts_with "/api/v1/route2"} { HTTP::header replace Host $static::EV2_SIDEBAND_HOSTNAME_XS2A WEBSSO::select sso-kerberos-2 } Issue I'm facing is that the second call is rejected directly by IIS (logs found in http.sys) : Http response : <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""http://www.w3.org/TR/html4/strict.dtd"> <HTML><HEAD><TITLE>Bad Request</TITLE> <META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD> <BODY><h2>Bad Request - Invalid Hostname</h2> <hr><p>HTTP Error 400. The request hostname is invalid.</p> </BODY></HTML> We checked the configuration of both api and it's both accessible from browser outside of the sideband irule. so hostname is good, ssl certificate is good, etc... If someone has any clue, I'll be grateful. Thks
