Hitting Webservice on Different Subnet

Question

I know this is somewhat of a server question, but I wanted to ask anyways in case someone has done this before.

I have a web service that is on our internal 172.x.x.x subnet and a web server that is on our internal 10.x.x.x subnet. The webserver needs to hit the 172 web service, but is unable to route there. The real solution would be to convince our network admins to put the server on the 172 network behind the DMZ, but this solution seems far off.

My quick and dirty solution is to create a proxy server on a box that connects to both networks, so I can then program my web service calls to hit the proxy server. However, I am a developer and have little knowledge on how to set this up.

I have friends that have had good luck with Squid Proxy Server in Nix, but the only box that is available for me is a Windows Server 2003 box. Ideally, I would like some sort of proxy that I could set up on top of IIS. Do you guys know of anything? I've seen some reviews for ISA Server 2006, but I'd hate to charge up the corporate budget since we only need it for this one web service.

Answer 1

As you mentioned, the best option is to cram the web server into the DMZ. That being impossible, see if the wiremonkeys can open up the appropriate port in the firewall just between the server and the web service (and just for http/https traffic). If both are impossible, I guess a proxy is possible (if the proxy is allowed to relay between the two networks).

The thing I keep asking myself, however, is under what circumstances could you have a web service for which you have a business need, yet you're not allowed to expose it on the 'Z? Are your wiremonkeys so resistant to change that you can't get your job done? If so, jump ship, man! Life's too short.

Answer 2

It is really quick and dirty, but you could use the tcpmon tool on a windows machine that has access to both networks.

Answer 3

I have to agree with Danimal that the right way to handle this would be to have the appropriate holes poked in the firewall. Especially if, as you have said, the interface is important to a customer-facing application.

It seems to me that "customers affected > 1000" is a great business case to convince the network admins, or perhaps their boss(es) to expend the effort on safely allowing your traffic.