Forum Discussion
NimbostratusGetting correct IP::client_addr when redirecting to another virtual server
Hi!
I'm writting an irule which redirects to another virtual server if all its members are down (a bypass). e.g. Requests hit vs-virtualA. If all it's pool members are down, the iRule redirects to vs-virtualB.
The problem I have is that the irule I have on vs-virtualB uses IP::client_addr. But when vs-virtualA redirects in the irule to vs-virtualB, the IP::client_addr takes on the F5's IP, rather than forwarding the "true" IP::client_addr that vs-virtualA would have seen.
Is there anyway (other than a global) to "forward" the IP::client_addr that the initial vs-virtualA would have reported?
Thank you in advance!
------
I've stripped out the pool member detection to be a very straight forward example. vs-virtualA iRule simply redirects to vs-virtualB and prints the IP. If I hit vs-virtualA, the IP reported is the F5's. If I hit vs-virtualB directly, the IP::client_addr is my host.
vs-virtualA's irule:
rule irule-bypass {
when CLIENT_ACCEPTED {
virtual vs-virtualB
}
}
vs-virtualB's irule:
rule irule-dest{
when HTTP_REQUEST {
HTTP::respond 200 content "
Triggered | client:[IP::client_addr]
"
}
}
2 Replies
- Kevin_Stewart
Employee
Semantically speaking, it's less of a redirect and more of a forward, but nonetheless you likely have a SNAT profile applied which is changing the client source. I think the easiest thing would be to simply choose another method of relaying the client source address. Here are two options:
1. HTTP headers
2. Sharedvar (https://devcentral.f5.com/wiki/iRules.sharedvar.ashx) - a really cool way of sharing a variable between targeted VIPs
Alternatively, you can either disable SNAT or issue a true redirect (via HTTP::redirect or HTTP::respond) and have the client go directly to the second VIP. 
JonG_107817Indeed snatting is involved here. I'll investigate the HTTP Header option and the shared var options you suggest.
Thanks!
