Something that I don’t hear a lot about these days is the Windows Routing and Remote Access Service (RRAS). I remember back in the “olden days” when we used to use RRAS for all sorts of things – LAN router, outbound NAT server and reverse NAT server. I don’t do that so much anymore because I’ve been using ISA or TMG firewalls for the last decade, and the ISA or TMG firewall is much more flexible than RRAS.
However, depending on your situation, there might still be times when you’d want to use RRAS. Maybe you need a quick and easy way to publish a service on your intranet and you don’t have time to figure out how to do it on the firewall. OK, that’s a pretty unlikely scenario. A more realistic situation in today’s economy: Maybe you’re on a tight budget and can’t afford to spend more money for the TMG product. Or how about when you want to test things in a virtual environment? It’s a lot easier to use Windows RRAS in a virtual environment than many other options, so why not take advantage of it?
Also, if you’re new to Windows, you might not even know about the RRAS service and some of the things it can do. If this is your first time hearing about RRAS, then I think you’ll be pleasantly surprised at all you can do with it. And it’s built into Windows Server 2008 R2, so you don’t have to spring for another program.
In this article, we’ll check out the reverse NAT feature in Windows Server 2008 R2 RRAS. Reverse NAT allows you to publish services on the intranet to the Internet. The reason we call it reverse NAT is because the client side of the connection is on the non-NATed side of the RRAS server. What we do with reverse NAT is map an IP address on the external interface of the RRAS server to an IP address on the intranet, for the protocol that you want to allow to communicate.
For example, suppose you have a web server on your intranet that you want to make available to users outside the intranet. A quick and dirty way to do this is to set up a NAT server and use reverse NAT. You configure the NAT server to accept connections on a specific IP address and port number (TCP or UDP; in the case of the generic web server, it would normally be TCP port 80) and then forward those connections to the web server on the same port (TCP port 80). You could even do something called “port redirection” and forward the connection to a different port other than the port on which the connection was received. For example, you publish your web server so that external users use TCP port 80 to connect to the NAT server, but then the web server accepts the forwarded connections on another port, such as TCP port 81. This is one method that can be used to enable you to host multiple web sites on the same web server.
In this example of how to configure the Windows Server 2008 R2 RRAS reverse NAT, I’m going to take advantage of a project that my husband, Tom Shinder, is spearheading along with Joseph Davies at Microsoft. This project is the “Test Lab Series” and you can learn more about the Test Lab concept on Tom’s blog. Something that all the Test Labs have in common is the “Base Configuration”. We will use the Base Configuration in this article since it creates a nice, standard Test Lab environment on which we can build other articles and demonstrations.
The first thing you should do to complete the exercises described in this article is build out the Base Configuration, which you can find at here.
After you build out that Base Configuration, you can snapshot the virtual machines that participate in the Base Configuration. That enables you to return to the Base Configuration to start a new Test Lab. It’s a very nice concept and I wish I’d had something like this years ago because it really saves a lot of time if you do frequent testing.
After you build the base configuration, log on to EDGE1 as CORP\User1. In the Initial Configuration Talks window, click the Add roles link as seen in Figure 1 below.
On the Before You Begin page, shown in Figure 2, click Next.
On the Select Server Roles page, shown in Figure 3, put a checkmark in the Network Policy and Access Services checkbox and click Next.
On the Network Policy and Access Services page, shown in Figure 4, click Next.
On the Select Role Services page, shown in Figure 5, put a checkmark in the Routing and Remote Access Services checkbox. Note that this will also automatically put checkmarks in the Remote Access Service and Routing checkboxes. Click Next.
On the Confirm Installation Selections page, shown in Figure 6, click Install.
On the Installation Results page, shown in Figure 7, click Close.
Now that the RRAS service is installed, you can turn it on. By default, RRAS is not enabled after installation. During the enabling process, you tell the RRAS wizard which roles you want RRAS to perform. To get this started, click Start and point to Administrative Tools and click Routing and Remote Access, as shown in Figure 8.
In the Routing and Remote Access console, shown in Figure 9, right click the EDGE1 (local) entry in the left pane of the console. Click Configure and Enable Routing and Remote Access.
Click Next on the Welcome to the Routing and Remote Access Server Setup Wizard page, shown in Figure 10.
On the Configuration page, shown in Figure 11, you have a number of options. Some of them allow you to configure the server as a remote access VPN server or site to site VPN server. In this example, we want to configure EDGE1 as a reverse NAT server. To do that, select the Network address translation (NAT) option and then click Next.
On the NAT Internet Connection page, shown in Figure 12, select the Use this public interface to connect to the Internet option and then select the Internet Network Interface. Click Next.
On the Completing the Routing and Remote Access Server Setup Wizard page, shown in Figure 13, click Finish.
In the left pane of the console, expand the EDGE1 (local)\IPv4 node and then click on the NAT node. In the right pane of the console, right click on the Internet interface and click Properties, as shown in Figure 14.
In the Internet Properties dialog box, click on the NAT tab, as shown in Figure 15. On the NAT tab, confirm that the Public interface connected to the Internet is selected and that there is a checkmark in the Enable NAT on this interface checkbox.
On the Address Pool tab, shown in Figure 16, you can add all the addresses that are bound to the external interface. Since there are two addresses bound to the external interface of EDGE1, we can add both of those addresses here. Click the Add button. In the Add Address Pool dialog box, enter the first address in the pool in the Start address and the last address in the pool in the End address. Enter the subnet mask in the Mask text box. In this example, the Start address is 188.8.131.52 and the End address is 184.108.40.206. The subnet mask is 255.255.255.0. Click OK in the Add Address Pool dialog box.
You can see the addresses you added now on the Address Pool tab, as shown in Figure 17. Notice the Reservations button. You can use this button to reserve an address on the external interface of the NAT server and forward all traffic from that address to a server on the intranet. You would do this if you wanted to allow all traffic to the server, and not limit the traffic to a specific protocol.
Click on the Services and Ports tab, shown in Figure 18, and you can see a list of the protocols that you can publish through the NAT server. Most of these protocols are “simple” protocols, in that they require a single primary connection. If you want to use a protocol that has multiple primary connections, or requires secondary connections back to the client on the Internet, then you will need a NAT editor. The RRAS NAT server includes several NAT editors to support complex protocols. One example is the FTP NAT editor.
Select the Web Server (HTTP) service and then put a checkmark in its checkbox.
This brings up the Edit Service dialog box that’s shown in Figure 19. In the Public address frame, select the On this address pool entry and enter 220.127.116.11 in the text box. In the Private address text box, enter the IP address of APP1, which is 10.0.0.3. Click OK.
Click OK in the Internet Properties dialog box, shown in Figure 20. At this point, the Windows Server 2008 R2 RRAS server is ready to accept connections from Internet hosts at IP address 18.104.22.168 on TCP port 80 and forward those connections to APP1 on the intranet, which is listening for incoming web connections on IP address 10.0.0.3 on TCP port 80.
Now let’s test it out! Move CLIENT1 to the Internet subnet (one of the three subnets in the Base Configuration). Open Internet Explorer and in the address bar enter http://edge1.contoso.com. This is the address you configured on the DNS server on INET1 in the base configuration which maps to the IP address 22.214.171.124 on EDGE1. Press ENTER and bang! There’s the default Web site on APP1, as shown in Figure 21. Now that was pretty easy, wasn’t it?
Click on the NAT node in the left pane of the console. In the right pane of the console, right click Internet and click Show Mappings. Here you will find some interesting and helpful information about mappings used on the Internet Interface for forward and reverse NAT connections. You also can see in the right pane of the console and number of statistics, such as Total mappings, Inbound packets translated, and others, as shown in Figure 22.
The RRAS service can provide you with some quick and dirty routing and remote access services in a number of scenarios. While the RRAS NAT service doesn’t provide services equivalent to an advanced firewall such as TMG or ISA firewall, it can be useful in a number of scenarios, especially those where you might need to do some testing in a virtual environment. You can even use it in a production environment, but since the Windows Server 2008 R2 RRAS service doesn’t include advanced connection inspection and flood mitigation protection as the ISA or TMG firewall do, I’d prefer to have a TMG firewall in front of it. But for testing, the RRAS service can’t be beat!
In this article, we went over the reverse NAT capabilities of RRAS. In a future article, we’ll look at some of the VPN capabilities you get right out of the box with Windows Server 2008 R2.