I have a Win2003 web server with two network cards. I have two
ADSL lines from two different ISPs, each with a different static IP
address on a different subnet. I want to connect one DSL line to each
of the two network cards and have the web server listen on both IP
addresses. The purpose is to have failure tolerance in case one of the
DSL lines goes down, and secondarily to load balance between the two
connections when both are up.
Here is an example of what happens now...
1) A request packet(s) comes in from somewhere out on the internet on
Card #2 with a destination IP address #2.
2) The application processes the request and sends a response packet(s)
with the source being IP address #2.
3) Windows looks up the _destination_ IP address for the response
packet (which is some random address out on the internet) in the
routing table and does not find a route, so uses the default gateway.
4) The response packet goes out to the default gateway, which is
connected to card #1.
5) The ISP connected to card #1 sees that this new packet has a source
IP address that does not belong on this connection (because that
address belongs to ISP #2) and discards the packet.
Here is what I would like to have happen...
4) The windows router knows to transmit the response packet out on
card #2 and uses the default gateway on that connection.
5) ISP #2 gets the packet and forwards it on to the IP address that
sent the request.
I can not use Windows standard destination-address-based routes to
achieve what I want because any address out on the internet could
potentially come in on either network card.
If there were just a version of the ROUTE ADD command that included
source address info, I'd be all set. The only problem is that far as I
can tell, there is no way to add an entry to the windows routing table
that includes
matching on _source_ address.
So, the question is - how can I get this setup with one Win2003
computer and two cards and ISP connections to work?
Non-answers include:
1) Use BGP - I can't because upstream ISPs won't listen to my BGP
advertisements. And anyway, I shouldn't need to.
2) Use Linux - Assume the app I am supporting only runs on Windows. (2nd
level non-answer is to port the application to Linux).
3) Use an external router - The whole point of this exercise is to
increase availability, so adding a new since point of failure is not a
good solution. (2nd level non-answer is to use a fault tolerant external router).
4) Set up destination routes for half the IP address on the internet
on one NIC and the other half on the other. I want any address on the
internet to be able to come in on either NIC and have it work.
Likely answer will be something like...
1) Some little known command/configuration/registry setting that
actually lets you add source-address based routes to the Windows routing
table. This is seeming very unlikely at this point.
2) Some Microsoft or 3rd party software add-on product that lets you
do this. It would probably take the form of an NDIS Intermediate
driver. If all else fails, I'll probably have to write this, but I'd
rather buy it.
3) Some very creative way of setting up something like an inverse NAT -
if that makes any sense. Normal NATs take lots of internal IPs and map
them to a single outgoing IP and keep track of which packets should go
to which hosts. Imagine the same setup except backwards - the whole
internet is now the internal network and the single server is the external
network. This seems possible, but I have no idea how to do it with the
Windows NAT stuff.
Extra credit:
All this will only make applications that listen for incoming
packets/connections be failure tolerant. Any connections that
originate on the local machine will take extra effort. While it is
possible that the local application might be smart enough to bind and
try to multiple cards/IP addresses for outgoing connections, it is
unlikely. So, the next step would be to create a virtual local IP
address that local applications could bind to that under the hood
would hot-map to either of the real IP addresses for outbound
connections. The code controlling this virtual IP could be smart
enough even to bounce between the real IP addresses when connection it
saw connection failures.
Thanks! |