WindowsNetworking.com Monthly Newsletter of September 2008 Sponsored by: GFI
Welcome to the WindowsNetworking.com newsletter by Thomas W Shinder MD, MVP. Each month we will bring you interesting and helpful information on the world of Windows Networking. We want to know what all *you* are interested in hearing about. Please send your suggestions for future newsletter content to: email@example.com
The NAT Service provided with Windows Server allows you to connect your internal network that uses private IP addresses to the Internet. The NAT Server intercepts requests to Internet hosts and replaces that source header information on the IP packets so that the NAT Server's external interface is seen as the source of the message sent to Internet hosts. When the Internet host returns the message, the NAT Server checks its "NAT Table" and returns the response to the internal host that issued the request.
Actually, the Windows Server NAT server is a Address and Port translator, because the NAT Server not only changes the source IP address in the IP header, but also changes the source port in the TCP or UDP header. Keep this in mind at your next MCSE cocktail party.
Advanced NAT Features
Not only does NAT allow you to access to Internet servers, but you can also use it provide Internet users access to your internal servers. In this way, you are performing "reverse NAT". The Internet user's public IP address is translated to the private IP address on the internal interface of the NAT Server, and the request is forwarded to the internal server on the private network using the private IP address.
You can also configure the NAT Server to support network applications that must use a predefined response port on the NAT Server. Many Internet games require that the Internet server be able to send responses back to a predefined port number or range of port numbers, rather than the dynamically assigned port number that NAT assigns for response ports for outbound requests.
The Address Pool
After you have configured the internal and external interfaces that will be used by the NAT Server, right click on the external interface and click on the Properties command. There you will see three tabs: General, Address Pool and Special Ports. Click on the Address Pool tab.
You might have wondered what the heck this is for, since the Microsoft documentation is clear as mud regarding its functionality. Actually, it's really simple. If you have a pile of IP addresses assigned to you by your ISP, you can allow the NAT Server to use them when performing address translation. You just click the "Add" button and put in the first address, the last address and the subnet mask.
A cool feature is that after you enter the first IP address and then the subnet mask, the dialog box will automatically enter the IP address of the last host in your network ID. You can change the last IP address if you like, as you don't have to give it all of the IP addresses on your subnet.
You don't have to have a pool of IP addresses to use NAT, but if you do, you can take advantage of this feature.
The NAT Server will use each of these addresses you include in the address pool as part of its address translations scheme. For example, suppose we included the following public addresses in our pool:
Internal computers will be assigned these public IP addresses in succession. The first internal host to make a request would use 220.127.116.11, the second internal host would use 18.104.22.168 and the third internal host request would use 22.214.171.124. If a fourth internal host were to make a request, and the entries for the first and second hadn't timed out of the NAT table, then the 126.96.36.199 address would be used for the fourth and subsequent requests. This makes the address translation process a bit quicker and more efficient.
Reserving Address Pool Entries
You can even reserve IP addresses in your pool to be used by a particular host on your internal network. For example, suppose you have an internal network host, 192.168.1.10, and you always want that host to use the external IP address 188.8.131.52. That internal host will have an exclusive priority over that public IP address, and it can't be used by other machines in the network address translation process. You can also allow all inbound connections to that IP address to be forwarded to that internal host by checking the "Allow incoming sessions to this address" checkbox.
Reservations can be added by clicking on the Reservations button.
This is very cool, since if you have an email server on your internal network and its IP address is 192.168.10, you can instruct NAT for forward all requests to 184.108.40.206 to this internal email server. If the request is to port 25, the SMTP Server service on that computer will accept the request and also send out messages via the same public IP address. This feature also allows an internal client exclusive access to a particular public address, and therefore doesn't "compete" with other internal hosts for external address mappings, which can make translation a bit snappier.
Add Special Ports
However, you might want more control over which packets are sent to an internal network computer. In the previous example, all packets send to 220.127.116.11 will be forwarded to the internal email server. You probably don't want that; you just want packets with a destination port of 25 forwarded to the email server. You don't want packets to other destination ports sent to it.
In this case, rather than reserving an IP address, you can add a "Special Port". Just click on the Special Ports tab and select either the TCP or UDP transport protocol and then click Add.
You can then add the specific address pool entry, the incoming port, the private IP address used by the server, and the outgoing port. Note that before you can assign a Special Port, you must have IP addresses in your address pool. If your external interface is using a dynamically assigned IP address, you're outta luck.
Many people wonder what the heck the "Incoming Port" and the "Outgoing Port" entries mean. The incoming port is the destination port number included in the request from the Internet user, and the outgoing port is the destination port number you want the NAT server to use when it sends the request to the internal server from its internal interface.
Typically, these will be the same. For example, if the destination port was 25 in the request from the Internet user, it's meant for an SMTP server on port 25. You'll want the outgoing port to be port 25 too, so that the internal server's SMTP service will pick up the message.
Support for Network Applications
You might run into a situation where you have clients that need to connect to Internet application servers via a specific port number, or the Internet server needs to send its responses back to a hard coded port number. When a client is directly connected to the Internet this isn't a problem, since the client running the application software will automatically open the response port the Internet application is expecting.
However, as we've noted earlier, the NAT Server performs port translation, which means that it will change the response port (source port) number after the request is received from the internal client. This creates a problem for the Internet server that wants to send its responses to a particular port, since the port number the Internet application server wants to respond to may be used for a dynamic port assignment for another internal host.
To solve this problem, you can reserve port numbers to be used by particular Internet application servers. To do this, you need to right click on the Network Address Translation (NAT) node in the left pane of the RRAS console, then click Properties, and finally click on the Translation tab. You'll see what appears below.
Then click the Applications button and click the Add button and you'll see the following
You need to enter the name of the application (you can name it whatever you like, its for identification purposes only), the Remote server port number which will be the destination port number the application uses to connect to the Internet application server, and then the Incoming response ports which is the port number or numbers to which the Internet application server needs to send its responses. These ports will now be reserved and will not be used as dynamically assigned response ports.
The last issue weíll cover is the Name Resolution tab on the NAT Serverís Properties sheet.
Note that you do not need to use the NAT Server to perform name resolution for your network. If you have an internal DNS Server that is configured to use your ISP's DNS Server as a forwarder, then you do not need to configure the NAT Server to perform DNS resolution for your internal network clients.
If you donít have an internal DNS Server to perform Internet name resolution for you, then you should configure the NAT Server to act as a DNS Proxy. When a network client makes a name resolution request, the NAT Server will resolve the name on the behalf of the client using the DNS Server settings you have configured for the NAT Server's external interface.
If you are using a demand-dial interface to access the Internet and you want the NAT Server to resolve host names for you, then you should allow it to Connect to the public network when a name needs to be resolved and then select the name of the demand-dial interface you configured.
I'd like to add one last word on name resolution. You probably have read that the NAT Server will perform NetBIOS name resolution by acting as a WINS proxy. Note that the machine is not a WINS Proxy Agent, which is an entirely different animal. The thing is, you don't need NetBIOS name resolution for Internet hosts, but you do need it for internal network hosts. The WINS Proxy function will use the WINS server configured on the internal interface to resolve NetBIOS names.
The Windows Server NAT Server is really cool. You can use it to allow your internal network clients that use private IP address to access resources on the public Internet. The Windows Server NAT Server can also be configured with a pool of IP addresses and translate requests by using all the IP addresses you've made available in the address pool.
The NAT Server also allows for reverse NAT, so that Internet users can access resources on your internal network. You can configure NAT for forward all requests to a particular external address to a single internal host, or you can fine tune the process by using "Special Ports" so that only requests with a particular destination port number are forwarded to a particular internal host.
Finally, you can configure the NAT Server to reserve certain ports that are required for Internet application servers that need to respond to a dedicated set of port numbers. This prevents the NAT Server from dynamically allocating these port numbers to requests made to other servers.
3. WindowsNetworking.com Articles of Interest
The ability to quickly and efficiently distribute digital certificates is mandatory on networks of all sizes. You need to be able to assign servers certificates so that they can authenticate themselves to users, and you need to be able to assign client operating systems certificates so that they can authenticate themselves to servers. Also, you may want to assign users certificates to take leverage the major security advantages of User Certificate Authentication (sometimes referred to as Client Certificate authentication).
The problem is that certificate deployment can be tedious if you choose a manual approach. What's the solution? Autoenrollment! To get your certificate autoenrollment process up and running quickly, check out this checklist for configuring certificate autoenrollment using Windows Server.
Dear Dr. Tom,
I need to join a Windows Vista Machine on one subnet to a Windows 2008 AD domain on a different subnet over a remote access VPN connection. Any ideas on how to do this? How does the Vista machine know how to get the DC on the different subnet? Much appreciated for any help. - Chris
Excellent question, especially in these days of VPN and branch office deployments. The primary issue you need to deal with is the DNS server. The Vista client needs access to the appropriate DNS records to join the Active Directory domain. Another option is to use WINS, as the WINS entry for the PDC emulator will allow your downlevel clients to join your domain. However, since you don't mention any need for downlevel client support, you probably don't need WINS, as the days of NetBIOS applications are coming to an end.
What you need to do is create the VPN connectoid. After you create the connectoid, connect to the VPN server. If the VPN server was configured correctly, it will assign your machine an address for a DNS server that has knowledge of your Active Directory. Some people have noticed the client won't use the VPN assigned DNS server address the first time you connect, so disconnect from the VPN and connect again. At this point you would be using the DNS server assigned by the VPN server (you can confirm this by using nslookup queries). Now join the Windows Vista client to the domain. You'll need to present domain admin credentials. You should log on via dial-up networking when you restart the computer. Note that making VPN clients members of a domain that they can't reach directly, or via a router or VPN gateway, is generally not too helpful, since the machine can't communicate with domain controllers during log on (because the VPN link is not established). However, if you "log on using dial up networking", you can get around some of these issues. Have fun! - Tom.
Got a question for Dr. Tom? Send it to firstname.lastname@example.org.