Our current server layout has 4 servers running on an external IP address all multi-homed using the 192.168.1.x network for external public access and the 192.168.5.x network for internal communication between all servers.
The 192.168.1.x and 192.168. 5.x networks are individual NICs on each server and run through distinct routers.
We have a bank of IP addresses, 1.2.3.122 being our current main site, the secondary (internal) router we would like to set up for testing and load balancing (mainly to get our system traffic off the same pipe as client traffic).
The 1.2.3.122 traffic works fine through the 192.168.1.x network and the servers all respond to traffic and requests without issue. However, attempting to access the 192.168.5.x network through a new IP address (1.2.3.125) is not working at all. If you are internal to the network, you can access the website on the server at (5.100), but it will not accept traffic through the external router.
However, if we switch the 192.168.5.x router to be on the 1.2.3.122 IP address, we can access our servers.
Is there a way to allow Windows Server 2012 to watch for internet traffic on both the 192.168.1.x and the 192.168.5.x subnets and properly respond to outside requests from them?
Our servers are Windows Server 2012 R2. Router on one side (192.168.1.x subnet / 1.2.3.122 external - default gateway) is a Cisco RV082 (small business router). On the other side (192.168.5.x subnet / 1.2.3.125 external / routing rules set up to pass traffic through 192.168.5.1 router for gateway to 192.168.5.x network - the side that doesn`t work externally) we have a Cisco 2911 router.
Answer
Your responses to comments are enough to clarify for me.
Windows Server 2012 doesn't have the functionality to do what you're looking for. You're looking for some basic policy-based routing functionality, which Windows has never had decent support for.
I don't know about the Cisco RV082 (which, if memory serves, is a re-badged Linksys offering), but the 2911 could NAT the traffic from the Internet to an address local to its 192.168.5.0/24 interface. Assuming you could get the same thing going on the RV082 side you'd find that the Windows machines would respond to requests out the "correct" NIC.
This is likely not a real world solution. This would be problematic because the Windows machines wouldn't have knowledge of the real source IP address of clients. Surely, at the least, this would be an analytics problem, if not exposing other problems in your apps where it might be assumed that you'll have knowledge of the client's IP address.
A better solution would be to put a policy-based routing solution in place ahead of the Windows Server machines. (I'd probably throw a Linux machine (or machines) upstream from the Windows Server machines running one of the various popular HTTP reverse-proxy applications, but that's personal preference.)
No comments:
Post a Comment