BigIP Report Old
Problem this snippet solves: This codeshare has been deprecated due to a hosting platform corruption. I have moved code and conversation to a new record (on the same original URL) https://devcentral.f5.com/s/articles/bigip-report can be Overview This is a script which will generate a report of the BigIP LTM configuration on all your load balancers making it easy to find information and get a comprehensive overview of virtual servers and pools connected to them. This information is used to relay information to our NOC and developers to give them insight in where things are located and to be able to plan patching and deploys. I also use it myself as a quick way get information or gather data used as a foundation for RFC's, ie get a list of all external virtual servers without compression profiles. The script has been running on 13 pairs of load balancers, indexing over 1200 virtual servers for several years now and the report is widely used across the company and by many companies and governments across the world. It's easy to setup and use and only requires guest permissions on your devices. Demo/Preview Please note that it takes time to make these so sometimes they're a bit outdated and they only cover one HA pair. However, they still serve the purpose of showing what you can expect from the report. Interactive demo http://loadbalancing.se/bigipreportdemo/ Screen shots The main report: The device overview: Certificate details: How to use this snippet: This codeshare has been deprecated due to a hosting platform corruption. I have moved code and conversation to a new record (on the same original URL) https://devcentral.f5.com/s/articles/bigip-report Installation instructions BigipReport REST This is the only branch we're updating since middle of 2020 and it supports 12.x and upwards (maybe even 11.6). Download: https://loadbalancing.se/downloads/bigipreport-v5.5.4.zip Documentation, installation instructions and troubleshooting: https://loadbalancing.se/bigipreport-rest/ Docker support This will be the recommended way of running bigipreport in the near future. It's still undergoing testing but it's looking really good so far. https://loadbalancing.se/2021/01/05/running-bigipreport-on-docker/ BigipReport (Legacy) Older version of the report that only runs on Windows and is depending on a Powershell plugin originally written by Joe Pruitt (F5). BigipReport (Stable): https://loadbalancing.se/downloads/bigipreport-5.3.1.zip BigipReport (BETA): https://loadbalancing.se/downloads/bigipreport-5.4.0-beta.zip iControl Snapin: https://loadbalancing.se/downloads/f5-icontrol.zip Documentation and installation instructions: https://loadbalancing.se/bigip-report/ Upgrade instructions Protect the report using APM and active directory Written by DevCentral member Shann_P: https://loadbalancing.se/2018/04/08/protecting-bigip-report-behind-an-apm-by-shannon-poole/ Got issues/problems/feedback? Still have issues? Drop a comment below. We usually reply quite fast. Any bugs found, issues detected or ideas contributed makes the report better for everyone, so it's always appreciated. --- Also trying out a Discord channel now. You're welcome to hang out with us there: https://discord.gg/7JJvPMYahA Code : 85931,86647,90730 Tested this on version: 13.0
F5 iApp Automated Backup
Problem this snippet solves: This is now available on GitHub! Please look on GitHub for the latest version, and submit any bugs or questions as an "Issue" on GitHub: (Note: DevCentral admin update - Daniel's project appears abandoned so it's been forked and updated to the link below. @damnski on github added some SFTP code that has been merged in as well.) https://github.com/f5devcentral/f5-automated-backup-iapp Intro Building on the significant work of Thomas Schockaert (and several other DevCentralites) I enhanced many aspects I needed for my own purposes, updated many things I noticed requested on the forums, and added additional documentation and clarification. As you may see in several of my comments on the original posts, I iterated through several 2.2.x versions and am now releasing v3.0.0. Below is the breakdown! Also, I have done quite a bit of testing (mostly on v13.1.0.1 lately) and I doubt I've caught everything, especially with all of the changes. Please post any questions or issues in the comments. Cheers! Daniel Tavernier (tabernarious) Related posts: Git Repository for f5-automated-backup-iapp (https://github.com/tabernarious/f5-automated-backup-iapp) https://community.f5.com/t5/technical-articles/f5-automated-backups-the-right-way/ta-p/288454 https://community.f5.com/t5/crowdsrc/complete-f5-automated-backup-solution/ta-p/288701 https://community.f5.com/t5/crowdsrc/complete-f5-automated-backup-solution-2/ta-p/274252 https://community.f5.com/t5/technical-forum/automated-backup-solution/m-p/24551 https://community.f5.com/t5/crowdsrc/tkb-p/CrowdSRC v3.2.1 (20201210) Merged v3.1.11 and v3.2.0 for explicit SFTP support (separate from SCP). Tweaked the SCP and SFTP upload directory handling; detailed instructions are in the iApp. Tested on 13.1.3.4 and 14.1.3 v3.1.11 (20201210) Better handling of UCS passphrases, and notes about characters to avoid. I successfully tested this exact passphrase in the 13.1.3.4 CLI (surrounded with single quote) and GUI (as-is): `~!@#$%^*()aB1-_=+[{]}:./? I successfully tested this exact passphrase in 14.1.3 (square-braces and curly-braces would not work): `~!@#$%^*()aB1-_=+:./? Though there may be situations these could work, avoid these characters (separated by spaces): " ' & | ; < > \ [ ] { } , Moved changelog and notes from the template to CHANGELOG.md and README.md. Replaced all tabs (\t) with four spaces. v3.1.10 (20201209) Added SMB Version and SMB Security options to support v14+ and newer versions of Microsoft Windows and Windows Server. Tested SMB/CIFS on 13.1.3.4 and 14.1.3 against Windows Server 2019 using "2.0" and "ntlmsspi" v3.1.0: Removed "app-service none" from iCall objects. The iCall objects are now created as part of the Application Service (iApp) and are properly cleaned up if the iApp is redeployed or deleted. Reasonably tested on 11.5.4 HF2 (SMB worked fine using "mount -t cifs") and altered requires-bigip-version-min to match. Fixing error regarding "script did not successfully complete: (can't read "::destination_parameters__protocol_enable": no such variable" by encompassing most of the "implementation" in a block that first checks $::backup_schedule__frequency_select for "Disable". Added default value to "filename format". Changed UCS default value for $backup_file_name_extension to ".ucs" and added $fname_noext. Removed old SFTP sections and references (now handled through SCP/SFTP). Adjusted logging: added "sleep 1" to ensure proper logging; added $backup_directory to log message. Adjusted some help messages. New v3.0.0 features: Supports multiple instances! (Deploy multiple copies of the iApp to save backups to different places or perhaps to keep daily backups locally and send weekly backups to a network drive.) Fully ConfigSync compatible! (Encrypted values now in $script instead of local file.) Long passwords supported! (Using "-A" with openssl which reads/writes base64 encoded strings as a single line.) Added $script error checking for all remote backup types! (Using 'catch' to prevent tcl errors when $script aborts.) Backup files are cleaned up after any $script errors due to new error checking. Added logging! (Run logs sent to '/var/log/ltm' via logger command which is compatible with BIG-IP Remote Logging configuration (syslog). Run logs AND errors sent to '/var/tmp/scriptd.out'. Errors may include plain-text passwords which should not be in /var/log/ltm or syslog.) Added custom cipher option for SCP! (In case BIG-IP and the destination server are not cipher-compatible out of the box.) Added StrictHostKeyChecking=no option. (This is insecure and should only be used for testing--lots of warnings.) Combined SCP and SFTP because they are both using SCP to perform the remote copy. (Easier to maintain!) Original v1.x.x and v2.x.x features kept (copied from an original post): It allows you to choose between both UCS or SCF as backup-types. (whilst providing ample warnings about SCF not being a very good restore-option due to the incompleteness in some cases) It allows you to provide a passphrase for the UCS archives (the standard GUI also does this, so the iApp should too) It allows you to not include the private keys (same thing: standard GUI does it, so the iApp does it too) It allows you to set a Backup Schedule for every X minutes/hours/days/weeks/months or a custom selection of days in the week It allows you to set the exact time, minute of the hour, day of the week or day of the month when the backup should be performed (depending on the usefulness with regards to the schedule type) It allows you to transfer the backup files to external devices using 4 different protocols, next to providing local storage on the device itself SCP (username/private key without password) SFTP (username/private key without password) FTP (username/password) SMB (now using TMOS v12.x.x compatible 'mount -t cifs', with username/password) Local Storage (/var/local/ucs or /var/local/scf) It stores all passwords and private keys in a secure fashion: encrypted by the master key of the unit (f5mku), rendering it safe to store the backups, including the credentials off-box It has a configurable automatic pruning function for the Local Storage option, so the disk doesn't fill up (i.e. keep last X backup files) It allows you to configure the filename using the date/time wildcards from the tcl [clock] command, as well as providing a variable to include the hostname It requires only the WebGUI to establish the configuration you desire It allows you to disable the processes for automated backup, without you having to remove the Application Service or losing any previously entered settings For the external shellscripts it automatically generates, the credentials are stored in encrypted form (using the master key) It allows you to no longer be required to make modifications on the linux command line to get your automated backups running after an RMA or restore operation It cleans up after itself, which means there are no extraneous shellscripts or status files lingering around after the scripts execute How to use this snippet: Find and download the latest iApp template on GitHub (e.g "f5.automated_backup.v3.2.1.tmpl.tcl"). Import the text file as an iApp Template in the BIG-IP GUI. Create an Application Service using the imported Template. Answer the questions (paying close attention to the help sections). Check /var/tmp/scriptd.out for general logs and errors. Tested this on version: 16.0
PowerShell module for the F5 LTM REST API
Problem this snippet solves: To report an issue with the F5-LTM or F5-BIGIP modules, please use the Issues sections of the GitHub repos (here and here) instead of commenting here. Thanks! This PowerShell module uses the iControlREST API to manipulate and query pools, pool members, virtual servers, and iRules. It aims to support version 11.5.1 and higher, and to conform to the schedule for technical support of versions, though this may eventually prove to become difficult. The module currently includes some functionality that, strictly speaking, is outside the scope of the LTM module. Hence, there is an active effort to wrap this LTM module into a larger BIG-IP module, and relocate that functionality elsewhere within that parent module, as well as expand the scope of functionality to include BIG-IP DNS (formerly GTM) and possibly other areas. Both the LTM module and the parent BIG-IP module are projects on github. Please use these projects to report any issues you discover. Thanks! The module contains the following functions. Add-iRuleToVirtualServer Add-iRuleToVirtualServer Add-PoolMember Add-PoolMonitor Disable-PoolMember Disable-VirtualServer Enable-PoolMember Enable-VirtualServer Get-CurrentConnectionCount (deprecated; use Get-PoolMemberStats | Select-Object -ExpandProperty 'serverside.curConns') Get-F5Session (will be deprecated in future versions. use New-F5Session) Get-F5Status Get-HealthMonitor Get-HealthMonitorType Get-iRule Get-iRuleCollection (deprecated; use Get-iRule) Get-Node Get-BIGIPPartition Get-Pool Get-PoolList (deprecated; use Get-Pool) Get-PoolMember Get-PoolMemberCollection (deprecated; use Get-PoolMember) Get-PoolMemberCollectionStatus Get-PoolMemberDescription (deprecated; use Get-PoolMember) Get-PoolMemberIP (deprecated; use Get-PoolMember) Get-PoolMembers (deprecated; use Get-PoolMember) Get-PoolMemberStats Get-PoolMemberStatus (deprecated; use Get-PoolMember) Get-PoolMonitor Get-PoolsForMember Get-StatusShape Get-VirtualServer Get-VirtualServeriRuleCollection (deprecated; use Get-VirtualServer | Where rules | Select -ExpandProperty rules) Get-VirtualServerList (deprecated; use Get-VirtualServer) Invoke-RestMethodOverride New-F5Session New-HealthMonitor New-Node New-Pool New-VirtualServer Remove-HealthMonitor Remove-iRule Remove-iRuleFromVirtualServer Remove-Pool Remove-PoolMember Remove-PoolMonitor Remove-ProfileRamCache Remove-Node Remove-VirtualServer Set-iRule Set-PoolLoadBalancingMode (deprecated; use Set-Pool) Set-PoolMemberDescription Set-Pool Set-VirtualServer Sync-DeviceToGroup Test-F5Session Test-Functionality Test-HealthMonitor Test-Node Test-Pool Test-VirtualServer How to use this snippet: To use the module, click 'Download Zip', extract the files, and place them in a folder named F5-LTM beneath your PowerShell modules folder. By default, this is %USERPROFILE%\Documents\WindowsPowerShell\Modules. The WindowsPowerShell and Modules folders may need to be created. You will most likely need to unblock the files after extracting them. Use the Unblock-File PS cmdlet to accomplish this. The Validation.cs class file (based on code posted by Brian Scholer) allows for using the REST API with LTM devices with self-signed SSL certificates. Nearly all of the functions require an F5 session object as a parameter, which contains the base URL for the F5 LTM and a credential object for a user with privileges to manipulate the F5 LTM via the REST API. Use the New-F5session function to create this object. This function expects the following parameters: The name or IP address of the F5 LTM device A credential object for a user with rights to use the REST API An optional TokenLifespan value for extending the life of the authentication token past the default 20 minutes You can create a credential object using Get-Credential and entering the username and password at the prompts, or programmatically like this: $secpasswd = ConvertTo-SecureString "PlainTextPassword" -AsPlainText -Force $mycreds = New-Object System.Management.Automation.PSCredential "username", $secpasswd Thanks to Kotesh Bandhamravuri and his blog entry for this snippet. There is a function called Test-Functionality that takes an F5Session object, a new pool name, a new virtual server, an IP address for the virtual server, and a computer name as a pool member, and validates nearly all the functions in the module. I've also contributed this code sample for how to gather some basic info about your LTM with this PS module. The module has been tested on: 11.5.1 Build 8.0.175 Hotfix 8 and later 11.6.0 Build 5.0.429 Hotfix 4 and later 12.0 / 12.1 13.0 Code : https://github.com/joel74/POSH-LTM-Rest Tested this on version: 11.5BIG-IP Report
Problem this snippet solves: Overview This is a script which will generate a report of the BIG-IP LTM configuration on all your load balancers making it easy to find information and get a comprehensive overview of virtual servers and pools connected to them. This information is used to relay information to NOC and developers to give them insight in where things are located and to be able to plan patching and deploys. I also use it myself as a quick way get information or gather data used as a foundation for RFC's, ie get a list of all external virtual servers without compression profiles. The script has been running on 13 pairs of load balancers, indexing over 1200 virtual servers for several years now and the report is widely used across the company and by many companies and governments across the world. It's easy to setup and use and only requires auditor (read-only) permissions on your devices. Demo/Preview Interactive demo http://loadbalancing.se/bigipreportdemo/ Screen shots The main report: The device overview: Certificate details: How to use this snippet: Installation instructions BigipReport REST This is the only branch we're updating since middle of 2020 and it supports 12.x and upwards (maybe even 11.6). Downloads: https://loadbalancing.se/downloads/bigipreport-v5.7.13.zip Documentation, installation instructions and troubleshooting: https://loadbalancing.se/bigipreport-rest/ Docker support https://loadbalancing.se/2021/01/05/running-bigipreport-on-docker/ Kubernetes support https://loadbalancing.se/2021/04/16/bigipreport-on-kubernetes/ BIG-IP Report (Legacy) Older version of the report that only runs on Windows and is depending on a Powershell plugin originally written by Joe Pruitt (F5) BIG-IP Report (only download this if you have v10 devices): https://loadbalancing.se/downloads/bigipreport-5.4.0-beta.zip iControl Snapin https://loadbalancing.se/downloads/f5-icontrol.zip Documentation and Installation Instructions https://loadbalancing.se/bigip-report/ Upgrade instructions Protect the report using APM and active directory Written by DevCentral member Shann_P: https://loadbalancing.se/2018/04/08/protecting-bigip-report-behind-an-apm-by-shannon-poole/ Got issues/problems/feedback? Still have issues? Drop a comment below. We usually reply quite fast. Any bugs found, issues detected or ideas contributed makes the report better for everyone, so it's always appreciated. --- Join us on Discord: https://discord.gg/7JJvPMYahA Code : BigIP Report Tested this on version: 12, 13, 14, 15, 16CORS implementation
Problem this snippet solves: Pretty self-explanatory - we had to implement CORS (Cross-Origin-Resource-Sharing) where we had multiple domains, all of which had to be able to make AJAX calls to API's in our 'api.example.com' subdomain. Additionally, we had some partners who also need to be able to call our API's. In some cases, we had to pass cookies in the request. In the past, various developers had created backend Java code to return the CORS response headers, but almost invariably they did an incomplete job - either returning an invalid value or not returning all the required headers or writing the code such that it wasn't portable across applications. Therefore, I decided to write some 'common' CORS handling code, which would have the benefit of doing 'proper' origin checking and would also immediately return the OPTIONS preflight response directly from F5, thus improving performance. After much hacking around, here is what I came up with. We used a class to define multiple top-level domains as 'allowed' origins - this would contain both your domains and also those of any partners whom you want to allow to make CORS requests to your site. If you just have multiple subdomains on a single domain (e.g. www.example.com, api.example.com, code.example.com), you could simply use [HTTP::header Origin] ends_with ".example.com" - it's a little simpler. I'm always returning the Access-Control-Allow-Credentials: true response header for 'valid' non-OPTIONS (e.g. GET/POST) CORS requests, even if it's not required (i.e. even if the withCredentials flag was not set in the request) - unfortunately, there is no way to know whether it is needed simply by looking at the request, so it's the only way to ensure client errors don't occur. I'm passing the value of the Access-Control-Request-Method request header in the Access-Control-Allow-Methods response header (e.g. a single value of 'GET' or 'POST' or whatever) - in most implementations, you'll see people returning somethign like a string like Access-Control-Allow-Methods: GET, POST, PUT, but there's really no significant benefit to doing this - much simpler to only return what is passed. In either case, it will be cached by the browser because of the Access-Control-Max-Age response header. Note that because you will be returning a specific Access-Control-Allow-Origin value, rather than '*', you should also return the Vary: Origin response header. This may have issues with browser caching or if you use a CDN like Akamai or Cloudflare - you should consult any CDN product documentation. There are multiple good sources for explaining the Vary header - Google is your friend. If anyone has any comments, please add them, good or bad! I would love to know if someone finds this snippet useful... Code : # Domains that are allowed to make cross-domain calls to example.com class allowed_origins { ".example.com" ".example2.com" ".goodpartner.com" } when HTTP_REQUEST { unset -nocomplain cors_origin if { [class match [HTTP::header Origin] ends_with allowed_origins] } { if { ( [HTTP::method] equals "OPTIONS" ) and ( [HTTP::header exists "Access-Control-Request-Method"] ) } { # CORS preflight request - return response immediately HTTP::respond 200 "Access-Control-Allow-Origin" [HTTP::header "Origin"] \ "Access-Control-Allow-Methods" [HTTP::header "Access-Control-Request-Method"] \ "Access-Control-Allow-Headers" [HTTP::header "Access-Control-Request-Headers"] \ "Access-Control-Max-Age" "86400" \ "Vary" "Origin" } else { # CORS GET/POST requests - set cors_origin variable set cors_origin [HTTP::header "Origin"] } } } when HTTP_RESPONSE { # CORS GET/POST response - check cors_origin variable set in request if { [info exists cors_origin] } { HTTP::header insert "Access-Control-Allow-Origin" $cors_origin HTTP::header insert "Access-Control-Allow-Credentials" "true" HTTP::header insert "Vary" "Origin" } } Tested this on version: 11.0ProxyPass v10/v11
Problem this snippet solves: iRule to replace the functionality of Apache Webserver ProxyPass and ProxyPassReverse functions. Allows you to do hostname and path name modifications as HTTP traffic passes through the LTM. This optimized version requires TMOS v10 or higher. If you are using APM for authentication on the virtual server, please use the ProxyPass_for_use_with_APM iRule instead. (Full documentation follows the iRule.) For use with TMOS v9, see ProxyPass v8.2 Note: In 10.1+ you can use an internal data group to store the ProxyPass configuration. Ignore the comments to the contrary in the instructions as these were for pre-10.1 releases. Please post questions or fixes for this iRule in the iRules forum to get the fastest response. Thanks Aaron. Introduction Sometimes it is desirable to have a different look and feel to your website on the outside than you have in the inside. You may want www.company.com/usa/ to internally go to the server usa.company.com. You may want support.company.com to go internally to abc123.company.com/web/support. This can create a few issues - sometimes the web server expects to see a certain hostname (i.e. for name-based virtual hosting) or will use the internal hostname and/or path when sending a redirect to the clients. These problems can be overcome with the Apache webserver using the ProxyPass module which can translate the URL on the way into the server, and the ProxyPassReverse module which can un-translate header fields such as Location in the case of a redirect. Now you can accomplish this with an iRule. The ProxyPass iRule translates incoming requests in a flexible manner and untranslates the Location, Content-Location, and/or URI headers in the response back to the client. ProxyPass also rewrites the domain and path in cookies set by the server. Page Content Modification In addition, this rule will perform basic page modification as needed (this feature is disabled by default but can be enabled in the RULE_INIT event). Using the example from the introduction, if the page content contains a link to http://abc123.company.com/web/support/viewticket.html, the iRule will modify that to be http://support.company.com/viewticket.html. Here are some examples: < a href=http://www.domain.com/path/file.html> will be modified assuming the incoming request was matched by the ProxyPass iRule and the inside hostname was www.domain.com and the inside path was /path. < a href="page2.html"> will not need to be modified as this is a URL already relative to the path. Even relative URLs such as < a href="../page2.html"> will work as long as it does not try to go above the top-level directory defined by the ProxyPass rules. You must have a stream profile defined on any virtual servers the rule is applied to in order to enable the page modification feature. Virtual Server The first step to using the ProxyPass iRule is to define the rule on your BIG-IP and associate it with one or more Virtual Servers. Note that each virtual server MUST have an HTTP profile defined (doesn't matter which one). I also highly recommend applying a OneConnect profile, especially if you will be choosing pools with ProxyPass. It also must have a stream profile associated with it if you want to uncomment the page modification code. The rule will work on HTTP sites as well as HTTPS sites where the SSL is terminated on the BIG-IP (i.e. a client-side SSL profile is defined). Data Groups You can apply the ProxyPass rule to any virtual server that you want to do translations on. But just applying the rule will have no effect unless you define the translations you want done. This is done by defining specific Data Groups. The ProxyPass iRule uses Data Groups which are created and managed by going to Local Traffic / Virtual Servers / iRules on the left menu bar in the BIG-IP GUI. Then choose the "Data Group List" tab at the top of the screen. Here you can create the data groups used by this rule. For 10.0.x, the data groups must be External, type "String", and Read-only. For 10.1 and higher, the data group can be internal or external with name=value pairings. In order to use this rule on a virtual server you must apply the rule to the virtual server and create a data group named ProxyPassXYZ where "XYZ" needs to be the name of the virtual server. If both of these conditions are not met then the rule will not work for that virtual server. ProxyPassXYZ Data Groups If your virtual server is named XYZ and has the ProxyPass iRule associated with it, it will look for a data group named ProxyPassXYZ. Assuming that class is found, for each new HTTP request, the rule will find the one row that matches the hostname/path used in the request. For example, the data group may contain 4 entries (each line below is one string in the data group): "www.usa.company.com/support" := "support.company-internal.com:8080/usa", "www.usa.company.com/" := "www.company-internal.com:8080/usa", "www.japan.company.com/" := "www.company-internal.com:8080/japan", "/" := "www.company-internal.com:8080/others", A request need not match any entries - if no entries match then the iRule will have no effect. But each request will only match at most one entry and that will be the entry with the most specific left-hand-side. Entries with hostnames specified on the left-hand-side will be matched before entries without hostnames. If multiple entries match then the entry with the longest path name on the left-hand-side will be used. The example above lists entries from most-specific to least-specific, just as the rule will process them, but in your actual data group the order of the entries does not matter. In the example above, requests to http://www.usa.company.com/support will match the first entry and have the host header changed to "support.company-internal.com:8080" and the URI will be rewritten so that the string /support at the beginning of the URI will be changed to /usa. Furthermore, requests to http://www.usa.company.com/ will match the second entry as long as the URI does not begin with "/support" in which case it would match the first entry. In that case the Host header will be changed to "www.company-internal.com:8080" and whatever URI the client sends in will be prepended with "/usa". Likewise all requests to http://www.japan.company.com/ will match the third entry and have the Host header changed to "www.company-internal.com:8080" and the URIs would be prepended with "/japan". Finally, all other requests that hit this example virtual server would match the least-specific rule which is simply "/" -- all URIs begin with "/" and thus all requests will match the fourth entry if they did not match any others. Remember that a catch-all entry is not required, but in this example we want to prepend the URI of all other requests with "/others". Note that the ProxyPass iRule does not actually alter the destination of the requests by default. In the examples above all of the requests would go to the default pool regardless of the entries they match. The hostnames and ports specified in the right-hand entry is only used to modify the Host header. To alter the destination pool see the next section. Dynamic Pool Selection You may also specify an alternate pool as a second item in the right-hand value of the entry. This is optional any items in the list without a pool name will just use the default pool associated with the virtual server. For example: "/support" := "support.company.com/ SupportPool", "/downloads" := "downloads.company.com/ DownloadPool", If the pool name is not valid the user will get an error and you should see an error message in /var/log/ltm. Dynamic SNAT You can optionally define a ProxyPassSNATs data group. This will allow you to use different SNAT IP based on which pool you send traffic to. The ProxyPassSNATs data group is shared by all virtual servers but will only have an effect if the selected pool is listed in the data group. The format of this data group (internal string type) is: Pool1 W.X.Y.Z Pool2 automap Dynamic ServerSSL Profiles You can optionally define a ProxyPassSSLProfiles data group and apply a generic serverssl profile to the virtual server. This will allow you to use different serverssl profiles based on which pool you send traffic to. The ProxyPassSSLProfiles data group is shared by all virtual servers but will only have an effect if the selected pool is listed in the data group and a generic serverssl is applied to the virtual server. The format of this data group (internal string type) is: Pool1 ServerSSLProfile1 Pool2 ServerSSLProfile2 Regular Expressions New in v10: you may also use regular expressions and backreferences when building your rule set. "/" := "=www.company.com/(.*?)/=$1.company.com/=", As you see, instead of a regular server-side entry, we have "=regex=replace=". Basically, in order for the regex to be run, the left-hand side must match the client host/path (just "/" in this case, which will always match unless something more specific matches). Once this happens, the client host and URI are combined into a form similar to www.domain.com/path and the regular expression is run a against it. If the regular expression does not match, ProxyPass does not alter the request. If it does match, the clientside path becomes the match string and the serverside path becomes the replace string. Within this replace string you can use $1 through $9 as back-references to grouped items in the original regular expression. So, the example above, entry is equivalent to all of these entries: "www.company.com/sales" := "sales.company.com/", "www.company.com/support" := "support.company.com/", "www.company.com/employment" := "employment.company.com/", Debugging You can debug your ProxyPass rules by setting the static::ProxyPassDebug variable at the top of the rule to 1 (or 2 for more verbose debugging). Once you do this you can SSH to the BIG-IP and run the command "tail -f /var/log/ltm" to see what ProxyPass is doing to your requests. Code : # ProxyPass iRule, Version 10.9 # Nov 26 2012. Date # THIS VERSION REQUIRES TMOS v10 or higher. Use ProxyPass v8.2 for TMOS 9.x. # This version does not work with APM-enabled virtual servers, please # download ProxyPass 10.2APM for this use case. # Created by Kirk Bauer # https://devcentral.f5.com/s/wiki/default.aspx/iRules/ProxyPassV10.html # (please see end of iRule for additional credits) # Purpose: # iRule to replace the functionality of Apache Webserver ProxyPass and # ProxyPassReverse functions. It allows you to perform host name and path name # modifications as HTTP traffic passes through the LTM. In other words, you # can have different hostnames and directory names on the client side as you # do on the server side and ProxyPass handles the necessary translations. # NOTE: You should not need to modify this iRule in any way except the settings # in the RULE_INIT event. Just apply the iRule to the virtual server and # define the appropriate Data Group and you are done. If you do make any # changes to this iRule, please send your changes and reasons to me so that # I may understand how ProxyPass is being used and possibly incorporate your # changes into the core release. # Configuration Requirements # 1) The ProxyPass iRule needs to be applied to an HTTP virtual server or # an HTTPS virtual server with a clientssl profile applied to it. # 2) A data group (LTM -> iRules -> Data Groups tab) must be defined with # the name "ProxyPassVIRTUAL" where VIRTUAL is the name of the virtual server # (case-sensitive!). See below for the format of this data group (class). # For 10.0.x, you must use an EXTERNAL data group. # 3) You must define a default pool on the virtual server unless you specify # a pool in every entry in the data group. # 4) If you are using ProxyPass to select alternate pools, you must define # a OneConnect profile in most cases! # 5) ProxyPass does not rewrite links embedded within pages by default, just # headers. If you want to change this, edit the $static::RewriteResponsePayload variable in RULE_INIT # and apply the default stream profile to the virtual server. # Data Group Information # For 10.0.x, you must define an external data group (type=String, read-only) which loads # from a file on your BIG-IP. For 10.1 and higher you can use an internal string data group with name=value pairings. # The format of the file is as follows: # "clientside" := "serverside", # or # "clientside" := "serverside poolname", # The clientside and serverside fields must contain a URI (at least a "/") and # may also contain a hostname. Here are some examples: # "/clientdir" := "/serverdir", # "www.host.com/clientdir" := "internal.company.com/serverdir", # "www.host.com/" := "internal.company.com/serverdir/", # Notes: # 1) You can optionally define a ProxyPassSNATs data group to SNAT based # on the pool selected. # 2) You can optionally define a ProxyPassSSLProfiles data group to select # a serverssl profile based on the pool selected. # 3) You can also use regular expressions which is documented on DevCentral. when RULE_INIT { # Enable to debug ProxyPass translations via log messages in /var/log/ltm # (2 = verbose, 1 = essential, 0 = none) set static::ProxyPassDebug 0 # Enable to rewrite page content (try a setting of 1 first) # (2 = attempt to rewrite host/path and just /path, 1 = attempt to rewrite host/path) set static::RewriteResponsePayload 0 } when CLIENT_ACCEPTED { # Get the default pool name. This is used later to explicitly select # the default pool for requests which don't have a pool specified in # the class. set default_pool [LB::server pool] # The name of the Data Group (aka class) we are going to use. # Parse just the virtual server name by stripping off the folders (if present) set clname "ProxyPass[URI::basename [virtual name]]" if { $static::ProxyPassDebug > 1 } { log local0. "[virtual name]: [IP::client_addr]:[TCP::client_port] -> [IP::local_addr]:[TCP::local_port]" } } when HTTP_REQUEST { # "bypass" tracks whether or not we made any changes inbound so we # can skip changes on the outbound traffic for greater efficiency. set bypass 1 # Initialize other local variables used in this rule set orig_uri "[HTTP::uri]" set orig_host "[HTTP::host]" set log_prefix "VS=[virtual name], Host=$orig_host, URI=$orig_uri" set clientside "" set serverside "" set newpool "" set ppass "" if {! [class exists $clname]} { log local0. "$log_prefix: Data group $clname not found, exiting." pool $default_pool return } else { set ppass [class match -element "$orig_host$orig_uri" starts_with $clname] if {$ppass eq ""} { # Did not find with hostname, look for just path set ppass [class match -element "$orig_uri" starts_with $clname] } if {$ppass eq ""} { # No entries found if { $static::ProxyPassDebug > 0 } { log local0. "$log_prefix: No rule found, using default pool $default_pool and exiting" } pool $default_pool return } } # Store each entry in the data group line into a local variable set clientside [getfield $ppass " " 1] set serverside [string trimleft [getfield $ppass " " 2 ] "{" ] set newpool [string trimright [getfield $ppass " " 3 ] "}" ] # If serverside is in the form =match=replace=, apply regex if {$serverside starts_with "="} { set regex [getfield $serverside "=" 2] set rewrite [getfield $serverside "=" 3] if {[regexp -nocase $regex "$orig_host$orig_uri" 0 1 2 3 4 5 6 7 8 9]}{ # The clientside becomes the matched string and the serverside the substitution set clientside $0 set serverside [eval set X $rewrite] } else { pool $default_pool return } } if {$clientside starts_with "/"} { # No virtual hostname specified, so use the Host header instead set host_clientside $orig_host set path_clientside $clientside } else { # Virtual host specified in entry, split the host and path set host_clientside [getfield $clientside "/" 1] set path_clientside [substr $clientside [string length $host_clientside]] } # At this point $host_clientside is the client hostname, and $path_clientside # is the client-side path as specified in the data group set host_serverside [getfield $serverside "/" 1] set path_serverside [substr $serverside [string length $host_serverside]] if {$host_serverside eq ""} { set host_serverside $host_clientside } # At this point $host_serverside is the server hostname, and $path_serverside # is the server-side path as specified in the data group # In order for directory redirects to work properly we have to be careful with slashes if {$path_clientside equals "/"} { # Make sure serverside path ends with / if clientside path is "/" if {!($path_serverside ends_with "/")} { append path_serverside "/" } } else { # Otherwise, neither can end in a / (unless serverside path is just "/") if {!($path_serverside equals "/")} { if {$path_serverside ends_with "/"} { set path_serverside [string trimright $path_serverside "/"] } if {$path_clientside ends_with "/"} { set path_clientside [string trimright $path_clientside "/"] } } } if { $static::ProxyPassDebug } { log local0. "$log_prefix: Found Rule, Client Host=$host_clientside, Client Path=$path_clientside, Server Host=$host_serverside, Server Path=$path_serverside" } # If you go to http://www.domain.com/dir, and /dir is a directory, the web # server will redirect you to http://www.domain.com/dir/. The problem is, with ProxyPass, if the client-side # path is http://www.domain.com/dir, but the server-side path is http://www.domain.com/, the server will NOT # redirect the client (it isn't going to redirect you to http://www.domain.com//!). Here is the problem with # that. If there is an image referenced on the page, say logo.jpg, the client doesn't realize /dir is a directory # and as such it will try to load http://www.domain.com/logo.jpg and not http://www.domain.com/dir/logo.jpg. So # ProxyPass has to handle the redirect in this case. This only really matters if the server-side path is "/", # but since we have the code here we might as well offload all of the redirects that we can (that is whenever # the client path is exactly the client path specified in the data group but not "/"). if {$orig_uri eq $path_clientside} { if {([string index $path_clientside end] ne "/") and not ($path_clientside contains ".") } { set is_https 0 if {[PROFILE::exists clientssl] == 1} { set is_https 1 } # Assumption here is that the browser is hitting http://host/path which is a virtual path and we need to do the redirect for them if {$is_https == 1} { HTTP::redirect "https://$orig_host$orig_uri/" if { $static::ProxyPassDebug } { log local0. "$log_prefix: Redirecting to https://$orig_host$orig_uri/" } } else { HTTP::redirect "http://$orig_host$orig_uri/" if { $static::ProxyPassDebug } { log local0. "$log_prefix: Redirecting to http://$orig_host$orig_uri/" } } return } } if {$host_clientside eq $orig_host} { if {$orig_uri starts_with $path_clientside} { set bypass 0 # Take care of pool selection if {$newpool eq ""} { pool $default_pool if { $static::ProxyPassDebug > 1 } { log local0. "$log_prefix: Using default pool $default_pool" } set newpool $default_pool } else { pool $newpool if { $static::ProxyPassDebug > 0 } { log local0. "$log_prefix: Using parsed pool $newpool (make sure you have OneConnect enabled)" } } } } # If we did not match anything, skip the rest of this event if {$bypass} { return } # The following code will look up SNAT addresses from # the data group "ProxyPassSNATs" and apply them. # # The format of the entries in this list is as follows: # # # # All entries are separated by spaces, and both items # are required. set class_exists_cmd "class exists ProxyPassSNATs" if {! [eval $class_exists_cmd]} { return } set snat [findclass $newpool ProxyPassSNATs " "] if {$snat eq ""} { # No snat found, skip rest of this event return } if { $static::ProxyPassDebug > 0 } { log local0. "$log_prefix: SNAT address $snat assigned for pool $newpool" } snat $snat } when HTTP_REQUEST_SEND { # If we didn't match anything, skip the rest of this event if {$bypass} { return } # The following code does the actual rewrite on its way TO # the backend server. It replaces the URI with the newly # constructed one and masks the "Host" header with the FQDN # the backend pool server wants to see. # # If a new pool or custom SNAT are to be applied, these are # done here as well. If a SNAT is used, an X-Forwarded-For # header is attached to send the original requesting IP # through to the server. if {$host_clientside eq $orig_host} { if {$orig_uri starts_with $path_clientside} { if { $static::ProxyPassDebug > 1 } { log local0. "$log_prefix: New Host=$host_serverside, New Path=$path_serverside[substr $orig_uri [string length $path_clientside]]" } clientside { # Rewrite the URI HTTP::uri $path_serverside[substr $orig_uri [string length $path_clientside]] # Rewrite the Host header HTTP::header replace Host $host_serverside # Now alter the Referer header if necessary if { [HTTP::header exists "Referer"] } { set protocol [URI::protocol [HTTP::header Referer]] if {$protocol ne ""} { set client_path [findstr [HTTP::header "Referer"] $host_clientside [string length $host_clientside]] if {$client_path starts_with $path_clientside} { if { $static::ProxyPassDebug > 1 } { log local0. "$log_prefix: Changing Referer header: [HTTP::header Referer] to $protocol://$host_serverside$path_serverside[substr $client_path [string length $path_clientside]]" } HTTP::header replace "Referer" "$protocol://$host_serverside$path_serverside[substr $client_path [string length $path_clientside]]" } } } } } } # If we're rewriting the response content, prevent the server from using #compression in its response by removing the Accept-Encoding header #from the request. LTM does not decompress response content before #applying the stream profile. This header is only removed if we're #rewriting response content. clientside { if { $static::RewriteResponsePayload } { if { [HTTP::header exists "Accept-Encoding"] } { HTTP::header remove "Accept-Encoding" if { $static::ProxyPassDebug > 1} { log local0. "$log_prefix: Removed Accept-Encoding header" } } } HTTP::header insert "X-Forwarded-For" "[IP::remote_addr]" } } when HTTP_RESPONSE { if { $static::ProxyPassDebug > 1 } { log local0. "$log_prefix: [HTTP::status] response from [LB::server]" } if {$bypass} { # No modification is necessary if we didn't change anything inbound so disable the stream filter if it was enabled # Check if we're rewriting the response if {$static::RewriteResponsePayload} { if { $static::ProxyPassDebug > 1 } { log local0. "$log_prefix: Rewriting response content enabled, but disabled on this response." } # Need to explicity disable the stream filter if it's not needed for this response # Hide the command from the iRule parser so it won't generate a validation error #when not using a stream profile set stream_disable_cmd "STREAM::disable" # Execute the STREAM::disable command. Use catch to handle any errors. Save the result to $result if { [catch {eval $stream_disable_cmd} result] } { # There was an error trying to disable the stream profile. log local0. "$log_prefix: Error disabling stream filter ($result). If you enable static::RewriteResponsePayload, then you should add a stream profile to the VIP. Else, set static::RewriteResponsePayload to 0 in this iRule." } } # Exit from this event. return } # Check if we're rewriting the response if {$static::RewriteResponsePayload} { # Configure and enable the stream filter to rewrite the response payload # Hide the command from the iRule parser so it won't generate a validation error #when not using a stream profile if {$static::RewriteResponsePayload > 1} { set stream_expression_cmd "STREAM::expression \"@$host_serverside$path_serverside@$host_clientside$path_clientside@ @$path_serverside@$path_clientside@\"" } else { set stream_expression_cmd "STREAM::expression \"@$host_serverside$path_serverside@$host_clientside$path_clientside@\"" } set stream_enable_cmd "STREAM::enable" if { $static::ProxyPassDebug > 1 } { log local0. "$log_prefix: \$stream_expression_cmd: $stream_expression_cmd, \$stream_enable_cmd: $stream_enable_cmd" } # Execute the STREAM::expression command. Use catch to handle any errors. Save the result to $result if { [catch {eval $stream_expression_cmd} result] } { # There was an error trying to set the stream expression. log local0. "$log_prefix: Error setting stream expression ($result). If you enable static::RewriteResponsePayload, then you should add a stream profile to the VIP. Else, set static::RewriteResponsePayload to 0 in this iRule." } else { # No error setting the stream expression, so try to enable the stream filter # Execute the STREAM::enable command. Use catch to handle any errors. Save the result to $result if { [catch {eval $stream_enable_cmd} result] } { # There was an error trying to enable the stream filter. log local0. "$log_prefix: error enabling stream filter ($result)" } else { if { $static::ProxyPassDebug > 1 } { log local0. "$log_prefix: Successfully configured and enabled stream filter" } } } } # Fix Location, Content-Location, and URI headers foreach header {"Location" "Content-Location" "URI"} { set protocol [URI::protocol [HTTP::header $header]] if { $static::ProxyPassDebug > 1 } { log local0. "$log_prefix: Checking $header=[HTTP::header $header], \$protocol=$protocol" } if {$protocol ne ""} { set server_path [findstr [HTTP::header $header] $host_serverside [string length $host_serverside]] if {$server_path starts_with $path_serverside} { if { $static::ProxyPassDebug } { log local0. "$log_prefix: Changing response header $header: [HTTP::header $header] with $protocol://$host_clientside$path_clientside[substr $server_path [string length $path_serverside]]" } HTTP::header replace $header $protocol://$host_clientside$path_clientside[substr $server_path [string length $path_serverside]] } } } # Rewrite any domains/paths in Set-Cookie headers if {[HTTP::header exists "Set-Cookie"]}{ array unset cookielist foreach cookievalue [HTTP::header values "Set-Cookie"] { set cookiename [getfield $cookievalue "=" 1] set namevalue "" set newcookievalue "" foreach element [split $cookievalue ";"] { set element [string trim $element] if {$namevalue equals ""} { set namevalue $element } else { if {$element contains "="} { set elementname [getfield $element "=" 1] set elementvalue [getfield $element "=" 2] if {[string tolower $elementname] eq "domain"} { set elementvalue [string trimright $elementvalue "."] if {$host_serverside ends_with $elementvalue} { if {$static::ProxyPassDebug > 1} { log local0. "$log_prefix: Modifying cookie $cookiename domain from $elementvalue to $host_clientside" } set elementvalue $host_clientside } append elementvalue "." } if {[string tolower $elementname] eq "path"} { if {$elementvalue starts_with $path_serverside} { if {$static::ProxyPassDebug > 1} { log local0. "$log_prefix: Modifying cookie $cookiename path from $elementvalue to $path_clientside[substr $elementvalue [string length $path_serverside]]" } set elementvalue $path_clientside[substr $elementvalue [string length $path_serverside]] } } append newcookievalue "; $elementname=$elementvalue" } else { append newcookievalue "; $element" } } } set cookielist($cookiename) "$namevalue$newcookievalue" } HTTP::header remove "Set-Cookie" foreach cookiename [array names cookielist] { HTTP::header insert "Set-Cookie" $cookielist($cookiename) if {$static::ProxyPassDebug > 1} { log local0. "$log_prefix: Inserting cookie: $cookielist($cookiename)" } } } } # Only uncomment this event if you need extra debugging for content rewriting. # This event can only be uncommented if the iRule is used with a stream profile. #when STREAM_MATCHED { #if { $static::ProxyPassDebug } { #log local0. "$log_prefix: Rewriting match: [STREAM::match]" #} #} # The following code will look up SSL profile rules from # the Data Group ProxyPassSSLProfiles" and apply # them. # # The format of the entries in this list is as follows: # # # # All entries are separated by spaces, and both items # are required. The virtual server also will need to # have any serverssl profile applied to it for this to work. when SERVER_CONNECTED { if {$bypass} { return } set class_exists_cmd "class exists ProxyPassSSLProfiles" if {! [eval $class_exists_cmd]} { return } set pool [LB::server pool] set profilename [findclass $pool ProxyPassSSLProfiles " "] if {$profilename eq ""} { if { [PROFILE::exists serverssl] == 1} { # Hide this command from the iRule parser (in case no serverssl profile is applied) set disable "SSL::disable serverside" catch {eval $disable} } return } if { $static::ProxyPassDebug > 0 } { log local0. "$log_prefix: ServerSSL profile $profilename assigned for pool $pool" } if { [PROFILE::exists serverssl] == 1} { # Hide these commands from the iRule parser (in case no serverssl profile is applied) set profile "SSL::profile $profilename" catch {eval $profile} set enable "SSL::enable serverside" catch {eval $enable} } else { log local0. "$log_prefix: ServerSSL profile must be defined on virtual server to enable server-side encryption!" } } # ProxyPass Release History #v10.9: Nov 26, 2012: Used URI::basename to get the virtual server name. Thanks to Opher Shachar for the suggestion. #Replaced indentations with tabs intead of spaces to save on characters #v10.8: Oct 25, 2012: Updated the class name to remove the folder(s) (if present) from the virtual server name. # This assumes the ProxyPass data group is in the same partition as the iRule. #v10.7: Oct 24, 2012: Changed array set cookielist {} to array unset cookielist as the former does not clear the array. # Thanks to rhuyerman@schubergphilis.com and Simon Kowallik for pointing out the issue and this wiki page with details: http://wiki.tcl.tk/724 #v10.6: Oct 14, 2012: Updated how the protocol is parsed from URLs in request and response headers to fix errant matches #v10.5: Feb 2, 2012: Removed extra stream profile $result reference for debug logging. #v10.4: Nov 23, 2011: Removed an extra colon in sever HTTP::header replace commands to prevent duplicate headers from being inserted #v10.3: Sep 27, 2010: Moved rewrite code to HTTP_REQUEST_SEND to work with WebAccelerator # Fixed bug with cookie rewrites when cookie value contained an "=" #v10.2: Jun 04, 2010: Can handle individual file mappings thanks to Michael Holmes from AZDOE # Also fixed bug with directory slash logic #v10.1: Oct 24, 2009: Now CMP-friendly! (NOTE: use ProxyPass v8.2 for TMOS v9.x) #v10.0: May 15, 2009: Optimized for external classes in v10 only (use v8.2 for TMOS v9.x) # Added support for regular expressions and backreferences for the translations. # v8.2: Jun 04, 2010: Fixed bug with directory slash logic # v8.1: May 15, 2009: Added internal redirects back in (removing them was a mistake) # v8.0: May 13, 2009: pulled in changes submitted by Aaron Hooley (hooleylists gmail com) # TMOS v10 support added. Cookie domain/path rewriting added. # v7.0: May 6, 2008: added optional serverssl contributed by Joel Moses # v6.0: Jan 15, 2008: Small efficiency change # v5.0: Jul 27, 2007: Added Referer header conversions # v4.0: Jul 27, 2007: Added optional debugging flag # v3.0: Jul 20, 2007: Added SNAT support contributed by Adam Auerbach # v2.0: May 28, 2007: Added internal directory redirects and optional stream profile # v1.0: Feb 20, 2007: Initial Release Tested this on version: 10.0
Proxy Protocol Initiator
Problem this snippet solves: iRule Support for BIG-IP sending Proxy header to serverside pool member. (BIG-IP as Proxy Protocol Initiator) Implements v1 of PROXY protocol at: http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt How to use this snippet: Add iRule to Virtual Server. Back-end server should accept Proxy header. Code : when CLIENT_ACCEPTED { set proxyheader "PROXY " if {[IP::version] eq 4} { append proxyheader "TCP4 " } else { append proxyheader "TCP6 " } append proxyheader "[IP::remote_addr] [IP::local_addr] [TCP::remote_port] [TCP::local_port]\r\n" } when SERVER_CONNECTED { TCP::respond $proxyheader } ### Alternate Optimized Version ### when CLIENT_ACCEPTED { set proxyheader "PROXY TCP[IP::version] [IP::remote_addr] [IP::local_addr] [TCP::remote_port] [TCP::local_port]\r\n" } when SERVER_CONNECTED { TCP::respond $proxyheader } Tested this on version: 11.6
Log Http Headers
Problem this snippet solves: This simple rule logs all HTTP headers in requests and responses to /var/log/ltm. This can be helpful in troubleshooting. Code : when HTTP_REQUEST { set LogString "Client [IP::client_addr]:[TCP::client_port] -> [HTTP::host][HTTP::uri]" log local0. "=============================================" log local0. "$LogString (request)" foreach aHeader [HTTP::header names] { log local0. "$aHeader: [HTTP::header value $aHeader]" } log local0. "=============================================" } when HTTP_RESPONSE { log local0. "=============================================" log local0. "$LogString (response) - status: [HTTP::status]" foreach aHeader [HTTP::header names] { log local0. "$aHeader: [HTTP::header value $aHeader]" } log local0. "=============================================" } # Sample output: Rule log_http_headers_rule : ============================================= Rule log_http_headers_rule : Client 192.168.99.32:2950 -> webmail.example.com/exchange/Aaron/Inbox/?Cmd=contents (request) Rule log_http_headers_rule : Host: webmail Rule log_http_headers_rule : User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Rule log_http_headers_rule : Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,im Rule log_http_headers_rule : Accept-Language: en-us,en;q=0.5 Rule log_http_headers_rule : Accept-Encoding: gzip,deflate Rule log_http_headers_rule : Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Rule log_http_headers_rule : Keep-Alive: 300 Rule log_http_headers_rule : Connection: keep-alive Rule log_http_headers_rule : Referer: https://webmail.example.com/exchange/ Rule log_http_headers_rule : X-Forwarded-For: 192.168.99.32 Rule log_http_headers_rule : Front-End-Https: On Rule log_http_headers_rule : ============================================= Rule log_http_headers_rule : ============================================= Rule log_http_headers_rule : Client 192.168.99.32:2950 -> webmail.example.com/exchange/Aaron/Inbox/?Cmd=contents (response) - status: 200 Rule log_http_headers_rule : Date: Tue, 06 Nov 2007 16 Rule log_http_headers_rule : Server: Microsoft-IIS/6.0 Rule log_http_headers_rule : X-Powered-By: ASP.NET Rule log_http_headers_rule : Content-Type: text/html Rule log_http_headers_rule : Content-Length: 55446 Rule log_http_headers_rule : MS-WebStorage: 6.5.7638 Rule log_http_headers_rule : Cache-Control: no-cache Rule log_http_headers_rule : =============================================
Complete F5 Automated Backup Solution
Problem this snippet solves: Hi all, Often I've been scouring the devcentral fora and codeshares to find that one piece of handywork that will drastically simplify my automated backup needs on F5 devices. Based on the works of Jason Rahm in his post "Third Time's the Charm: BIG-IP Backups Simplified with iCall" on the 26th of June 2013, I went ahead and created my own iApp that pretty much provides the answers for all my backup-needs. Here's a feature list of this iApp: It allows you to choose between both UCS or SCF as backup-types. (whilst providing ample warnings about SCF not being a very good restore-option due to the incompleteness in some cases) It allows you to provide a passphrase for the UCS archives (the standard GUI also does this, so the iApp should too) It allows you to not include the private keys (same thing: standard GUI does it, so the iApp does it too) It allows you to set a Backup Schedule for every X minutes/hours/days/weeks/months or a custom selection of days in the week It allows you to set the exact time, minute of the hour, day of the week or day of the month when the backup should be performed (depending on the usefulness with regards to the schedule type) It allows you to transfer the backup files to external devices using 4 different protocols, next to providing local storage on the device itself * SCP (username/private key without password) SFTP (username/private key without password) FTP (username/password) SMB (using smbclient, with username/password) Local Storage (/var/local/ucs or /var/local/scf) It stores all passwords and private keys in a secure fashion: encrypted by the master key of the unit (f5mku), rendering it safe to store the backups, including the credentials off-box It has a configurable automatic pruning function for the Local Storage option, so the disk doesn't fill up (i.e. keep last X backup files) It allows you to configure the filename using the date/time wildcards from the tcl clock command, as well as providing a variable to include the hostname It requires only the WebGUI to establish the configuration you desire It allows you to disable the processes for automated backup, without you having to remove the Application Service or losing any previously entered settings For the external shellscripts it automatically generates, the credentials are stored in encrypted form (using the master key) It allows you to no longer be required to make modifications on the linux command line to get your automated backups running after an RMA or restore operation It cleans up after itself, which means there are no extraneous shellscripts or status files lingering around after the scripts execute Enjoy! Thomas Schockaert Contributed by: Thomas Schockaert How to use this snippet: minimum version 11.4 Code : 67735 Tested this on version: 11.4Microsoft Skype for Business Server 2015
Problem this snippet solves: New release candidate iApp template and deployment guide for Microsoft Skype for Business Server 2015 (formerly Lync Server 2010/2013). For more information and complete guidance on configuring the iApp template, see the associated deployment guide: http://www.f5.com/pdf/deployment-guides/microsoft-skype-for-business-dg.pdf f5.microsoft_skype_server_2015.v1.0.0rc9: posted to downloads.f5.com in 11/2017 RC-9 was posted to downloads.f5.com (as will most new versions of this template). It contained the following changes: new BIG-IP AFM IP Intelligence threat categories to support BIG-IP v13.1 and support for route domain 0 from non-Common partitions. f5.microsoft_skype_server_2015.v1.0.0rc7: posted 09/21/2016 RC-7 provides additional SIP domain support within reverse proxy, a monitor schema change for reverse proxy to make use of the 200 OK response when querying lyncdiscover/lyncdiscoverinternal, support for the director service standalone use case(separate LTM from Front End service), added support to ask for the IP phone update url to allow connections through reverse proxy and added a port 80 Virtual Server in addition to the existing 443 Virtual Server for reverse proxy. RC 5 and 6 were never released to the public, this includes changes as a part of those RC's f5.microsoft_skype_server_2015.v1.0.0rc4: posted 02/16/2016 RC-4 Fixes a security log profile error when deploying on versions of BIG-IP earlier than 11.4, where AFM is not available. f5.microsoft_skype_server_2015.v1.0.0rc3: posted 01/22/2016 RC-3 attaches a supplemental ICMP monitor to the Edge internal UDP virtual server. See https://support.f5.com/kb/en-us/solutions/public/6000/100/sol6143.html for more information. f5.microsoft_skype_server_2015.v1.0.0rc2: posted 01/11/2016 RC-2 contains only a small correction to the iRule produced by the iApp template. The iApp will now always force the FQDN written to lowercase in the iRule, even if the user enters CAPITAL letters. f5.microsoft_skype_server_2015.v1.0.0rc1: posted 07/06/2015 New iApp template for Skype for Business. Code : 70782
