Hitting Webservice on Different Subnet

Question

Hello,

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.

Thanks in advance for your help.

Thanks, CJAM

Answer 1

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

Answer 2

Haha, that's funny that you say that. I thought about using Fiddler to do something similar. I'm more looking for something that can be run as a service though. I would hate to have someone accidentally console in and log off the user that is running the app. Boom Registration down: Customers affected > 1,000.

Answer 3

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 4

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.

Answer 5

First off, thank you all for the help. The response time on this site is amazing. Props to Joel Spolsky for making the site.

As for my question, the main issue is a result of our department structure and due to the fast growth of the company. Things are in the process of being changed to meet growing demands. However, as it stands currently, my department is on the 10 network, but the department that houses the web service is on the 172. I don't believe that these two networks ever connect, let alone know of each other's existence. I'm mainly trying to find a band aid, so I can continue developing other projects and mark this task semi-complete for the time being. I found an IIS module that runs as an IIS site, but I'm having some trouble implementing it and the documentation is pretty sparse (which worries me in itself).

I may end up just upgrading the web service version on the server, but I'd rather find a proxy method so we're not expanding resources across multiple boxes. Each web service uses up resources for the main API that it uses to interact w/ a UNIX based server.

So the saga continues :)