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 its way to its destination and communications will fail.
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 172.16.97.x network. So, what if our VPN users needed to contact a web server that is sitting on the 172.16.120.x network? Rhe 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 172.16.120.x network, that traffic makes its way to the destination network successfully.
The IP address of that router is 172.16.97.1. If we were able to configure a Default Gateway on the internal NIC of our VPN server, it would be set to 172.16.97.1, 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 must push 172.16.120.x traffic through 172.16.97.1 by using the internal NIC.
The PowerShell command we would run for our example route is as follows:
New-NetRoute -DestinationPrefix '172.16.120.0/24' -InterfaceIndex 4 -NextHop 172.16.97.1The non-PowerShell equivalent would be as follows:
route add -p 172.16.120.0 mask 255.255.255.0 172.16.97.1
if 4You can verify that it was added correctly with the Get-NetRoute command:
