System.Net.WebRequest problems

This problem has been killing me. The overall problem is within a complex app, site and service installation, but i've scaled it right back to a simple web application that invokes a web request on another unsecured resource. My web app is very simple with just the following in Page_Load:

1   2 3

System.Net.WebRequest tx = System.Net.WebRequest.Create ("http://othermachine/listener.aspx"); System.Net.WebResponse rx = tx.GetResponse(); rx.Close();

This script is hosted on localhost and othermachine is within the intranet zone and no proxies etc are involved. On my machine things work fine, but on the other machines in the office (who also have the above installed on localhost) we the error message below during execution of the web request to the other machine (line 2 of the source);

A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond

Now, here's the kicker. the above code works when it's run through the VS.NET ASP.NET Development web server! It only fails when it's served through IIS!!! I've been trying to work this out for 2 days now to no avail. If anyone has any ideas, please get in touch....there's a beer in it for the solver!

UPDATE - HERE'S THE SOLUTION
Despite it working when hosted outside of IIS, and despite checking in several places to see if proxy / firewalls were to blame it turned out that when the above code was hosted within IIS it WAS using a proxy server on the failing machines. The solution was to simply disable the proxy for the app through web.config:

<system.net>
<defaultProxy enabled="false"/>
</system.net>

For some unknown reason, when hosted under IIS, the WebRequest would initialise and then ask the proxy server (configured in IE) for access to othermachine, but it would obviously ask the proxy server for this access as LOCALMACHINE\ASPNET or NETWORK SERVICE - which of course would probably be refused access to the proxy.

Really don't know why this was a problem under IIS only, but the above setting should work regardless of hosting environment.