I am setting up a reverse proxy. I am converting the code from an open source WAF (which currently works). Using the F5 configuration utility I have built my rewrite profile (with several URL translations pointing to servers defined in my pool), a pool (single pool with my 3 servers using a non standard port). Also 2 Virtual Servers (an HTTP port 80 VS which does a ssl redirect to the HTTPS VS using the same non standard port as the pool). In addition I have setup HSL to a graylog server. My problem is that its not working, I have my HSL setup to log requests but nothing is being logged. I have followed the https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm-implementations-11-4-0/21.html. Do I need to create the HTML removal profile (I dont want to remove any tags) and do I need to create a local traffic policy (I only have 1 pool so I would not think so) Are there any further examples I can follow?

Ok well it seems you don't quite understand the guide. Let me summarise for you. Rewrite profile = URI Translation HTML profile = Tag Removal (optional) Local Traffic Policy (LTP) = pool selection The URI translation modifies the data however it does not choose a destination for you. The load balancing method on your pool does that. But in this case we want to override that with LTP. You can instruct LTP to select an individual pool member but multiple pools is a better approach. Separate your servers into pools, use LTP to select the pool you need based on the URI. So why does it work this way? The rewrite engine is designed to reformat data and that's it. LTP on the other hand is designed to to a whole lot of things including choosing a destination based on that data. Pools are better because if you decide to add another server to support capacity then you just add one more to the relevant pool. Also persistence methods such as cookie persistence are often linked to the pool. In the case you want persistence to work across pools as you might here, their is a tick box for it.

I split out the pool into 3 seperate pools. I created single policy with 3 different rules (one for each pool). I modified my HTTP VS to use no default pool and to use my policy (is that correct)? In addition I assigned a client SSL profile to the HTTP VS (required to assign my policy). Do I need an HTTPS VS since the nodes are using ssl? in the LTP rules should the HTTP-host be what the host the client will see or the address of the pool member (I think it would be what the client will see not the node).

No default pool is fine just use the LTP policy to add an extra rule at the bottom to catch anything that does not match and log it. You will need a clientssl and serverssl profile if your nodes are SSL The HTTP host is what the client is requesting. They don't see the backend at all. From the client's perspective the F5 is the server. From the server perspective the F5 is the client. They don't know about each other at all. Because I don't have enough data I need to make a few assumptions. Are you routing using URI or host ? If host then separate your servers into pools based on hostname so if two server look after the same hostname they should be in the same pool. If URI then separate your servers into pools of servers who look after the same URI match. Then for host matching your LTP would look like... Rule 1. HTTP host equals app1.mydomain.com forward to pool app1-pool Rule 2. HTTP host equals app2.mydomain.com forward to pool app2-pool Rule 3. HTTP host equals app3.mydomain.com forward to pool app3-pool or for URI matching it would look like... Rule 1. HTTP path starts_with /site1 forward to pool app1-pool Rule 2. HTTP path starts_with /site2 forward to pool app2-pool Rule 3. HTTP path starts_with /site3 forward to pool app3-pool You should have a catch all rule at the end to pickup anything that's not matching Rule 4. Match any traffic, Log tcl:UNMATCHED URI [HTTP::uri] Then when you are testing you can goto System, Logs, Local Traffic and search for UNMATCHED to see if any traffic is not matching your rules.

I am using URI matching. so in my rewrite policy I have. Rule 1. HTTP host equals Rule 2. HTTP path starts_with /site1 forward to pool app1-pool Rule 3. HTTP path starts_with /site2 forward to pool app2-pool Rule 4. HTTP path starts_with /site3 forward to pool app3-pool What should my rewrite profile look like? Currently I have URI Translation settings Client: /APP1/ Server: /app1 Client: /APP2/ Server: /app2 Client: /APP3/ Server: /app3 also tried Client: http://host.domain.com/APP1/ Server: /app1 Client: http://host.domain.com/APP2/ Server: /app2 Client: http://host.domain.com/APP3/ Server: /app3 Finally your mention of logging unmatched traffic. where does that log? If I want to point it at an HSL server what would the rule look like?

Sorry I cant make sense of this. First the rewrite policy looks more like a local traffic policy. What is rule 1. for? why does it have no action? Did you mean if HTTP::host notequal too host.domain.com action Ignore. What is your matching strategy for the policy? In the rewrite profile, their is no need to specify the IP and port. The pool selection in your local traffic policy takes care of that. The pool members should be added on the correct IP and ports the application is listening on.

