LTM Policy with Rewrite profile forward to specific Node

[Kalido]

The issue I am currently facing is in the common partition I have a profile rewrite and an LTM policy in place working perfectly and has no issues.

I have tried to replicate this in a different partition with the exact same steps and it is not working.

We have a virtual server:

VS_Azure1.aeltc.com_10.205.1.xxx       abc.aeltc.com                        10.205.1.xxx    443 (HTTPS)      Standard           Edit...   DMZ

And we have a pool:

pool_abc.aeltc.com                             3           DMZ

In this pool we have 3 different nodes ( running 3 different services )

The profile rewrite looks like this:

Client uri: https://abc.aeltc.com/aegis/tt/api/ > server uri: https://ae-iapp01-tt.office.aeltc.org/AEGIS10/api/

Client uri: https://abc.aeltc.com/catering/tt/api/ > server uri: https://uniwareintegration-tt.office.aeltc.org/api/

The above are 2 examples, so the LTM policy I have tried to configure is:

If when browsing to abc.aeltc.com they add /aegis/tt/api/ then send the traffic to node one always.

If when browsing to abc.aeltc.com they add /catering/tt/api/ then send the traffic to node two always.

I have attempted to do this via LTM however the policy isn't working it still load balances via the pool?

Any help would be deeply apricated.

[Daniel_Wolf]

Hi Kalido,

so I understand, that when a certain Host is matched and the URI starts with a specific string you want to send traffic to the node directly instead of load balancing it to the pool.

Can you share a snippet of your Local Traffic Policy with us? Maybe compare the working policy from the common partition with the other one? On the CLI just run tmsh list ltm policy <myPolicy>.

Additionally you could add a log action, to check whether your conditions are matched and the policy is set properly?

See this devcentral article: HTTP Brute Force Mitigation Playbook: Bad Actor Behavior and Gathering Statistics using BIG-IP LTM P...

It has a couple of examples of how to add logging to LTM Traffic Policies.

KR

Daniel

[Kalido]

Hi Daniel,

Firstly thank you very much for responding to this question!

And that is correct, the VS has a dns record in place for example lets say abc.aeltc.com so if they type that it it hits the VS.

However I would like the policy to push the traffic to a specific node depending on the second part of the string.

So abc.aeltc.com/football -> 10.10.10.1

abc.aeltc.com/tennis -> 10.10.10.2

abc.aeltc.com/hockey -> 10.10.10.3

The beginning host header will always be the same its just the /*** that will change and depending on that /*** the F5 will push it to a specific node.

below is the snippet, I just want to also state that these are running on two different partitions. One is common and the other is a created partition DMZ

Working Policy:

(cfg-sync Changes Pending)(Active)(/Common)(tmos)# list ltm policy Wifi-Proxy

ltm policy Wifi-Proxy {

  controls { forwarding }

  last-modified 2020-11-17:14:28:30

  requires { http }

  rules {

    wifi-Redirect-test {

      actions {

        0 {

          forward

          select

          node 167.98.43.131

          snat automap

        }

      }

      conditions {

        0 {

          http-uri

          values { /cloud-authorizeMAC.php }

        }

      }

    }

    wifi-Redirect-testPT {

      actions {

        0 {

          forward

          select

          node 10.11.1.103

          snat disable

        }

      }

      conditions {

        0 {

          http-uri

          values { /api/v1/venues/aeltc/locations/last_known.json }

        }

      }

      ordinal 1

    }

  }

  status published

  strategy best-match

}

Not working config policy:

(cfg-sync Changes Pending)(Active)(/DMZ)(tmos)# list ltm policy Azure-URI-Pool-Selection-V2

ltm policy Azure-URI-Pool-Selection-V2 {

  controls { forwarding }

  draft-copy Drafts/Azure-URI-Pool-Selection-V2

  last-modified 2021-01-27:12:31:25

  partition DMZ

  requires { http }

  rules {

    aegis {

      actions {

        0 {

          forward

          select

          node 10.110.64.123

        }

      }

      conditions {

        0 {

          http-uri

          values { /aegis/tt/api/ }

        }

      }

    }

    catering {

      actions {

        0 {

          forward

          select

          node 10.110.64.123

        }

      }

      conditions {

        0 {

          http-uri

          values { /catering/tt/api/ }

        }

      }

      ordinal 1

    }

    stringers {

      actions {

        0 {

          forward

          select

          node 10.110.64.130

        }

      }

      conditions {

        0 {

          http-uri

          values { /stringers/tt/api/ }

        }

      }

      ordinal 2

    }

  }

  status published

  strategy /Common/best-match

}

I also want to point out that I am using profile rewrites to modify the backend servers uri.

Once again I really appreciate the help!

[Daniel_Wolf]

I see some differences in the SNAT actions. Again I'd recommend to add some logging to the actions and also to do a tcpdump to see if SNAT might be the cause already.

[Kalido]

I see that Snat Actions but I do not know how they got there, for example: 

 

Where did these even come from, I will attempt to do the logging but I have tried to read on how to do a TCP dump and cant find any straight forward guides?

[Daniel_Wolf]

So piece by piece. You would have to edit the policy in order to see the SNAT options. See here:

The log could be:

tcl: client [IP::client_addr]:[TCP::client_port] -> URL: [HTTP::host][HTTP::uri]

And the tcpdump command could look like this:

tcpdump -i 0.0:nnnp -w /shared/tmp/troubleshooting.cap host <your_node_IP_here> AND port <your_node_Port_here>

[Kalido]

Hi Daniel,

Thank you for the above, I am starting to suspect that the issue isn't the policy.

I believe it could be the profile rewrites not working which is why it is not matching the policy.

Is there a method to test the rewrite profiles to see if they are working as expected?

could using the profile rewrite in a different partition cause issues as it is using the common parent profile?

I have checked the configs of both profile rewrites the one that works and the one that doesn't and I couldn't see any issues to why the rewrite wont work in the new partition.

[Daniel_Wolf]

Hi Kalido,

did you try to add some logging logic to the Traffic Policy or did you perform a tcpdump?

Are your Traffic Policy conditions matched or not?

Once you have that clear, you can continue to investigate in other directions.

How is the Rewrite Profile configured and what is it supposed to do?

[Kalido]

Hi Daniel,

I created a TCP dump but I will be honest it is not making sense or I am not reading it correctly and struggling to see where the issue is.

so the profile rewrite are set as follows:

The VS has an IP of 1.2.3.4 and we have given it a DNS name of abc.aeltc.com

We have 3 nodes in a pool all running different services.

So the point of the rewrite for us was we can always use the same hostname and depending on the uri after the host it will forward the traffic to the correct node.

So for example:

if when browsing to abc.aeltc.com they add /aegis/tt/api/ then send the traffic to node one always.

If when browsing to abc.aeltc.com they add /catering/tt/api/ then send the traffic to node two always.

I haven't done the logging I will do that now.

[Kalido]

The reason I feel like it could be the rewrite is because if it is not rewriting properly it won't understand the policy.

[Daniel_Wolf]

Ok, so if I understand you correct, you are replacing part of the URI.

As an example, the users browses https://abc.aeltc.com/aegis/tt/api/, then the request should be sent to node1 and "/aegis/tt/api" should be replaced with "/AEGIS10/api".

I think you could do that within that same Traffic Policy or with an iRule.

This is a very basic example

The tcl code in my example is:

tcl:/test[HTTP::uri] 

[Daniel_Wolf]

Found a better example:

tcl:[string map {"/aegis/tt/api/" "/AEGIS10/api/"} [HTTP::uri]]