A service first provided by Microsoft in its Windows 98 operating system, Internet Connection sharing is meant to allow a single Internet connection to be shared amongst multiple computers on a small network with minimal configuration. In Windows 2000, ICS is implemented via the actual sharing of a network interface, which has a real’ IP address, either via a dial-up or fixed network connection. It is important to remember that ICS (which is available in both Windows 2000 Professional and Server) is mainly meant as a solution for small and home offices, and not larger enterprise environments.
How ICS actually works is quite simple. The machine on which ICS is configured is actually acting as a Network Address Translation (NAT) server. In a nutshell, Network Address Translation is usually used to translate between two connected ranges of IP addresses, usually one that is using a public IP address, and the other which is using a private address range. The external’ interface has a real IP address, and the internal interface is given the private address 192.168.0.1. The system also acts as a sort of mini DHCP server, handing out IP addresses in the 192.168.0.0/24 range to clients on the internal network. To that end, clients use the addresses received, pointing to the 192.168.0.1 interface as their default gateway. The ICS system also does a DNS proxy function, meaning that all client hostname resolution requests will be forwarded to the ICS system for resolution via the configured external DNS parameters.
The actual configuration of ICS couldn’t possibly be simpler. The key is to remember that you will require at least two interfaces on the ICS box. This might be accomplished using two network cards, or perhaps a network card and a dial-up connection such as one made via an ISDN adapter or analog modem. Remember the connection that you wish to share’ is the one that will have the external IP address. If this is your modem, go into the properties of the connection object that you have created to connect to your ISP and share it as I have outlined below. If it were a second network card, you would access the Sharing tab of the appropriate Local Area Connection, and configure that instead. The sharing of a dial-up connection appears as is shown below:
Note the properties in the screen above. Enabling ICS is as simple as checking a checkbox, but you also have to decide whether or not you wish to enable on-demand dialing, which basically would enable the connection should a client on the external network make a request to an Internet-based resource. What you choose here would depend on the level of control that you wish to have over the Internet connection.
By default, ICS is configured such that all requests made to the external interface for resources inside your network are denied by default. This helps to protect your network from outside users. However, in many cases companies might be hosting FTP or Website internally, which they wish the outside world to be able to access. For these cases, you can configure options in the Settings area, as shown below:
These setting can include standard services such as those shown above (FTP, SMTP, etc), or can include custom applications that you can define on the applications tab. Note that these will allow you to specify an external port that will listen’ for requests on the external interface, and then forward them to the appropriate internal address that you specify, as shown below:
Possibly the single most important thing to remember when running ICS is that all other internal DHCP servers must be removed, since ICS will be handling the DHCP server functionality on the network. Having other DHCP servers present may lead to conflicts.
Network Address Translation
Windows 2000 Server also includes another solution similar to ICS but more robust, in the form of the Network Address Translation protocol in Routing and Remote Access. While it basically consists of the same functional elements as ICS (and works in a very similar manner), NAT has some additional features that may make it a better fit than ICS in some environments.
The idea behind NAT is pretty straightforward. The system requires at least one external public IP address, from which all requests for external resources by clients on the internal network are made. This single IP address appears to be the one originating all requests to other servers on the Internet. In reality, the NAT server is making the requests for internal clients and keeping track of things by holding a table in memory that maps the internal request to an external request. The NAT server maps the port number that the external request was made on to the internal system that made the request (both the internal IP and port number used by the internal client). When the NAT server receives the appropriate response to its request, it looks at the table, sees which port number the reply is coming in on, and forwards the reply to the correct internal client. This setup allows many many computers to easily access the Internet off of only a single external IP address.
Obviously you will need to configure your Windows 2000 Server’s Routing and Remote Access tool to support NAT. This is accomplished by choosing to add a new routing protocol from within the tool, as shown below:
Once added, NAT is configured by accessing its properties. One of the main benefits of NAT is that you can choose whether or not you wish for the services to act as a DHCP server for internal clients. This would allow you to continue using an already established DHCP server to hand out addresses, or use the functionality of NAT to do so. It will also allow NAT to be used as a standard address translation service, perhaps translating between internal public and external public ranges if such an addressing scheme is already in use, or simply to connect two different networks together while gradually moving towards an entirely new addressing scheme. For example, if two companies merged, they might be using incompatible ranges of addresses, with immediate connectivity being a priority. The screenshot below outlines the DHCP functionality that can be configured if required, including exclusions if necessary. Note that by default the private 192.168.0.0 range will be used, unless otherwise specified.
NAT would allow this as an interim solution prior to the reconfiguration of the entire network. Another feature within NAT is the ability to continue to handles DNS resolution requests if required via a DNS proxy function (where the internal clients again forward DNS resolution requests to the NAT server). Note that this ability is turned off by default (as is the address assignment function), but can be configured as required, as shown below, even for demand-dial connections.
Much like ICS, NAT can also be configured to allow external requests to a certain port to be mapped to an internal server, such that a web server or otherwise could be hosted behind the NAT server, on the internal network.
Internet Authentication Service
Windows 2000 implements a powerful centralized authentication, authorizations and accounting service (often referred to as AAA) in the form of IAS, its implementation of the Remote Access Dial-in Authentication Service (RADIUS). Used for both dial-in and VPN connections, IAS allows you to control in a more centralized manner the authentication of users, accounting of their connection start and stop times, as well as a way to centralize the application of remote access policies (authorization).
Not installed by default, IAS must be added via Add/Remove programs in Control Panel, as shown below:
Once installed, IAS is accessed using the associated Internet Authentication Services administrative tool.
Many people get confused about the purpose and configuration of IAS, so lets consider the basics. First of all, a big reason for using IAS is to centralize the authentication requests sent to remote access servers. For example, consider an environment that consists of a variety of remote access solutions (these are sometimes referred to as a NAS, or Network Access Server), such as Windows NT RAS, Windows 2000 RRAS, Cisco routers, various VPN and dial-in hardware solutions, and so forth. Maintaining accounts on those various platforms could be difficult, if not impossible. What RADIUS allows you to do is have all requests from the various remote access servers forwarded to the RADIUS server for authentication instead. As such, it is important to remember that a RADIUS client is actually a remote access server. The remote access server has client connections as well, but these are not RADIUS clients. I repeat, a RADIUS client is a remote access server. The remote access server does not authenticate client requests when RADIUS is used; instead it forwards them to the RADIUS server for processing.
This centralization provides a number of other benefits as well, including the ability to centralize the distribution of remote access policies. Remember that by default, remote access policies are local to the server on which they are created. In instances where you choose to set up a remote access server as a RADIUS client, all remote access policies on the server are ignored in favor of those configured on the RADIUS server. This presents a powerful way to control the application of remote access policy settings, especially in large distributed environments.
The actual configuration of IAS is quite simple, but there are a few things that you will need to be aware of. For starters, if you want a remote access server to act as a RADIUS client, it must be capable of authenticating to RADIUS. Most vendors add this functionality to their remote access servers, since RADIUS is an industry standard. Windows 2000 RRAS can act as a RADIUS client if correctly configured both in the RRAS settings and IAS setting. In RRAS, the setting are configured from the Security tab in the properties of the RRAS server, as shown below:
By default, an RRAS-based server will authenticate to the Windows provide, either Active Directory or the local SAM database, depending on your setup. If RADIUS is chosen, further configuration is required, including the address of the server and a shared secret, which will be used between the RADIUS client and server for authentication purposes.
Simply configuring the RADIUS client is not enough. The settings for the RADIUS server must be configured via IAS, as shown below:
Note the three sections that exist – Clients, Remote Access Logging, and Remote Access Policies. The Clients sections will allow you to add remote access server addresses and the corresponding shared secret that you originally set up. You will need to do this for each and every remote access server that you wish to act as a RADIUS client. The remote access logging pages allows you to configure what type information you wish log (and the associated format), as shown below:
Note that by default, nothing is logged, but recommendations are provided.
The last section allows you to configure the centralized remote access policies that I discussed earlier. These policies are configured and work in exactly the same manner as explained in the earlier remote access article.
You should understand that if you want IAS to be able to access a user’s dial-in properties in Active Directory, you must configure it to do so. This is accomplished choosing Register Service in Active Directory’ from the Action menu of the snap-in (if the server is not a member of an AD domain, this option will be grayed out). Note that IAS will authenticate users against Active Directory or the local SAM database, as applicable. Note also that if you want redundant IAS servers, you should configure them similarly, being sure to copy the remote access policies to the second server, while configuring the RADIUS clients appropriately to account for the second server as well.
First appeared at 2000trainers.com
Dan DiNicolo is a technical trainer, consultant, author, and the managing editor of the free IT learning web site 2000Trainers.com. When he’s not busy traveling the world as an IT volunteer with organizations like Geekcorps, Dan makes his home in the snowy northern backwoods of Canada.
