Forum Discussion
Xylene_UK_11374
Nimbostratus
NimbostratusIIS REMOTE_ADDR
Previously we had opened a case regarding the use of the Request.ServerVariable("REMOTE_ADDR") in ASP code. When we front our ASP sites with the LTM this Server Variable is changed to the a self-ip on the ltm. Since this code reference is pervasive we'd has preferred to not change it, but changing was certainly an option (undesirable nonetheless). However, we have discovered that we have a few vendor packages written in .NET and ASP that also use REMOTE_ADDR, and the issue is that we have no control over their code. We need to get a solution that will essentially substitute the client ip into the header so that it will be consumed by REMOTE_ADDR correctly. I was trying to work with the following iRule but I don't know what header value to change so that REMOTE_ADDR will pick it up.
when HTTP_REQUEST {
HTTP::header replace REMOTE_ADDR [IP::remote_addr]
}
Also, we tried Layer4 Forwarding without any success. I think that the iRule should "fit the bill", but I have no idea what to replace. Is there a list of header values you pass from the LTM that we could look at so we can determine which one contains the self-ip which is subsequently pulled by REMOTE_ADDR?
14 Replies
Xylene_UK_11374Hey,
The following was sent from our F5 account engineer. Thoughts on her
suggestions?
In order for the BIG-IP to enhance the performance and security of
application traffic, that traffic has to go into and out of the BIG-IP
(or any load balancer). If a server that is behind the BIG-IP uses the
BIG-IP as its default gateway, then the original client address is
retained. The source IP is that of the client and can be used by the
server. This is a routed configuration and probably the most common
configuration.
If a real server does not use the BIG-IP as the gateway, then the only
way to get traffic back to the BIG-IP is to use "SNAT". With SNAT, the
BIG-IP changes the IP source address of the client to the BIG-IP's
address. Then the server will send traffic back to the BIG-IP. The
"SNAT" configuration is also very common. Since the original client
address is no longer in the packet, a header is inserted, usually the
X-Forwarded-For header, that includes the client address. Then the web
server runs some code to extract the client IP value. Here is a link to
the IIS filter at F5 DevCentral:
http://devcentral.f5.com/Default.aspx?tabid=38. The X-Forwarded-For
header is a de facto standard and widely used anytime a load balancer is
installed.
The only other option is to use an "npath" configuration. In this setup,
the real server accepts traffic directed to the virtual IP address and
the return traffic bypasses the BIG-IP. This requires special setup on
the real server and is much less commonly used, since its use eliminates
much of the benefit of having an application delivery platform and it is
not as easy to support.
hoolioCirrostratus
I agree with all of that, with two clarifications: the DLL will modify the IP address which IIS logs. I don't think it will have any effect on the SERVER_ADDR CGI variable. And with ASM it is important that the response go back through ASM so that you can see what effect the request had on the server (ie the response code from the web server). Also, there might be an issue where ASM wastes resources waiting for the response that will never arrive. This is a guess though. So I don't think nPath is a good solution with ASM.
I think a reasonable solution would be to depend on redundancy of the active-standby ASM units. Or if you're very concerned about ASM on both units being affected by some kind of attack, you could create a second non-ASM VIP on the ASM units and use that as a lower priority member in the LTM pool.
Aaron- I don't know much about IIS, but some searching brings me http://blogs.msdn.com/david.wang/archive/2005/09/28/HOWTO-ISAPI-Filter-which-Logs-original-Client-IP-for-Load-Balanced-IIS-Servers.aspx, which seems to be pretty definitive (if you look at the comments) that there is no way on IIS to change that variable. The only way to make it be the real client IP is to have your IIS server receive traffic from the real client IP.
You also said that your ASM setup (ASM is something else I'm not an expert on) requires SNAT. I'm going to assume that that's true. In that case, even vlangroups will not help. So as far as I can see, there is no clean solution.
There's one wacky thing that *might* work, though, which is have the packets coming from the ASM be rewritten to have the real client IPs. One way to accomplish this *might* be via tagged vlans. The traffic flow would be:
1) Traffic comes in to your LTM from the Internet on, say, VLAN 100.
2) The LTM inserts a custom header with the real client IP
3) The LTM SNATs the traffic and sends it to the ASM on VLAN 100.
4) The ASM sends the traffic back to another, different VIP on the LTM on, say, VLAN 200.
5) The LTM, via an iRule, reads the custom header, and re-SNATs the traffic back to the original client IP, and sends it to the server on VLAN 200.
I think that this should work, and that auto-lasthop should make things just work for the return traffic.
This assumes your servers support tagged VLANs (which they really should). If they don't, then you might be able to accomplish the same thing with Route Domains on v10.x.
Again, I can't promise this is a solution, but it might be worth trying. - Xylene_UK_11374Hey,
Unfortunately I think I may have been steering us down the wrong path.
For the site on which we're trying to retrieve the client IP we don't
not use the ASM. The traffic for this site is routed directly from the
LTM to the IIS server. Since that is the case what would your suggestion
be outside of making a gateway change on the IIS server (Which we have
attempted multiple times without success).
Thanks
