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:
