This recipe follows right on the heels of our previous topic. If you have never worked on a server that is making use of more than one NIC, then you have probably never had a reason to poke around in the Windows routing table. The minute that you are tasked with setting up a new server that needs to be connected to multiple networks, or that you get thrown into a situation where you need to troubleshoot such a system, this suddenly becomes critical information to have in your back pocket.
On a server that is connected to multiple networks, you only have one Default Gateway address defined. This means any subnets that need to be reached by flowing through one of the other NICs, the ones that do not contain the Default Gateway, need to be specifically defined inside the routing table. Otherwise, Windows simply does not know how to get to those subnets and it will attempt to push all traffic through the Default Gateway. This traffic will never make it to its destination and communications will fail.
Today, we are setting up a new VPN server. This server has a NIC plugged into the Internet where remote clients will come in, and another NIC plugged into the internal network so that the client traffic can make its way to the application servers that the users need to access. In this scenario, the Default Gateway must be populated on the External NIC. There will be no Default Gateway address defined on the Internal NIC, and without some assistance, Windows will have no idea how to properly route traffic toward the servers inside the network.
For our example, the Internal NIC is plugged into the 10.0.0.x network. Since it has a direct physical connection to this network, it is automatically able to properly contact other servers that reside on this subnet. So if the VPN server was 10.0.0.5 and we had a Domain Controller running on 10.0.0.2, we would be able to contact that Domain Controller without any additional configuration. But most companies have multiple subnets inside their network. So what if our VPN users needed to contact a web server that is sitting on the 10.0.1.x network? When traffic comes into the VPN server looking for a destination of 10.0.1.8 (the web server), the VPN server will check its local routing table and find that it does not have an entry for the 10.0.1.x network. Since it doesn't know what to do with this request, it sends it to the Default Gateway, which sends the packets back out the External NIC. Those packets don't have a valid destination to reach through the External NIC, which is plugged into the Internet, and so the traffic simply fails.
We need to define a static route in the routing table of our VPN server, so that when VPN clients request resources inside the 10.0.1.x network, then that traffic makes its way to the destination network successfully. We need to bind this route to our Internal NIC so that the VPN server knows it has to send these packets through that physical network interface.
We are setting up a new Windows Server 2016 VPN server. This server has two NICs installed, one plugged into the Internet and the other plugged into the internal network. Inside our corporate network, there are two subnets. 10.0.0.x (/24), which our Internal NIC is plugged into, and 10.0.1.x (/24), where our web server resides. There is, of course, a router between the two internal subnets, which is how traffic physically flows between the two. The IP address of that router is 10.0.0.254. If we were able to configure a Default Gateway on the Internal NIC of our VPN server, it would be set to 10.0.0.254, and all traffic would work without any further input. However, since our VPN server is multi-homed and there can only be a Default Gateway configured on the External NIC, we need to tell the server that it has to push 10.0.1.x traffic through 10.0.0.254 by using the Internal NIC.
So basically, we need to do the following to create a static route in our VPN server:
- Identify the subnet that we want to contact. In our example, it is 10.0.1.0
- Identify the subnet mask, which is 255.255.255.0
- Identify the IP address of the router that will get us to that network, which is 10.0.0.254
- Identify the Interface ID number of the physical NIC that needs to carry this traffic, which can be attained as follows:
- Discovering this NIC ID is going to take us a minute. First, open up Network Connections and expand the fields so that you can see the device name of each NIC.
- Now open Command Prompt and type
route print. This is a print of your entire routing table. Scroll back up to the very top and you will see the Interface ID numbers of your NICs listed.
We can see that our Internal NIC is the second NIC, named
Microsoft Hyper-V Network Adapter #2. Looking at that entry in the route print, there is a number over to the left of that name. This is our Internal NIC's Interface ID number, which is4in this example. - Discovering this NIC ID is going to take us a minute. First, open up Network Connections and expand the fields so that you can see the device name of each NIC.
We now have all the information needed to put together our route statement and bind it to our Internal NIC. The general format that our route add statement needs to take is route add -p <subnet> mask <mask> <gateway> if <interfaceID>. The -p part of the command is very important as it makes this route persistent. Without the -p part, our new route would disappear after the reboot.
So, in order to tell our VPN server how to send traffic into the new 10.0.1.x subnet that we have been talking about, our specific command is as follows:
route add -p 10.0.1.0 mask 255.255.255.0 10.0.0.254 if 4
This command tells the server to add a new persistent route for the 10.0.1.0/24 network, flow this network traffic through the 10.0.0.254 gateway and bind this route to NIC ID 4, which is our internal network interface.
With a multi-homed server, only one NIC will have a Default Gateway. Therefore, any subnets that we need to access through the other interfaces have to be specifically defined. Before we added this new route, the server was completely unable to contact the 10.0.1.x network. This is because the routing table did not have any information about this subnet, so any traffic trying to get there was being sent out the Default Gateway, which is on the External NIC plugged into the Internet. By adding a static route to our server, we have now defined a routing path for the server to take whenever it has traffic that needs to get to 10.0.1.x.
If you have many subnets in your network, you may be able to cover them all with a blanket route statement. A blanket route is also known as an aggregate or supernet route. This could save you the time of having to set up a new route statement for each and every one of your networks. For example, if we had many 10.something networks and we wanted to flow all of them through our Internal NIC, we could do that with a single route statement, as follows:
Route add -p 10.0.0.0 mask 255.0.0.0 10.0.0.254 if 4
This route would send any 10.x.x.x traffic through the Internal NIC. Whether you blanket your routes like this or set each one up individually doesn't make a difference to the server as long as its routing table contains information about where to send the packets that it needs to process.