Forum Discussion
NimbostratusAPM /my.policy redirect rewrite
Hi,
We have a situation whereby our F5 is fronted by an external 3rd-party WAF solution. All our external hosted sites are behind a single hostname, and the URI determines what IP the WAF solution routes traffic to.
So for example:
www.mysites.com/applications/app1 -> a rule in the WAF provider routes this to 1.1.1.1 which is a Virtual Server on our F5.
www.mysites.com/application/app2 -> another rule would route this request to another IP (1.1.1.2) etc..
The problem we are facing is that we use APM on a particular Virtual Server. When traffic hits, the F5 redirects the browser to www.mysites.com/my.policy . However, this then means that the WAF solution no longer routes the traffic to the correct F5 VS as it does not have the "/applications/app1" URI pre-pended.
What we need is for the F5 to redirect the user to www.mysites.com/applications/app1/my.policy
I've tried a solution using an iRule which I thought would work, but the my.policy redirect doesn't seem to trigger the HTTP_RESPONSE event, even with the restrict_irule_events flag disabled. See below:
when CLIENT_ACCEPTED {
ACCESS::restrict_irule_events disable
}
when HTTP_RESPONSE {
log local0. "HTTP Response Location: [HTTP::header value "Location"]"
if {[HTTP::header value "Location"] starts_with "/my.policy"} {
HTTP::header replace Location "/applications/app1/my.policy"
}
}
Am I approaching this wrong? When the browser receives the redirect, I'm not even seeing anything in the log file so pretty sure the event isn't firing.
Not sure if what we want is even achievable?
2 Replies
- MichaelatF5
Employee
You need to look at using Clientless-Mode. Clientless-mode removes the 302 redirect pattern from the access policy creation and evaluation process.
when HTTP_REQUEST { HTTP::header insert "clientless-mode" 1 }
- Kevin_Stewart
Well, sort of.
While clientless-mode will avert the /my.policy redirects, it doesn't deal with the APM session cookie that is bound to the (single) host name. So when you authentication to one app, you'll get an MRHSession cookie for www.mysites.com. When you go to the second app it won't prompt you for authentication at all because you'll be sending a valid APM session cookie in the very first request.
If you're only using APM for one of the VIPs, then you could just make sure you switch based on URI pattern and /my.policy.
when HTTP_REQUEST { switch -glob [string tolower [HTTP::uri]] { "/applications/app1*" { pool app1_pool } "/my.policy* { pool app1_pool } "/applications/app2*" { pool app2_pool } default { pool app1_pool } } }If you have more than one APM VIP using this same host name, then you could do VIP targeting (an LTM VIP in front of your APM VIPs) and write an iRule that rewrites the /my.policy redirect URI from each VIP (ex. /app1/my.policy and /app2/my.policy) and then write it back in the following request, and rewrite the outgoing MRHSession cookies so that they have a path attribute that is specific to each application.
Set-Cookie: MRHSession=1298329493824239; path=/app1; secure...But probably the very best solution is to not put two APM VIPs on the same host name. If you're worried about limited IPs you can point multiple host names at a single IP and the APMs won't step on each other.
