Does anyone know how I can prevent the leak of the internal IP address? I've fixed similar issues from an IIS angle where you can use an IIS admin script to set either usehostname or sethostname. But I don't see how I can apply this to an ISA server.
Hi... thanks for that. I did look at the http filter and thought that the only chance I had was on the signatures tab and trying to block it there. However nothing I tried seemed to make any difference. I wondered whether it was because the response was coming from ISA itself rather than the site being proxied; perhaps it wasn't intercepting at the right point. I believe that the redirect (which includes the IP address) is being inserted by ISA. FWIW, I am using the http filter to block the web server header which is working fine.
Can anyone else confirm that this they get the same response from ISA in the given scenario?
From: Southern California
The LOCATION header included with an HTTP 302 'Object Moved' response is generated by either the web server or by the actual web page itself (e.g. using Response.Redirect in ASP). Conceivably you could use the HTTP filter to modify the response, however, I am not aware of any way to alter request or response headers other than the SERVER and VIA headers. You can allow and deny them selectively, but that doesn't really solve your problem here. It might be possible to do this with a third-party plug-in, but I don't specifically know of one.
The best solution would be to perform the protocol redirection with ISA (configure bridging to redirect HTTP requests to HTTPS), or have your web server administrator or the application developer change the redirect to use the public host name instead of the private host name.
Thanks for posting Richard but I am using bridging. It might help if I explain more about my scenario.
I am terminating SSL at the proxy server like this: Client <--https--> ISA 2006 <--http--> server Within the proxy rule, I have the bridging tab set to redirect to port 80 on the internal web server, so I'm pretty sure that the redirect is not coming from the internal web server.
On the listener properties, I have the "connections" tab set to enable both port 80 and 443 and "HTTP to HTTPS redirection" set to redirect all traffic from http to https (the bottom option).
What I believe is happening is that the listener is doing what it's told, i.e. redirect all traffic to port 443. On a HTTP/1.1 request, that's fine because the request needs to specify a host (well.. a properly formed HTTP/1.1 request will specify it) so ISA can construct the correct location header. However, with HTTP/1.0, there is no such host entry so ISA can only redirect to what it knows and because it's a protocol shift (from http to https), the redirect cannot be relative. So it returns a new location entry of "https://IP_ADDRESS" - which is not good
I know this thread is old but I just had a case similar to this. The solution is to not use "Require All Users to Authenticate" on the Listener tab. Let the rule require authentication by putting something such as "All Authenticated Users" in the Users tab.
I saw this thread because of Keith's update, so now I am obliged to comment on Richard's comment:
I am not aware of any way to alter request or response headers other than the SERVER and VIA headers. You can allow and deny them selectively, but that doesn't really solve your problem here. It might be possible to do this with a third-party plug-in, but I don't specifically know of one.
This is why we made IsaScript. Of course any solution that saves you having to use a third party filter would be a win. If you can avoid the problem behavior entirely then great!