Introduction
Recently I needed to set up a test network in my office which uses a DSL router to connect to the Internet. The test network needed to be on a different subnet than my office LAN but also needed Internet connectivity. I decided to install Windows Server 2008 on a spare box that had two network interface cards (NICs), install the Routing and Remote Access Service (RRAS) on the box, and use the box as a router between my Workplace and Test networks (see Figure 1).
Figure 1: Using RRAS as a router to connect two subnets
There were basically two ways I could have proceeded. First, I could have configured the RRAS box as an IP router to forward traffic between the two subnets. This would have allowed clients on the Test network to send packets to servers on the Internet, but it wouldn't enable return traffic to be routed back to the client. The reason is that a packet entering the DSL router from the Internet side would be routed to the 172.16.11.0 network and would therefore have no way of reaching a client on the 10.0.0.0 network. A solution to this problem would have been to add a static route to the DSL router that directly forwards all packets having a destination address of 10.0.0.x to the Workplace interface of the RRAS box (172.16.11.220). Then, once a packet bound for 10.0.0.x reaches this interface, the RRAS box would then forward the packet to its other interface (10.0.0.1) and from there the packet would enter the Test network and eventually reach its destination. Unfortunately, I did not have admin access to the DSL router since it was managed by my ISP, so I did not follow this approach.
The other approach I could take, and the one that I actually did choose to implement, was to configure the RRAS box as a Network Address Translation (NAT) router. NAT is an IETF standard that provides a way for translating the IPv4 addresses of computers on one network into IPv4 addresses of computers on a different network. Of course, the DLS router on my Workplace network is also configured as a NAT router, so the result of implementing this approach is what is known as cascaded NAT or double NAT. Internet connectivity works fine through 2 or even 3 cascaded NATs, although a few applications can have problems with this type of network topology. For example, Windows Home Server doesn't seem to like cascaded NATs.
Anyways, after searching online a bit I found that there's lots of confusion around how to set up a two-subnet Internet-connected network like that shown in Figure 1, so I decided to write this article which walks you through the steps of setting up this kind of scenario.
Installing the Server Computer
First, Windows Server 2008 was installed on the double-NIC computer and the IPv4 settings of each NIC was configured as follows:
NIC connected to Test LAN:
- IP address = 10.0.0.1
- Subnet mask = 255.0.0.0
- Default gateway = none
- DNS servers = none
NIC connected to Workplace LAN:
- IP address = 172.16.11.220
- Subnet mask = 255.255.255.0
- Default gateway = 172.16.11.1
- DNS servers = the public IP addresses of my ISP's DNS servers
Note that the NIC connected to the Test LAN (10.0.0.0) should not have a default gateway—see KB 157025 here for an explanation of why multihomed computers (computers connected to multiple networks) should only have one gateway address assigned.
Note also that the NIC connected to the Test LAN has been configured with the IP addresses of public DNS servers. This is not needed in order for the clients on the Test network to access the Internet, but it is needed if you want to be able to access the Internet from the RRAS server itself.
Installing the Client Computers on the Test LAN
Windows 7 was then installed on the client computers, after which their IPv4 settings were configured as follows:
- IP address = 10.0.0.101 (.102, .103, …)
- Subnet mask = 255.0.0.0
- Default gateway = 10.0.0.1 (the near-side interface of the RRAS box)
- DNS servers = the public IP addresses of my ISP's DNS servers
At this point all the "wires" are connected, but if we try to ping the DSL router from a client computer on the Test network, or if we try to traceroute an address on the public Internet from the same client computer, these attempts will fail indicating that the Test network does not yet have Internet connectivity (Figure 2):
Figure 2: Can not ping a public IP address from a client on the Test network
And naturally, if we try to browse the Web from our client machine, this too will fail (Figure 3):
Figure 3: Can not browse the Web
Installing and Configuring RRAS
To enable the client computers on the Test network to access the Internet, we need to install the RRAS role on the server and then configure the server as a NAT router. To install the RRAS role, launch the Add Roles Wizard from Server Manager or OOBE.exe and add the Network Policy and Access Services role (Figure 4):
Figure 4: Installing RRAS step 1
On the next wizard page, select Routing and Remote Access Services to install two role services, Remote Access Service and Routing (Figure 5):
Figure 5: Installing RRAS step 2
Once the wizard finishes, open the Routing and Remote Access console from Administrative Tools, right-click on the local server and select Configure and Enable Routing and remote Access. This launches the Routing and Remote Access Server Setup Wizard; select Network Address Translation (NAT) on the Configuration page of this wizard as shown in Figure 6:
Figure 6: Configuring RRAS for NAT step 1
Next, on the NAT Internet Connection page, we select the network interface that is on the Workplace LAN, which is the "public interface" of the NAT router (see Figure 7)
Figure 7: Configuring RRAS for NAT step 2
The next page asks us whether the NAT router should also provide DHCP and DNS services to the computers on the Test network, which is connected to the "private interface" of the NAT router. Since our client computers all have static IP addresses assigned, we'll choose not to do this (Figure 8):
Figure 8: Configuring RRAS for NAT step 3
Once the wizard finishes, the RRAS service starts up and the service is configured for both IPv4 routing and NAT. To see this, begin by right-clicking on the local server in the RRAS console and selecting Properties. The General tab shows that IPv4 routing has been enabled, which means IPv4 packets can be forwarded from one NIC to the other (Figure 9):
Figure 9: Verifying RRAS configuration step 1
Selecting the NAT node in the RRAS console shows that three network interfaces were created when NAT was configured on the server using the Routing and Remote Access Server Setup Wizard. Figure 10 shows the properties of Local Area Connection, which in this scenario is the network connection to the Test (10.0.0.0) network. Note that NAT considers this network the "private" network, that is, the network "behind" the NAT router:
Figure 10: Verifying RRAS configuration step 2
Figure 11 shows the properties of Local Area Connection 2, which in this scenario is the network connection to the Workplace (172.16.11.0) network. Note that NAT considers this network the "public" network, that is, the network "in front of" (on the Internet side of) the NAT router:
Figure 11: Verifying RRAS configuration step 3
The Internal network interface is also added to the NAT configuration as a private interface.
Testing NAT
At this point NAT has been configured with IP routing, and if I try and ping the DSL router from a client computer on the Test network, or if I try and traceroute from the same client to a server on the public Internet, these attempts should now succeed (Figure 12):
Figure 12: Network connectivity verified between the Test network and the Internet
Likewise, if I try and browse the Web from a client computer on the Test network, this too should succeed (Figure 13):
Figure 13: Computers behind the NAT can browse the Web
I can also monitor NAT activity using the RRAS console. To do this, open the console and select the NAT node and examine the network statistics for Local Area Connection 2 (the "public" or Internet-facing NAT interface) as shown in Figure 14:
Figure 14: Viewing NAT activity
Finally, by right-clicking on this interface and selecting Show Mappings, you can open a separate window that lets you view more details concerning what your NAT router is doing (Figure 15):
Figure 15: Viewing detailed NAT activity
