Internet Connection Sharing on Windows 2000
Internet Connection Sharing (ICS) first appeared in Windows 98 and was carried forward into Windows 2000 Professional and Server editions. The goal of the feature is simple: let a single machine with an external IP address forward that connection to a handful of local computers without the need for a dedicated router or firewall appliance. Because Windows 2000 was designed for small offices, the implementation of ICS reflects that target market. It works best with a modest number of clients - typically a dozen or so - and is not meant for large, multi‑site enterprises that need granular control over routing, QoS, or security policies.
When you enable IIS on a Windows 2000 box, the system takes on the role of a Network Address Translation (NAT) server. NAT rewrites the source IP address of outgoing packets from each internal client to match the public address of the host. On the return path, the NAT table maps incoming packets back to the correct internal machine using the destination port that was allocated when the original request left. In practice, the host’s “public” interface will usually be the modem, DSL, or cable connection that receives the real IP from your ISP, while the “private” interface is typically an Ethernet adapter wired to a local switch or hub.
The internal network is usually assigned a private address space such as 192.168.0.0/24. The Windows 2000 machine runs a tiny DHCP server that hands out IP addresses in that subnet, sets 192.168.0.1 as the default gateway, and supplies the DNS servers that the clients will use. If the DNS servers are not provided by the ISP, the same host can act as a DNS proxy: it forwards hostname queries to the upstream DNS, caches the responses, and returns them to the clients. This keeps the configuration lightweight while ensuring that the network still has name resolution.
Configuring the feature is straightforward but requires at least two physical interfaces. If you only have one network card, you can still run the host as a modem gateway. The “Dial-up Networking” connection you use to reach the Internet is the one that gets shared. Right‑click the connection, choose Properties, then click the Sharing tab. Tick the “Allow other network users to connect through this computer’s Internet connection” box. An optional checkbox lets you enable on‑demand dialing; the host will automatically dial when a local client attempts to access the Internet. This feature is handy for conserving bandwidth and reducing the cost of a long‑distance line, but it does add a bit of latency for the first request.
By default, Windows 2000 blocks inbound connections that come from the Internet into the local network. That default firewall stance protects the clients from unsolicited traffic. However, you can open ports for services you want to expose - FTP, SMTP, HTTP, or any custom application. Under the Sharing tab, click Settings and you will see a list of common ports that can be enabled. For each port you enable, you can specify which internal host the traffic should be forwarded to. The port mapping is a simple 1:1 rule: incoming packets on the external interface with a specific port number are forwarded to the IP and port on the private side. When you finish, hit Apply.
Before you enable the host’s DHCP server, make sure there are no other DHCP servers on the local network. Two servers will compete to assign addresses, and the result is a cascade of misconfigured clients that keep dropping out. If you need a dedicated DHCP appliance - for example, if you run a VoIP system that requires specific options - disable the built‑in DHCP or reserve a separate subnet for the DHCP appliance.
After the configuration steps, test connectivity from a client: ping the default gateway, verify that DNS resolution works, and open a browser to an external site. If you enabled on‑demand dialing, you may see a prompt that the host is going to dial. Once the connection is established, the client should be able to reach the Internet. A quick way to confirm that NAT is operating is to check the host’s “Network Connections” window: the shared connection will have a little icon indicating that it is shared.
Because Windows 2000 was shipped before the widespread adoption of 64‑bit processors and high‑capacity network cards, performance can lag when dozens of clients generate heavy traffic. Keep the client count low, or consider a dedicated router for larger deployments. Still, for a home office or a small branch office with a few machines, Windows 2000’s built‑in sharing provides a quick and cost‑effective solution.
Routing and Remote Access: NAT for Windows 2000 Server
While the built‑in Internet Connection Sharing feature offers a lightweight NAT implementation, Windows 2000 Server ships a more advanced NAT service within Routing and Remote Access (RRAS). The core idea is identical - translate internal private IP addresses into a single public address - but the server exposes a richer set of features that make it suitable for medium‑size networks and service providers alike.
To bring the NAT feature online, open the RRAS console, right‑click the server name, and select “New Routing Protocols.” From the list that appears, choose NAT and confirm. The protocol will appear in the tree as a child node. Right‑click the NAT node, choose Properties, and the NAT configuration wizard will launch. The first page asks whether you want to act as a DHCP server for the local network. If your network already has a DHCP appliance, leave this unchecked; if not, you can let RRAS issue addresses. The default address range is 192.168.0.0/24, but you can choose any private range that matches your LAN layout.
On the next screen you specify the public interface - the interface that connects to the ISP. This is the interface that holds the real, routable IP address. The private interface is the one that connects to the local network, often a LAN port on a switch or a dedicated Ethernet adapter. After you designate these, the wizard will install a NAT table that keeps a running map of translation entries. When a client on the LAN sends traffic to an external host, RRAS records the client’s source IP and port, rewrites the packet to use the public IP and a fresh port, and sends it out. When the reply comes back, RRAS looks up the port mapping and forwards the packet to the original client.
RRAS also gives you the ability to perform static NAT, translating specific internal addresses to fixed external ones. This is useful for servers that must remain reachable from the Internet under a known address. In the NAT properties, click the “Static NAT” tab and add a rule. Enter the internal IP, the external IP you want to map it to, and optionally set the ports. RRAS will then allocate those ports on the public interface and forward any incoming traffic to the specified internal host.
Beyond basic address translation, RRAS supports NAT over a demand‑dial connection. If your WAN interface is a modem or a dial‑up link, RRAS can automatically dial whenever traffic from the LAN needs to go out. In the NAT properties, tick “Enable NAT over dial‑up connection” and choose the dial‑up interface. You can also configure the same on-demand dialing options that you used for home‑share. This gives you a simple way to keep a single line for both office phones and Internet traffic, but be aware that the first connection will take a few seconds to establish.
Another advantage of RRAS is the ability to keep a DNS proxy active for the LAN. Under the “General” tab, there is a checkbox for “Use DNS proxy.” When enabled, all DNS queries from the internal network are forwarded to the configured external DNS servers. By default the proxy is off because RRAS assumes you will run a dedicated DNS server on the network. If you do not have one, enabling the proxy can simplify your setup.
Once you have configured NAT, the next step is to test it. Use a client on the LAN to ping an external IP address, like 8.8.8.8, and then look at the RRAS console’s “Event Log” to verify that the packets are being translated. You can also use “netstat” on the server to see the active NAT connections. If everything looks good, open a web browser on the client and navigate to a public site. If the page loads, your NAT is functioning correctly.
RRAS also supports other routing protocols - like RIP, OSPF, or static routes - that can be used in combination with NAT. For example, you might run a separate VPN service on the same server. In that case, you would set up a VPN gateway that uses a different public IP, but still shares the same WAN interface. RRAS will then maintain separate translation tables for each interface, keeping your network traffic separate and secure.
In many organizations, RRAS serves as a transitional technology. You may have two incompatible address ranges across departments - say, one using 10.0.0.0/8 and the other 172.16.0.0/12. By enabling static NAT on the server, you can temporarily allow both subnets to reach the Internet while you migrate all devices to a single, unified scheme. Once the migration is complete, you can disable static NAT and rely on the dynamic table alone.
Overall, RRAS gives Windows 2000 Server a professional‑grade NAT solution that can handle more clients, offers better control over port forwarding, and can be paired with a range of other services such as VPN or routing protocols. For small to medium enterprises that need more than a home‑office setup, the combination of RRAS and NAT is a powerful, cost‑effective alternative to buying a dedicated router.
IAS: Centralizing Authentication, Authorization, and Accounting
Windows 2000’s Internet Authentication Service (IAS) is the enterprise answer to the Remote Access Dial‑in Authentication Service (RADIUS). IAS provides a central AAA engine for all types of remote access - dial‑up, VPN, or even wireless connections that rely on RADIUS for authentication. By pulling all user credentials into one place, you avoid the headache of maintaining separate user databases on every remote access device.
IAS is not installed by default. Open the Control Panel, choose Add or Remove Programs, and then click Add/Remove Windows Components. Find “Internet Authentication Services” on the list and check it. After installation, launch the IAS console from Administrative Tools. The console gives you three primary sections: Clients, Remote Access Logging, and Remote Access Policies. Each of these serves a different purpose but all work together to enforce a consistent authentication model.
The first step is to register the server in Active Directory if you want it to retrieve user accounts from AD. From the IAS console’s Action menu, choose “Register Service in Active Directory.” If the server is already joined to a domain, this will create the necessary security principal. Once registered, IAS will look for user accounts in the domain’s SAM database or, if you’re using AD, the LDAP store.
Next, you need to add the remote access servers that will forward authentication requests to IAS. Open the Clients tab, click New, and enter the hostname or IP address of the device that will act as a RADIUS client. In the same dialog, supply a shared secret - a string that both devices agree upon. This secret protects the authentication packets from tampering. Repeat the process for each remote access server, such as a Cisco router, a Windows 2000 RRAS server, or a VPN appliance.
Once the clients are registered, you can start configuring policies. In the Remote Access Policies section, click New Policy. A wizard guides you through the steps: give the policy a name, choose the type of policy (allow, block, or redirect), set the scope (which users or groups the policy applies to), and then define the rules (like bandwidth limits or connection restrictions). You can enforce a policy that applies only to users in a particular OU, or to those who connect from a specific IP range.
Because IAS can log all authentication attempts, you should enable logging to troubleshoot connectivity issues. In the Remote Access Logging tab, click New Log and specify the events you want to capture - such as successful logons, failed logons, or disconnections. The logs are written to the Windows event log by default, but you can also choose to store them in a file. Logs provide a forensic trail that can help diagnose problems, monitor usage, and satisfy audit requirements.
IAS also supports accounting. By enabling the accounting feature, the server will record details about each session - start time, end time, bytes transferred, and the client that initiated the connection. Accounting records are useful for billing, policy enforcement, or simple usage analysis. To enable accounting, open the IAS properties and check the box for “Enable accounting.” You can then specify a RADIUS accounting server if you wish to forward the data to another system.
When you have multiple IAS servers, redundancy is key for high‑availability environments. Each IAS server can register itself in the domain, and each remote access server can be configured to use both IAS servers as clients. The remote access device will attempt to authenticate against the first server; if that fails, it will fall back to the second. You must ensure that the policies and client configurations are identical on both IAS servers; otherwise, one server might grant access while the other blocks it.
Integrating IAS with existing Windows authentication mechanisms is straightforward. If you’re using the built‑in NTLM or Kerberos protocols, IAS will simply forward the credentials to the domain controller for verification. No additional password synchronization is needed. For VPN connections that rely on smart cards or certificates, IAS can validate the certificate against the domain’s Public Key Infrastructure (PKI).
One common use case is to limit the bandwidth or access times for remote users. With IAS, you can create a policy that allows connections only between 8 a.m. and 6 p.m., or that caps data usage to a certain megabyte limit. Because the policy is enforced by the IAS server, all remote access devices - no matter the vendor - receive the same restrictions.
Overall, IAS gives Windows 2000 a robust, centralized authentication platform that scales from a handful of VPN users to dozens of dial‑up subscribers. By centralizing AAA in one place, you reduce administrative overhead, enforce consistent security policies, and gain visibility into remote access usage.
No comments yet. Be the first to comment!