Dual Homed Servers
In this blog I look at how you can dual-network home a Windows server, and how you need to consider the network routing.
====
A number of server roles can require multiple network interfaces - the Access Edge server for example. This can lead to an issue where both network cards are on the same subnet.
The issue arises due to the fact that you're never quite sure which interface your traffic is going out of. On the Access Edge, this causes a problem as traffic for the Internet must come out of its own interface whereas traffic destined for the internal network subnets must come out of another. From a firewall perspective, you need to know which interface is being used for traffic as you need to set the rules appropriately.
So, how do we deal with? Well the simplest way is to do it via the routing command. First, consider this scenario.
In this example we have a server with two network interfaces connected to the same subnet of 192.168.143.0. The default gateway is set to the internet facing gateway of 192.168.143.254.
One thing to note here is that you can only have one default gateway. Setting a default gateway on both interfaces is pointless and can lead to bizarre behaviour - even more so if the default gateways are different. So, rule number 1, only specify a single default gateway.
So let's assume that your internal network is all the private addressing ranges of 10.0.0.0 – 10.255.255.255, 172.16.0.0 – 172.31.255.255 and 192.168.0.0 – 192.168.255.255. What we want to achieve is that all traffic for the internal network goes out of the interface 192.16.143.129 only and it goes via the internal gateway of 192.168.143.2.
So, firstly, how do we check to see which interface traffic is trying to go out of? The trick is to use TELNET and the NETSTAT command. The telnet session is used to start a connection to a remote host, and the NETSTAT command can be used to work out which interface is being used.
In this example, I'm going to connect to the SIP service on an OCS front-end server. So, first fire up two DOS prompts. In the first box, type 'NETSTAT -n' - you'll get an output like this.
This will show any existing connections - the local address being the local interface being used, and the foreign address being the target. The :xxx shows the source and destination ports respectively. In the other DOS prompt, start a TELNET session to your host on a known port. In my example, I'm using the SIP service on an OCS front-end service. For example you could use 'TELNET host port' or in my example 'TELNET 172.22.0.141 5061' where 172.22.0.141 is my SIP server and 5061 is the SIP service.
Now, if your routing works the system will connect to your target service. At this point, you can run the 'NETSTAT -n' command and see which interface the connection is going out from. Look out for the target IP address in the 'Foreign Address' column and the port that you specified. If your routing doesn't work, if you're going out of the wrong interface and via the wrong gateway for example, your system won't connect in the TELNET session. The 'NETSTAT -n' command can still be used to view the interface and the port however - the state will simply be 'SYN_SENT'. See the example here.
Line 3 shows my local interface of 192.168.143.128 (My internet facing network card) and the destination address of 172.22.0.141:5061 in a 'SYN_SENT' state. From this, we can see that the request is going out of the wrong interface.
So how do we resolve? Well it's essentially by adding in a static IP route which is in itself pretty easy - the trick is to make sure you specify the interface to use for the route. To get a print out of your routing table use the command 'ROUTE PRINT' from your DOS prompt. You'll get a screen like this.
Make a note of the interface references at the top. 0x10003 refers to the NIC with the MAC address of 00-0c-29-dc-1d-3f which is our internet facing NIC. 0x10004 refers to the MAC address of 00-0c-29-dc-1d-49 which is our internally facing NIC, and the one we're interested in.
What we're going to do is add static routes for the private address ranges via the internally facing NIC and via the internally facing gateway. Do this with the following commands:
ROUTE ADD 10.0.0.0 mask 255.255.255.0 192.168.143.2 IF 0x10004 -p
ROUTE ADD 172.16.0.0 mask 255.240.0.0 192.168.143.2 IF 0x10004 -p
The above commands may wrap - they need to be entered on the same line. Note the 'IF 0x10004' - this is where we specify which actual physical interface to use for the route. If you'd just have entered the gateway without this you may still be able to route to your target but you wouldn't be able to control the interface that the traffic is sourced from.
Enter the above commands, and re-run the 'ROUTE PRINT' you'll get this screen.
You'll now see the addition of the static routes at the bottom of the list - note it doesn't however specify the interface.
How do we test to make sure we're using the right interface? Well, as above, we use the TELNET test along with 'NETSTAT -n' to see where the traffic is going.
Fire up a couple of DOS prompts and in one window start a TELNET session to an internal host on a port you know to be open (and accessible via your firewall!). In my example, I'm connecting to an OCS Front-End server's SIP port with 'TELNET 172.22.0.141 5061'. Once you've started your telnet session, re-run the 'NETSTAT -n' command in the other window, and you should hopefully get an output like this:
Now, in this screen you can see on the last line a session to my target address of 172.22.0.141:5061 going out of the 192.168.142.129 interface - our internally facing interface. Also, the session is established showing that we're hitting the right gateway.
This is exactly what we wanted.
In general multi-homing Windows machines on the same subnet is not to be recommended, especially if you're using the machine for 'normal' Windows services such as file/print etc. For service provision as a SIP Proxy/Access Edge, mediation etc. however it's completely workable but more complex to set up.
Another note for your DNS by the way is to be make sure that only the relevant interface is entered into your DNS. For example on an Access Edge role you want the DNS entry to return the correct IP Address for the internal interface.
On another note I've seen a number of sites where people have tried to control routing behaviour by changing binding orders and the like. They've often had some success doing this too. One thing I often hear about this scenario though is that it 'mostly works' and is 'a bit flakey'. Controlling the routing behaviour as above is as solid as a rock and just works. The binding order & multiple default gateways just seems flakey.
So, there you have it, how to control multi-homed routing. Who said Windows wasn't exciting.
blog comments powered by Disqus