Topic: FW (ISA Server) Blocking LOGS

[savagejay]

Hi folks, running a rather in-depth enterprise class web system where
in addition to our ASA Firewall we also run an MS ISA server to handle
traffic to our exchange server...

ANYHOW... I go the ISA server to open and forward http traffic to
our WAMP server though upon checking the Log files (access specifically)
it is showing the IP of the ISA Server and not the browser...

I cannot find a way to do proper web statistics on our sites (we have
7 of them running) if the only stats I can get are from the ISA server...

Taking a shot in the dark here that someone has run into this???

Thanks for any help.

[tdonovan]

Taking a "a shot in the dark" at a reply: most proxies add an X-Forwarded-For HTTP header to the request. Perhaps MS ISA does this, or can be configured to do so.

If it does, you can adjust your log format and add %{X-Forwarded-For}i which should add this info to your log file.

Hope this helps.

-tom-

[savagejay]

Here's a long answer I got from another forum,
the resolution is at the end, I never thought of the outbound
gateway.... Anyway here it is for those that may run into this:

"With the setting "Requests appear to come from the ISA Server computer", the logic is...

The request comes into ISA and ISA sends it back to the internal web server. When ISA does this, it changes the "Source IP" address field in the IP Header to it's Internal adapter IP address. When the web server sees this request (we'll assume it's on the same logical segment as ISA), it sees the source IP is ISA. It checks it's routing table and says "Oh! This address is directly accessible to me. All I have to do is ARP for this IP and if I get a ARP response, I'll deliver it directly to that host." and the response is complete as far as the web server is concerned.

Now, with the setting "Requests appear to come from the original client", the logic is...

The request comes into ISA and ISA sends it back to the internal web server. When ISA does this, it leaves the "Source IP" address field in the IP Header alone - the external client's IP is maintained. When the web server sees this request (we'll assume it's on the same logical segment as ISA), it sees the source IP is someone on the internet. It checks it's routing table and says "Oh! This address isn't directly accessible to me. My routing table says that if I don't have a more specific route, my next hop is x.x.x.x, or my default gateway. Let me ARP for the gateway and if I get a response, I'll deliver it to that system". The request is now done as far as the web server is concerned.

With the setting for "Requests appear to come from original client" it is essential that the return path for responses from the web server honor the incoming path of the request (as far as your network is concerned - we won't get into the path that is used on the internet) - in other words, if the request came in from ISA and this setting is enabled, then the response has to go out through ISA as well.

This begs the question, why can't it go out some other device fo the response. 2 reasons - if that other device is capable of stateful inspection, it will not have any state for the response from the web server since the original packet came in through ISA. The second reason is that even if that device doesn't perform stateful inspection,, it most likley does NAT. As the response goes through that other device, the source IP will get changed to the NAT device's IP and by the time the original client gets the response, the source IP is not who the client sent it's request to and it will drop the response.

Essentially, if you have the option for "Request appears to come from original client" then the internal server must point to ISA for its default gateway."

Incidentally, your idea worked as well for a workaround for the logs...
thanks Tom!