Local traffic policies and irules together
Problem this snippet solves: Local traffic policies are very useful to define URL-based redirection, virtual servers and pool assignments, host header rewriting... But some actions can't be done with Local traffic policies and there are some deployments with both Policies and irules applied on the same VS. for HTTP_REQUEST event, Policies are executed before irules. If Policy action is http-reply redirect, the irule is executed but all HTTP changes raise TCL error (insert header, modify cookies, URI rewriting) This code allow to detect this policy action and disable event and exit irule. How to use this snippet: import this irule on the appliance and enable it on the VS (to disable irule event) or insert following line on top of each irule assigned to the VS (to exit the current irule): if {[POLICY::targets http-reply] } {return} As http-reply respond with HTTP/1.0 version, the TCP connection will be closed after the reply and no other request will be sent to the F5, the event can be disabled. Code : when HTTP_REQUEST priority 1 { if {[POLICY::targets http-reply] } { log local0. "LTM Policy action contains redirect. Disabling event" event disable return } } Tested this on version: 11.6
LTM policies only works with http profile?
Hi all, Today I found a limit when needed the following config: A tcp-only service on one VS which does listen to any. About 60 tcp-only listener ports which should be load balanced to two backends. We need to monitor each of the tcp-ports of the backends, therefore we need about 60 pools for this. I created the following objects: 1 VS ANY TCP listener 60 pools, one for each tcp listener with two backend members. 1 LTM policy with 60 rules like the following: rule_AQ { actions { 0 { forward select pool /Common/pool_AQ_8137 } } conditions { 0 { tcp port values { 8137 } } } } When I try to add the LTM policy to the VS I get the error: 010716d9:3: Virtual server /Common/AQ-domain.com_any requires a profile of type http for ltm policy /Common/pol_AQ_8137. Since this config would be used as a tcp-only service, I cannot add a http profile to the VS. So are LTM policies only usable for HTTP traffic? Thanks, Peter
Redirect base on source IP Address for Virtual Server - Local Traffic Policy
Is it possible to have a local traffic policy to redirect traffic based on source ip address. Here's what I've setup but I don't get any hits on the policy Policy Name: Redirect-Traffic Strategy: Execute first matching rule Rule1 Rule Name: Match-Server1 Match all of the following conditions: TCP address matches any of 10.1.1.1 at request time (apply to traffic on remote side of external interface Forward traffic to node 10.2.2.1 Rule2 Rule Name: Match-Server1 Match all of the following conditions: TCP address matches any of 10.1.1.2 at request time (apply to traffic on remote side of external interface Forward traffic to node 10.2.2.2 ` I've generated traffic from both sources but the traffic policy never applies to Rule1 Here's an output of show ltm policy in tmsh `----------------------------------------------------- | Rule Action Invoked Succeeded ----------------------------------------------------- | Match-Server1 0 [forward select] 0 0 | Match-Server2 0 [forward select] 118 118 Is the remote side of external interface - the source client IP address (cs-client-addr)?
Configuring LTM policies with request and response conditions
BIG IP VERSION 13.1.0.6 Afternoon. The following LTM policy exists to insert security headers into responses when missing. The LTM policy is attached to a VS which performs virtual hosting using another LTM policy to switch the back-end pools depending on incoming header. A new requirement to remove the X-Content-Type-Options nosniff header for specific sites hosted on this virtual server exists and the LTM policy was adjusted as below to include a request condition against the host isnot header, this however has resulted in unexpected behaviour where-by the header is no longer inserted regardless of whatever site is being requested. Any ideas? Code ltm policy pol-tp-http-header-apply-security-controls-inc-exclusions { description "Edit headers on response to enable security controls" last-modified 2019-01-10:14:09:44 requires { http } rules { rl-tp-header-insert-x-content-type-options { actions { 0 { http-header response insert name X-Content-Type-Options value nosniff } } conditions { 0 { http-host host not values { site1.example.com site2.example.com } } 1 { http-header response name X-Content-Type-Options not values { nosniff } } } description "Insert the x-content-type-options header set to no sniff" ordinal 2 }
LTM Policy with HTTP_REQUEST and HTTP_PROXY_REQUEST
Hello, I try to create ltm Policy Rule to forward traffic to different virtual IP with check http host. BIG IP version: 13.1.08 I created a first Policy with two rules: Policy name: TEST2 First Rule to match HTTP PROXY REQUEST And When attempting to create a second rule to match HTTP REQUEST , the system displays an error message that appears similar to the following example: An error occurred: transaction failed:010716e2:3: Policy '//Drafts/', rule ''; an action precedes its conditions. The same configuration with an irule works. Thank you for your return. GuillaumeURL Rewrite using local traffic policy
I am looking to use a local traffic policy instead of a iRule (if possible). We want to rewrite the URI portion of incoming requests as they are presented to the inside web host. Outside: https://www.domain.com/something/prod/something/something Inside: https://www.domain.com/something/something I see the action when creating a policy to REPLACE a portion of the URI. I set it to match "/prod" and replace "" blank field. I also tried to match "/something/prod" and replace with "/something". Neither option seems to work. Is this the correct way to handle this? What is the best way to see how it is getting rewritten if you do not have direct access to web server? Thanks!Simplifying Local Traffic Policies In BIG-IP 12.1
Following up on yesterday’s Introduction to Local Traffic Policies (really a rehash of Steve McCarthy’s article from 11.4), we’ll look at improvements made to local traffic policies interfaces and logic in BIG-IP 12.1. Local traffic policies are sets of rules defined and published to various virtual servers across your BIG-IP. Major interface and workflow improvements in 12.1 ease administration of existing and new local traffic policies. 12.1’s goal is to make your local traffic processing easy to implement and reduce the need for those pesky 5 line iRules that can quietly breed like vermin across your BIG-IP ecosystem. I’m lookin’ at you citizenelah! Workflow The pseudo-process for building local traffic policies hasn’t changed since inception in 11.4. Policies are defined in the centralized policy manager interface located within the Local Traffic menu of BIG-IP. Creating policies consist of: A policy name and strategy A rule matching condition A processing action for the condition Publishing the completed policy (new in 12.1) A a virtual server for policy assignment BIG-IP version 12.1 adds the concept of publishing rules prior to applying them. This removes the possibility for a developer/orchestration admin to enumerate and apply incomplete policies still under development. Prior versions allowed in-progress policies to be available for selection within a virtual server and if a user accidentally enabled it, your traffic would be bound for darkness. Adding this publication steps gives the admin or developer a little breathing room during policy creation. Upgrades from previous versions will place the pre-existing policies into the published category. Building a Policy The Local Traffic Policy management interface is located under the Local Traffic menu within BIG-IP 11.4 through current releases. Building a policy is quite simple now but let’s check out the not-so subtle differences. I think you’ll agree this is a much easier way to implement conditional rules over the older HTTP Class, iRules, or older traffic policy builders. That’s right, if you haven’t used them before, local traffic policies have been sitting there all along since 11.4. However I personally cannot blame you if you ignored them. They were a bit intimidating as the comparison below shows. BIG-IP 11.6 BIG-IP 12.1 In version 12.1, you can change the operands within the strategy, still using: first-match: starts the actions for the first rule in the rules list that matches the connection conditions best-match: selects and stars the actions of the rule in the rules list with the best match. For expanded focus on best match, see the 12.1 LTM LTM Guide all-match: stars the actions for all rules int eh rules match list. When multiple rules match, the best match method is then applied. Lowest ordinal, highest priority, or first rule matches all fall into “all-match. Local Traffic Policy Rule Improvements Customer feedback gave us a lot to work with to fix the rule interface and it shows here. Previous versions blasted the user with a large and complicated screen that required a lot of examination and experimentation. Version 12.1 brought the rule creation back to a purist IF/THEN logical workflow as show below. BIG-IP 11.6 BIG-IP 12.1 Seriously… that’s a HUGE difference. Additional rules and actions can be added to a policy by clicking a plus sign on the right side (cut out of screenshot). Suddenly adding a URI redirect or weak cipher use logging statement becomes a lot easier to implement. Once complete, publishing the local traffic policy completes the processing making it available to all virtual servers. Recycling one of Steve McCarthy’s recipes for selective compression is quite easy to implement shown below. BIG-IP 12.1 Compression Rule Configuration (via bigip.conf) ltm policy /Common/Drafts/selective_compression { controls { compression } requires { http } rules { rule-1 { actions { 0 { compress response enable } } conditions { 0 { http-header name Content-type starts-with values { text/ } } 1 { cpu-usage last-1min less-or-equal values { 5 } } } } } strategy /Common/first-match } You’re starting to get the idea of how easy it is to buildlocal traffic policies in 12.1’s new centralized Local Traffic Policy interface. Maybe you already have a few iRules slated for retirement in lieu of the improved ease local policies provide. The performance gains are definitely worth taking a closer look. For detailed information on local traffic policies and methods behindcreating and management please review the support documentation BIG-IP Local Traffic Management: Getting Started with Policies. We encourage sharing what iRules you can decommission with local traffic policies, drop us a line or even post your config in codeshare.