reverse proxy | DevCentral

13 Replies

Kevin_Davies_40
Nacreous
Apr 14, 2017
Ok well it seems you don't quite understand the guide. Let me summarise for you.

Rewrite profile = URI Translation

HTML profile = Tag Removal (optional)

Local Traffic Policy (LTP) = pool selection

The URI translation modifies the data however it does not choose a destination for you. The load balancing method on your pool does that. But in this case we want to override that with LTP. You can instruct LTP to select an individual pool member but multiple pools is a better approach. Separate your servers into pools, use LTP to select the pool you need based on the URI.

So why does it work this way? The rewrite engine is designed to reformat data and that's it. LTP on the other hand is designed to to a whole lot of things including choosing a destination based on that data. Pools are better because if you decide to add another server to support capacity then you just add one more to the relevant pool. Also persistence methods such as cookie persistence are often linked to the pool. In the case you want persistence to work across pools as you might here, their is a tick box for it.
- pedinopa_170325
  Nimbostratus
  Apr 14, 2017
  I split out the pool into 3 seperate pools. I created single policy with 3 different rules (one for each pool). I modified my HTTP VS to use no default pool and to use my policy (is that correct)? In addition I assigned a client SSL profile to the HTTP VS (required to assign my policy). Do I need an HTTPS VS since the nodes are using ssl?
  
  in the LTP rules should the HTTP-host be what the host the client will see or the address of the pool member (I think it would be what the client will see not the node).
- Kevin_Davies_40
  Nacreous
  Apr 15, 2017
  No default pool is fine just use the LTP policy to add an extra rule at the bottom to catch anything that does not match and log it.
  
  You will need a clientssl and serverssl profile if your nodes are SSL
  
  The HTTP host is what the client is requesting. They don't see the backend at all. From the client's perspective the F5 is the server. From the server perspective the F5 is the client. They don't know about each other at all.
  
  Because I don't have enough data I need to make a few assumptions. Are you routing using URI or host ? If host then separate your servers into pools based on hostname so if two server look after the same hostname they should be in the same pool. If URI then separate your servers into pools of servers who look after the same URI match.
  
  Then for host matching your LTP would look like...
  
  Rule 1. HTTP host equals app1.mydomain.com forward to pool app1-pool Rule 2. HTTP host equals app2.mydomain.com forward to pool app2-pool Rule 3. HTTP host equals app3.mydomain.com forward to pool app3-pool
  
  or for URI matching it would look like...
  
  Rule 1. HTTP path starts_with /site1 forward to pool app1-pool Rule 2. HTTP path starts_with /site2 forward to pool app2-pool Rule 3. HTTP path starts_with /site3 forward to pool app3-pool
  
  You should have a catch all rule at the end to pickup anything that's not matching
  
  Rule 4. Match any traffic, Log tcl:UNMATCHED URI [HTTP::uri]
  
  Then when you are testing you can goto System, Logs, Local Traffic and search for UNMATCHED to see if any traffic is not matching your rules.
- pedinopa_170325
  Nimbostratus
  Apr 17, 2017
  I am using URI matching. so in my rewrite policy I have.
  
  Rule 1. HTTP host equals Rule 2. HTTP path starts_with /site1 forward to pool app1-pool Rule 3. HTTP path starts_with /site2 forward to pool app2-pool Rule 4. HTTP path starts_with /site3 forward to pool app3-pool
  
  What should my rewrite profile look like? Currently I have
  
  URI Translation settings Client: /APP1/ Server: /app1 Client: /APP2/ Server: /app2 Client: /APP3/ Server: /app3
  
  also tried Client: http://host.domain.com/APP1/ Server: /app1 Client: http://host.domain.com/APP2/ Server: /app2 Client: http://host.domain.com/APP3/ Server: /app3
  
  Finally your mention of logging unmatched traffic. where does that log? If I want to point it at an HSL server what would the rule look like?

Forum Discussion

reverse proxy

13 Replies

Recent Discussions

import live updates from version x to version y

Tenant image upgrade

iRule editor partition button does not work

F5Access | MacOS Sonoma

Overwriting or adding LTM SSL Traffic cert and key using iControlREST

Related Content

F5 Reverse Proxy setup

Troubleshooting Lync/Skype for Business Reverse Proxy

Setup a Reverse Proxy that redirects to internal port

F5 SSL Offload behind Nginx Reverse Proxy

Reverse Proxy With Basic SSO