Using Windows Server as a NAT Router


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


Conclusion


By using the Network Address Translation and IP routing capabilities of the RRAS role of Windows Server 2008, you can easily set up a separate test subnet on your network and ensure that computers on this test subnet have access to the Internet. This article has walked you through how to set this up step by step.

22 thoughts on “Using Windows Server as a NAT Router”

  1. Ganesh Avasthi

    i am configuring NAT in 2012 r2 server in LAB environment. my private computers are able to connect public network & its showing in mapping also, but when someome try to access my internal private computer then mapping table showing inbound packet rejected & not able to connect from outbound to inbound.

  2. This article could be the answer to a problem I am about to encounter on my own test network. I will try this out asap.

    Good work.

  3. In case anyone else can benefit from this, if you want to have a topology exactly as is what is in the diagram in the article, you can forgo NAT on your RRAS server, and just stick with LAN routing. Everything else the same, no need to manually add static routes, and if you want to enable VPN (i.e. check the “IPv4 remote access server” within the main RRAS properties), just do it and everything is still fine.

    Mitch Tulloch’s bidirectional inbound NAT link is very confusing, even difficult to navigate. But if you don’t actually need NAT for the systems on the test network (ask yourself why you need it), just don’t use NAT, stick with LAN routing, which works both ways, or between both NICs on the RRAS server.

    The quickest way to accomplish this, is to just right click NAT under RRAS -> IPv4 -> NAT, and choose Delete. It’s instant and solves the issue of clients in regular LAN (172.) accessing clients in test LAN (10.). You still need to use a static route on either the main internet router, or on regular LAN clients, so they know to go to RRAS’ 172. NIC to access 10.X.X.X hosts.

  4. Dear Mitch, please allow me to edit my words about your bidirectional inbound NAT link. It reads way more offensively than I intended. I just wanted to say, it’s high level, and another (easier) option is to forgo NAT, which is likely not needed in the many cases where people are setting up RRAS for a test network. Sorry if I offended you, it wasn’t meant that way.

    1. No problem Jeremy and thanks for your earlier comment. This is a very old article and I my goal in walking readers through the process was mostly about helping them understand what happens under the hood with RRAS for this scenario. Your procedure is much simpler though 🙂

    2. Hi Jeremy,
      I tried to implement the bidirectional communication between the private LAN (10.0.0.x) and workspace LAN (192.168.137.x) by following your advice of “just delete away the NAT”.
      However, this does not work. The client machines on workspace LAN still unable to ping the client machines on private LAN. Worst still, my client machines on private LAN failed to have internet connection and failed to be able to ping machine on workspace LAN; which previously I am able to do so after followed the instruction from Mitch Tulloch in the article above through the use of NAT.
      I noticed that you mentioned in your message above that :”You still need to use a static route on either the main internet router, or on regular LAN clients, so they know to go to RRAS’ 172. NIC to access 10.X.X.X hosts.”. How is this implemented? Appreciate if you could illustrate in detail……

  5. Joseph Whitehead

    It seems all (almost?) the NAT guides for RRAS assume you already had DHCP on that server. Just a reminder that you’ll need to also install the “DHCP” role. Luckily, it’s even easier to setup than NAT. 🙂

  6. Hi Jeremy,

    I tried to implement the bidirectional communication between the private LAN (10.0.0.x) and workspace LAN (192.168.137.x) by following your advice of “just delete away the NAT”.

    However, this does not work. The client machines on workspace LAN still unable to ping the client machines on private LAN. Worst still, my client machines on private LAN failed to have internet connection and failed to be able to ping machine on workspace LAN; which previously I am able to do so after followed the instruction from Mitch Tulloch in the article above through the use of NAT.

    I noticed that you mentioned in your message above that :”You still need to use a static route on either the main internet router, or on regular LAN clients, so they know to go to RRAS’ 172. NIC to access 10.X.X.X hosts.”. How is this implemented? Appreciate if you could illustrate in detail……

  7. Hi
    I started Microsoft service nat on Windows Server 2016, along with a
    service dhcp and dns default
    Normally working
    When I define one ip address pool on nat ،It does not work service nat but if remove pool ip its normally working

  8. Hi, I have a problem I have defined subnets for my access to my internal network. my question is how to block the internet to some pc? now all have internet and all can communicate to the internal network but I need to block some clients from the internet. my server consists of 3 network cards 1.- which comes from my T1, 2.- local network, 3.- internet modem everything the server does through the RRAS.
    my widows is 2008 Server R2, with internal segment
    Server
    192.16.254.1 192.16.254.20
    255.255.255.0 255.255.255.0
    gateway 192.16.254.1
    DNS 192.16.254.1
    Thank you.

  9. I know this article was written a decade ago but it still works! There’s one gotcha though, everyone reading this article should be aware of. Mitch suggested that you should add the external DNS server’s IP address as the DNS address on all your machines (via DHCP scope options). The unseen problem with doing this is, your internal name resolutions will also start flowing outside and thus cause a lot of issues which might take people a long time to figure out why they’re happening. The correct way to do this is to add the external DNS server’s IP (which could be your internet router’s internal IP) as a forwarder in your DNS configuration. That will eliminate the internal name resolution issues while still providing internet access to all your machines. Hope this helps someone! 🙂

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top