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?
hoolioCirrostratus
Hi,
You will need to change the application code or disable SNAT. REMOTE_ADDR is a CGI variable which IIS provides based on the source IP address of the TCP packet. It is not set based on an HTTP header value.
So if you're using SNAT and want to get the original client IP address, you can enable insertion of the X-Forwarded-For HTTP header on a custom HTTP profile. This dictates that LTM insert the original client IP address in an HTTP header named X-Forwarded-For. You would need to change all references in the application from REMOTE_ADDR to HTTP_X_FORWARDED_FOR.
For more info, you can check SOL4816:
SOL4816 - Using the X-Forwarded-For HTTP header to preserve the original client IP address for traffic translated by a SNAT
https://support.f5.com/kb/en-us/solutions/public/4000/800/sol4816.html (Click here)
Aaron
Xylene_UK_11374Hi Aaron,
Thanks for the update.
Is there any way of doing this without using the x-forwarded method. say I dont have access to the back end servers?- hoolioIf you can change the default gateway of the servers to the LTM's floating self IP address on the server VLAN (and no clients access the virtual server from the same VLAN as the servers) you could disable SNAT on the virtual server. If you need to use SNAT, you'd need to change the app to parse the client IP address from a custom HTTP header like the XFF header.
If you're using the client IP address for anything but reporting, you should also remove any pre-existing XFF headers by setting the HTTP profile option for 'Header to Remove' to X-Forwarded-For. This ensures that LTM will remove any XFF headers inserted by a previous device in the chain before inserting its own XFF header.
Aaron - Xylene_UK_11374Hi Aaron,
Many thanks for the options, I will see how best I can use this in my set up and let you know the outcome. - Xylene_UK_11374We need to utilize Auto Map SNAT so that our traffic can be routed
properly through our ASM (Our ASM functionality would not work without
it). Also, we have vendor code that references REMOTE_ADDR so changing
it to reference XFF header is not an option for us.
Sorry. - hoolioDo you have a standalone ASM unit (or units) being load balanced by an LTM unit? If so, I think auto lasthop on the ASM would ensure the response to the client goes back from the ASM to the LTM even if the LTM is not performing SNAT. This assumes the flow is:
client - LTM - ASM - server
Aaron - Xylene_UK_11374We do indeed have the architecture you mention, but we have our pools
configured with priority groups so that the LTM will route directly to
our servers if the ASM is non-functional. Would this matter? - hoolioI don't see how that would work without SNAT on the LTM or on the ASM, as I think the server would need to dynamically update it's routing table based on the state of the ASM unit. Anyone else have ideas?
Do you have two ASM units? If so, you wouldn't need to worry about failing open directly to the web server pool.
Aaron - Xylene_UK_11374Hey,
The configuration involving the priority group for direct access to the
HTTP servers via the LTM in case of ASM failover was suggested and
configured by an F5 ASM consultant as best practice. We do indeed have a
failover pair of ASMs but the consultant deemed this configuration as
the best way to ensure 0% downtime for our properties.
Have you heard of anyone loading an ISAPI filter on the IIS server
directly to make this change? I saw a posting on devcentral in which the
developer "faked" IIS into adding the Xforward information into the IIS
logs instead of the actual client ip. Perhaps the same "fake" could be
done for standard use of REMOTE_ADDR. Thoughts?
Thanks, - hoolioIf you have a pair of ASM units, I personally don't see the need to fail open direct to the pool. But I don't have all of the details of your implementation and requirements. What would take both ASM units down? Would you also need to account for a similar possibility of both LTM units going down simultaneously? If you're concerned about the ASM processes themselves, I suppose you could configure a non-ASM VIP on the ASM units and add that as a lower priority pool member on the LTMs.
The XFF logging DLL which Joe created (Click here) will log the XFF value, but won't change the CGI variable REMOTE_ADDR which IIS sets.
Aaron