Multi-homing Windows Server 2019
Historically, there haven't been many scenarios that require Windows servers to have a connection to more than one network. This is because most of the roles that they were accomplishing were done on whatever single network they were plugged into. There was no need for a server to have direct connections to multiple networks because that was the router and switch's job, right? In today's Windows Server world, there are numerous roles that can take advantage of multi-homing, which simply means having multiple network cards connected to different networks at the same time. There are some proxy roles that can use multiple NICs; Remote Access roles such as DirectAccess and VPN recommend a dual-NIC setup, and you can even use a Windows Server as a general router if you want to.
If you work a lot with DirectAccess, you will find many multi-homed servers with incorrect network configurations. This recipe is a collection of points that need to be followed when configuring a Windows Server with multiple NICs that are connected to different networks to make sure it behaves and flows traffic as you expect it to.
Getting ready
You just need a Windows Server 2019 instance online for this recipe. We have two NICs installed on this server and they are plugged into different networks. I am prepping a Remote Access server that will sit on the edge, so I have one NIC plugged into the corporate internal network and the other connected to the internet.
How to do it…
To configure a Windows Server with multiple NICs, perform the following process:
- Only one Default Gateway: In your NIC properties, you need to make sure that you only have a Default Gateway identified on one of your NICs. This is the most common mistake that I find in the field. If you have two NICs, it would seem logical that you would simply populate their IP address settings just like you would with any server or computer, right? Nope. The purpose of a Default Gateway is to be the fallback or the route of last resort. Whenever your server tries to send out network traffic, it will search the local routing table for information on how to send out that traffic. If it does not find a specific route that corresponds to the IP address that you are sending to, then it will default that traffic over to the Default Gateway address. Therefore, you only ever want to have one Default Gateway assigned on a server, no matter how many NICs are connected. On all other NICs installed on the system, simply leave the Default Gateway field unpopulated inside the TCP/IP properties. By the way, for a DirectAccess server or for pretty much any other server that faces the internet, the Default Gateway needs to be on the external NIC, so I will be leaving that field empty in the properties of my internal NIC.
- Limit your DNS servers: Another common configuration that I have seen is to have DNS server addresses defined for every network adapter installed on the system. While this doesn't usually break anything like multiple Default Gateways can, it does cause unnecessary slowness when the system is trying to resolve DNS names. Try to have DNS server addresses configured on only one NIC. Once again, using our example DirectAccess server setup, I will be configuring DNS server addresses on my internal NIC because that is necessary for DA to work. I will not be putting my public DNS server specifications into the external NIC; instead, I will leave those fields empty.
- Use static IP addresses: The roles and functions you may perform on a Windows Server that require multiple NICs will be best served by having static IP address information assigned to those network cards. If you let one or more of the NICs pull information from DHCP, you could easily create a situation where you have too many DNS servers defined, or where you have multiple Default Gateways on your system. As we already know, neither of these scenarios is desirable.
- Prioritize the NIC binding: It is a good practice to set a priority for your NICs so that you can place the card that you expect to have the most network traffic as #1 in the list. For our DirectAccess server, we always want the internal NIC to be placed on the top. In earlier versions of Window Server, this could be done via the GUI. However, in Windows Server 2019, the only way we can do this is via PowerShell.
- Follow these steps:
- Open PowerShell as Administrator.
- Run Get-NetIPInterface -AddressFamily IPv4. You will receive a list of network connections that are available on your server. The fields we're interested in are InterfaceAlias and InterfaceMetric:
- If your internal network has an InterfaceMetric value lower than your external network, then you can stop here. However, if the InterfaceMetric value of the external interface is the same or lower than your internal interface, then it needs to be renumbered with Set-NetIPInterface -InterfaceAlias 'External' -InterfaceMetric 20, where External is the name of your external adapter and InterfaceMetric is higher than InterfaceMetric of your internal adapter:
- Add static routes: A couple of minutes ago, you probably started thinking 'Hey, if I don't have a Default Gateway on my internal NIC, what tells the server how to get packets into the subnets of my internal network?' Great question! Because you only have one Default Gateway, when you need to send traffic out one of the other NICs, you need to make sure that a static route exists in the Windows routing table. This ensures that the server knows which interface gets traffic for each subnet. Make sure to check out the next two recipes for specific information on how to add those routes.
How it works…
Anybody can multi-home their server by simply plugging two NICs into two different networks. The tricky part is making sure that you configure those NICs and the operating system appropriately so that network traffic flows in the right directions at the right times. Following this list of rules will give you a solid foundation so that you can build out these types of scenarios and know that you are doing so in the correct fashion. Deviating from these rules will result in unexpected behavior, which sometimes is not immediately obvious. This can make for some very frustrating troubleshooting down the road.
See also
- Adding a static route to the Windows routing table
- Using dynamic BGP routing in your Windows routing table