• Chapter 1. Installing and Configuring Windows Server 2003
  • software development Company Server 2003
  • Chapter 1. Installing and Configuring Windows Server 2003
  • New Features in Windows Server 2003
  • Best Practices
  • Moving Forward
  • Version Comparisons
  • Hardware Recommendations
  • Installation Checklist
  • Functional Overview of Windows Server 2003 Setup
  • Installing Windows Server 2003
  • Post Setup Configurations
  • Functional Description of the Windows Server 2003 Boot Process
  • Correcting Common Setup Problems
  • Chapter 2. Performing Upgrades and Automated Installations
  • New Features in Windows Server 2003
  • NT4 Upgrade Functional Overview
  • Upgrading an NT4 or Windows 2000 Server
  • Automating Windows Server 2003 Deployments
  • Moving Forward
  • Chapter 3. Adding Hardware
  • New Features in Windows Server 2003
  • Functional Description of Windows Server 2003 Architecture
  • Overview of Windows Server 2003 Plug and Play
  • Installing and Configuring Devices
  • Troubleshooting New Devices
  • Moving Forward
  • Chapter 4. Managing NetBIOS Name Resolution
  • New Features in Windows Server 2003
  • Moving Forward
  • Overview of Windows Server 2003 Networking
  • Name Resolution and Network Services
  • Network Diagnostic Utilities
  • Resolving NetBIOS Names Using Broadcasts
  • Resolving NetBIOS Names Using Lmhosts
  • Resolving NetBIOS Names Using WINS
  • Managing WINS
  • Disabling NetBIOS-over-TCP/IP Name Resolution
  • Chapter 5. Managing DNS
  • New Features in Windows Server 2003
  • Configuring a Caching-Only Server
  • Configuring a DNS Server to Use a Forwarder
  • Managing Dynamic DNS
  • Configuring Advanced DNS Server Parameters
  • Examining Zones with Nslookup
  • Command-Line Management of DNS
  • Configuring DHCP to Support DNS
  • Moving Forward
  • Overview of DNS Domain Structure
  • Functional Description of DNS Query Handling
  • Designing DNS Domains
  • Active Directory Integration
  • Configuring DNS Clients
  • Installing and Configuring DNS Servers
  • Configuring Secondary DNS Servers
  • Integrating DNS Zones into Active Directory
  • Chapter 6. Understanding Active Directory Services
  • New Features in Windows Server 2003
  • Active Directory Support Files
  • Active Directory Utilities
  • Bulk Imports and Exports
  • Moving Forward
  • Limitations of Classic NT Security
  • Directory Service Components
  • Brief History of Directory Services
  • X.500 Overview
  • LDAP Information Model
  • LDAP Namespace Structure
  • Active Directory Namespace Structure
  • Active Directory Schema
  • Chapter 7. Managing Active Directory Replication
  • New Features in Windows Server 2003
  • Replication Overview
  • Detailed Replication Transaction Descriptions
  • Designing Site Architectures
  • Configuring Inter-site Replication
  • Controlling Replication Parameters
  • Special Replication Operations
  • Troubleshooting Replication Problems
  • Moving Forward
  • Chapter 8. Designing Windows Server 2003 Domains
  • New Features in Windows Server 2003
  • Design Objectives
  • DNS and Active Directory Namespaces
  • Domain Design Strategies
  • Strategies for OU Design
  • Flexible Single Master Operations
  • Domain Controller Placement
  • Moving Forward
  • Chapter 9. Deploying Windows Server 2003 Domains
  • New Features in Windows Server 2003
  • Preparing for an NT Domain Upgrade
  • In-Place Upgrade of an NT4 Domain
  • In-Place Upgrade of a Windows 2000 Forest
  • Migrating from NT and Windows 2000 Domains to Windows Server 2003
  • Additional Domain Operations
  • Moving Forward
  • Chapter 10. Active Directory Maintenance
  • New Features in Windows Server 2003
  • Loss of a DNS Server
  • Loss of a Domain Controller
  • Loss of Key Replication Components
  • Backing Up the Directory
  • Performing Directory Maintenance
  • Moving Forward
  • Chapter 11. Understanding Network Access Security and Kerberos
  • New Features in Windows Server 2003
  • Windows Server 2003 Security Architecture
  • Security Components
  • Password Security
  • Authentication
  • Analysis of Kerberos Transactions
  • MITv5 Kerberos Interoperability
  • Security Auditing
  • Moving Forward
  • Chapter 12. Managing Group Policies
  • New Features in Windows Server 2003
  • Group Policy Operational Overview
  • Managing Individual Group Policy Types
  • Moving Forward
  • Chapter 13. Managing Active Directory Security
  • New Features in Windows Server 2003
  • Overview of Active Directory Security
  • Using Groups to Manage Active Directory Objects
  • Service Accounts
  • Using the Secondary Logon Service and RunAs
  • Using WMI for Active Directory Event Notification
  • Moving Forward
  • Chapter 14. Configuring Data Storage
  • New Features in Windows Server 2003
  • Functional Description of Windows Server 2003 Data Storage
  • Performing Disk Operations on IA32 Systems
  • Recovering Failed Fault Tolerant Disks
  • Working with GPT Disks
  • Moving Forward
  • Chapter 15. Managing File Systems
  • New Features in Windows Server 2003
  • Overview of Windows Server 2003 File Systems
  • NTFS Attributes
  • Link Tracking Service
  • Reparse Points
  • File System Recovery and Fault Tolerance
  • Quotas
  • File System Operations
  • Moving Forward
  • Chapter 16. Managing Shared Resources
  • New Features in Windows Server 2003
  • Functional Description of Windows Resource Sharing
  • Configuring File Sharing
  • Connecting to Shared Folders
  • Resource Sharing Using the Distributed File System (Dfs)
  • Printer Sharing
  • Configuring Windows Server 2003 Clients to Print
  • Managing Print Services
  • Moving Forward
  • Chapter 17. Managing File Encryption
  • New Features in Windows Server 2003
  • File Encryption Functional Description
  • Certificate Management
  • Encrypted File Recovery
  • Encrypting Server-Based Files
  • EFS File Transactions and WebDAV
  • Special EFS Guidelines
  • EFS Procedures
  • Moving Forward
  • Chapter 18. Managing a Public Key Infrastructure
  • New Features in Windows Server 2003
  • Moving Forward
  • PKI Goals
  • Cryptographic Elements in Windows Server 2003
  • Public/Private Key Services
  • Certificates
  • Certification Authorities
  • Certificate Enrollment
  • Key Archival and Recovery
  • Command-Line PKI Tools
  • Chapter 19. Managing the User Operating Environment
  • New Features in Windows Server 2003
  • Side-by-Side Assemblies
  • User State Migration
  • Managing Folder Redirection
  • Creating and Managing Home Directories
  • Managing Offline Files
  • Managing Servers via Remote Desktop
  • Moving Forward
  • Chapter 20. Managing Remote Access and Internet Routing
  • New Features in Windows Server 2003
  • Configuring a Network Bridge
  • Configuring Virtual Private Network Connections
  • Configuring Internet Authentication Services (IAS)
  • Moving Forward
  • Functional Description of WAN Device Support
  • PPP Authentication
  • NT4 RAS Servers and Active Directory Domains
  • Deploying Smart Cards for Remote Access
  • Installing and Configuring Modems
  • Configuring a Remote Access Server
  • Configuring a Demand-Dial Router
  • Configuring an Internet Gateway Using NAT
  • Chapter 21. Recovering from System Failures
  • New Features in Windows Server 2003
  • Functional Description Ntbackup
  • Backup and Restore Operations
  • Recovering from Blue Screen Stops
  • Using Emergency Management Services (EMS)
  • Using Safe Mode
  • Restoring Functionality with the Last Known Good Configuration
  • Recovery Console
  • Moving Forward
  • Who Should Read This Book
  • Who This Book Is Not For
  • Conventions
  • Acknowledgments
  • About the Author
  • About the Technical Reviewers
  • Index
  • Index A
  • Index B
  • Index C
  • Index D
  • Index E
  • Index F
  • Index G
  • Index H
  • Index I
  • Index J
  • Index K
  • Index L
  • Index M
  • Index N
  • Index O
  • Index P
  • Index Q
  • Index R
  • Index S
  • Index SYMBOL
  • Index T
  • Index U
  • Index V
  • Index W
  • Index X
  • Index Z
  • Preface
  • Previous Section Next Section

    Configuring an Internet Gateway Using NAT

    Figure 20.34 shows a typical SOHO network configuration. In this example, a single server running Windows Server 2003 supports all network services, including acting as a gateway to the Internet.

    Figure 20.34. Typical SOHO network with a Windows Server 2003 server running RRAS as a gateway.

    graphics/20fig34.gif

    You may look at this diagram and wonder why the vendor who set up the system didn't simply use a low-cost SOHO appliance as the gateway. Part of the reason is money. The additional equipment isn't free and many SOHO installations are extremely price sensitive. A better reason, technologically speaking, is the generous feature set supported by Windows Server 2003. This feature set includes a firewall, flexible inbound port forwarding, the ability to have multiple public IP addresses, and virtually unlimited client connections.

    Using a single server for file-and-print and network services isn't the most fault tolerant solution, of course, but small business owners are accustomed to thinking in terms of bottom line rather than business recovery. This same business probably has critical machines on the operations floor and rolling stock in the parking lot that do not have redundancy, either. Most small business owners measure risk against cost and decide to have a single server. You can mitigate the impact of a downed server by designating one or more XP desktops as alternate Internet gateways. An XP desktop functions tolerably well in these circumstances and it only takes a second to make the configuration change as long as you already have a second network adapter in the desktop.

    Setting up a Windows Server 2003 as an Internet gateway involves installing an additional network interface that connects to the Internet (this could be a network cable connected to a cable modem, a DSL adapter, or a demand-dial connection) then configuring the following RRAS components:

    • Routing service

    • Network Address Translation (NAT) service

    • Firewall service

    If the public interface connects to a DSL provider that requires individual connections, setting up the gateway also involves configuring the integrated Point-to-Point Protocol over Ethernet (PPPoE) support in Windows Server 2003. See the previous section, "PPPoE," for details.

    Functional Description of Network Address Translation

    If the server in Figure 20.34 were configured as a standard router, each client in the office would need a public IP address. This presents two problems. One involves security. The clients would be exposed to the Internet where all the bad guys can find them and do nasty things to them.

    The other problem involves architecture. The supply of available IP addresses is dwindling rapidly. IPv6 will alleviate this problem, and the security problem as well, but it will take many years for the deployment of IPv6-capable devices and hosts to reach the point where address availability is not an issue.

    For the time being, NAT solves both problems by a trick that any teenager would love. NAT translates one IP address into another IP address, permitting a client to be something different on a private network and a public network. NAT is documented in RFC 1597, "Address Allocation for Private Internets," and RFC 1631, "Network Address Translation (NAT)."

    Address Mapping

    To take advantage of NAT, you need to deploy IP addresses from one of the reserved ranges set aside for private use. Internet routers are configured to block any traffic from these reserved ranges. They are as follows:

    Class A: 10.0.0.0 to 10.255.255.255

    Class B: 172.16.0.0 to 172.31.255.255

    Class C: 192.168.0.0 to 192.168.255.255

    Broadband Performance

    To get the latest updates on tweaks that can improve performance over broadband connections, visit www.speedguide.net.

    As an administrator thinking about how to implement NAT, you are free to choose any of the private address ranges that fit your needs. The most flexible is the Class A because of the large number of networks and hosts it can support, but the Class C range is simpler to manage for a small network.

    Here's how NAT works. Consider a client on the private side of a NAT device. The client makes an HTTP connection to a web server on the public side. The client sends HTTP traffic to the web server via well-known Transport Control Protocol (TCP) port 80. The client selects an unused TCP port on which to listen for a response. This source port is included in the datagram sent to the web server so the server knows where to reply.

    When the HTTP packet from the client arrives at the NAT device, the NAT device modifies the IP header by substituting its own public IP address for the client's address then sends the packet on its way.

    The web server responds to that IP address, which returns the traffic to the public interface on the NAT device. The NAT service swaps back the client's IP address and sends the packet into the private network where it is routed to the client.

    Port Mapping

    True NAT uses a one-to-one mapping between a private address and a public address. This protects the client's identity, but it does very little to minimize the use of public IP addresses. That is the job of another feature called Port Address Translation, or PAT. The NAT service in Windows Server 2003 implements both NAT and PAT.

    Here's now PAT differs from NAT. When a private client sends traffic to a host on the public side of the NAT device, the NAT device not only substitutes its public IP address, it substitutes a random TCP port number for the port on which the client is listening for a response. It keeps the original IP address and port number in a lookup table.

    When the web server responds, it returns an HTTP packet to the public interface on the NAT device using the number of the substituted port. The NAT device swaps the client's information back into the packet then sends it onto the private network where it is routed to the client.

    So, the difference between NAT and PAT lies in the way they use the public address. With pure NAT, you would need a public address for each client on the private side. With PAT, you essentially multiplex the private clients onto one public IP address.

    Windows Server 2003 RRAS, like most NAT devices, uses a combination of NAT and PAT. You can see the address and port mappings used by the Windows Server 2003 NAT service by opening the RRAS console, right-clicking the NAT interface, and selecting the Show Mappings option.

    If the public interface of the RRAS server has more than one IP address, the NAT service maps private clients one-to-one with the public addresses until it arrives at the last available address. It then shifts to PAT for the remainder of the clients. This is sometimes called NAT overloading. There is no performance difference between NAT and PAT.

    NAT Editors

    In addition to simply translating IP header addresses, NAT may need to peer inside the TCP or User Datagram Protocol (UDP) packet itself to find source IP addresses put there by an application.

    For example, when you ping a host, the ICMP packet contains the IP addresses of the source and destination hosts. The same is true for the FTP port command and other applications. In addition, there are instances when source addressing is used outside of the TCP or UDP payload. This occurs in Point-to-Point Tunneling Protocol (PPTP), where the Generic Routing Encapsulation (GRE) protocol handles IP communication with the TCP and UDP datagrams and their port number tunneled inside the packet. (The embedded IP addresses in L2TP over IPSec are encrypted, making them impervious to NAT translation.) Windows Server 2003 NAT uses information stored in special configuration files called NAT Editors to determine the location of IP address information in an application packet. Each application requires its own NAT Editor. Windows Server 2003 has NAT Editors for FTP, ICMP, and PPTP. NAT Editors are not included for Simple network Management Protocol (SNMP), Lightweight Directory Access Protocol (LDAP), Microsoft COM, and Remote Procedure Call (RPC).

    Inbound Connections Through NAT

    As long as a connection to a public host originates from a client in the private network, the NAT service will permit inbound traffic from the public side. If the connection request originates on the public side, however, NAT blocks the request.

    There may be situations when you want clients on the public side of the NAT to connect to a server on the private side. Linux calls this port forwarding.

    Routing inbound traffic backwards through NAT is a little like taking a guest to a State Department dinner. Admittance is strictly by invitation only. Inbound mapping through NAT is done on a port-by-port basis. For instance, if you have a web server in the private network that you want to make available to public clients, you can configure the NAT router to accept inbound connections directed at port 80 and route them to the selected web server. A user on the public side who points a browser at the IP address of the NAT would see web pages returned by the server on the private side.

    RRAS has two ways to configure port forwarding through NAT. The simplest way is to associate a port on the public side with a server and a port on the private side. This is done using the Services and Ports tab in the Properties window of the public interface. Figure 20.35 shows an example.

    Figure 20.35. Properties window of public NAT interface showing the services that can be configured to map between a public address and a private address.

    graphics/20fig35.gif

    If you want to publish a private web server on the public side, select the Web Server option. This opens an Edit Service window where you can define the private address and ports.

    This one-to-one mapping of external well-known ports to internal servers works fine so long as you have only one server on the private side hosting a particular service. But what if you have three web servers on the private side that you want to publish on the public side? You could use different ports on the public side, but this would require using non-standard ports, which complicates the connection for clients.

    A better solution is to obtain a pool of addresses from your ISP then configure the public interface to use this pool for inbound NAT mapping. You can then select an IP address and port number on the public side to represent each server and service on the private side.

    You can assign addresses to the public interface using the Address Pool tab of the Properties window for the public interface.

    Controlling ICMP Responses

    Internet Control Message Protocol (ICMP) is used for communicating between clients and hosts for a variety of purposes. Unfortunately, bad guys often "Shanghai" this protocol to crash servers or initiate denial-of-service attacks. Windows Server 2003 has a new option for selecting the ICMP message types to which the public interface will respond. The Properties window for the public interface has an ICMP tab that lists the messages and their function. Figure 20.36 shows the selection list.

    Figure 20.36. Public interface Properties window showing the ICMP tab that lists the various messages you can elect to enable or disable.

    graphics/20fig36.gif

    If you have cannot obtain a contiguous set of addresses from your ISP, you can enter the addresses one at a time as separate address ranges with a range of 1 address. There is no need to stop and start the RRAS service after making a new port mapping.

    NAT Deployment Checklist

    Here are the key points to remember about NAT before installing and configuring the service:

    • NAT requires a separate IP network for the local LAN that either uses a private IP address space (preferred) or public addresses that are unique in your organization.

    • NAT maintains a volatile mapping of TCP/UDP ports and private IP addresses. If you down the server, this map is lost and clients must reconnect to the public hosts to get new mappings.

    • NAT can use multiple public IP addresses for inbound port forwarding if you have several servers hosting the same service.

    • If you have a unique application that inserts IP addresses into the payload of a TCP or UDP packet, or puts IP address information into another protocol, you must configure a NAT Editor to translate the addresses properly or the application will not work through NAT.

    • Network clients must be configured to use the NAT router as a gateway to the Internet. This is most easily done using DHCP, but you can manually configure the IP stack on the clients, if you prefer.

    Internet Connection Sharing (ICS)

    Creating an Internet gateway using the NAT service available in RRAS requires some fairly sophisticated skills. You need to know how to set up RRAS as a router, how to configure NAT and the interfaces within NAT, how to set up clients to use the NAT server as a gateway, and how to handle DNS requests from clients on the private side of the NAT server.

    For a small office with a single server running Windows Server 2003, there is a much simpler way to configure the gateway. You can click two selections and restart the clients and call it a day. This convenience comes to you in the form of Internet Connection Sharing, or ICS. ICS is also available in XP desktops, Windows 2000 servers and desktops, Windows ME and Windows 98 Second Edition.

    ICS is enabled via the Network Connections window as an option in the Advanced tab of the Properties window of the public interface (see Figure 20.37).

    Figure 20.37. Properties window of the public interface on a multihomed server showing the ICS and ICF options in the Advanced tab.

    graphics/20fig37.gif

    ICS is a suite of services that automates the creation of an Internet gateway. Here is what happens automatically when you enable ICS on the public interface:

    • The IP address of the private interface is automatically changed to 192.168.0.1. This address cannot be changed, bypassed, or overridden. (There is a Registry hack for ICS in Windows 98/ME, but not for Windows Server 2003/XP.) If you have already configured the network with a different private address, you will have to change your selection.

    • Then, if the public interface is a circuit-switched device, it is reconfigured as a demand-dial router.

    • A small DHCP service is initialized to pass out addresses in the 192.168.0.0/24 network. This service is controlled by the Ipnathlpr.dll. It is not a full-blown installation of DHCP.

    • A small DNS proxy service is installed, also controlled by Ipnathlpr.dll. This proxy passes DNS queries to the DNS server configured on the public interface. This generally comes from the service provider via DHCP.

    Internet Connection Firewall (ICF)

    Although NAT is a key component of a firewall, NAT in and of itself is not a firewall. In other words, NAT takes no active part in blocking traffic directed at ports on the public side of an RRAS server. Microsoft responded to the presence of an integrated firewall in Linux with a new feature in Windows Server 2003 and XP called the Internet Connection Firewall, or ICF.

    Compared to more sophisticated (and costlier) firewall solutions, such as Microsoft's Internet Security and Acceleration (ISA) Server or CheckPoint Firewall, ICF looks relatively pale. It lacks the enterprise controls and extensive reporting you'd expect from an enterprise firewall solution; but for its niche, which is to act as a firewall for ICS, it performs very well.

    ICS and DHCP

    You might be concerned that the indiscriminate use of ICS in your network could result in rogue DHCP servers passing out 192.168 IP addresses. To avoid this, an ICS server or desktop uses DHCPINFORM packets to discover the presence of other DHCP servers on the wire. If it finds any, it disables itself and makes an Event log entry.

    Also, the DHCP feature in ICS does not respond to requests from the DHCP allocator in RRAS. This prevents dial-up clients from obtaining addresses from the ICS server.

    As of this writing, there have been no tactical or strategic weaknesses identified (or at least reported) in ICF. The service lacks many of the features you would expect in a commercial firewall, but as a way of blocking access to the Internet-facing side of a server, it seems to do the trick. With ICF in place, all ports resisted probing by the typical tools used to do such things. For instance, the public interface came up negative when probed by Legion and LanGuard and the ShieldsUp page at the Gibson Research web site, www.grc.com.

    ICF is enabled in one of two ways. If you use NAT, it is an option on the private interface under NAT in the RRAS console. If you use ICS, it is an option on the same properties page where you enable ICS.

    Configuring NAT in RRAS

    Setting up NAT on an Internet gateway is much simpler than configuring a standard routed connection because there is no need for additional services from your ISP. Here is a quick checklist to use for your preparations:

    • If you have a DNS server that is the Start of Authority (SOA) for your public DNS namespace, you'll need to either keep the server in the public network or map port 53 in NAT to point at the DNS server. If you move the DNS server into the private address space and do not map the original address to the public interface for NAT, you will need to contact your ISP or the operator of your top-level domain (TLD) to change the address of the name server at the TLD servers. Do the same for any other servers that are moved to the private side, such as your email server (which uses an MX record in DNS).

    • The gateway needs at least two network interfaces: one for the private side and one for the public side. The public interface can be a circuit-switched interface (modem or ISDN) or a dedicated interface.

    • Do not use a domain controller as a NAT router. You will get erratic results, especially with DNS and LDAP.

    • RRAS must be configured to support routing.

    • The circuit-switched interface, if any, must be configured for demand-dial routing. This is done from the RRAS console by opening the Port Properties window, double-clicking the device to open the Configure Device window, then selecting the Demand-Dial Routing Connections option.

    • Some ISPs have fair use policies barring NAT connections to their systems. Check to make sure so you won't get your service disconnected.

    With these prerequisites in place, you're ready to set up the gateway.

    Configuring NAT and ICF

    Start by making sure that the connection to the Internet at the gateway server is fully functional. Then load interfaces into NAT and configure them as directed in Procedure 20.14.

    Procedure 20.14 Configuring NAT and ICF

    1. Open the Routing and Remote Access console.

    2. Expand the tree under the IP Routing icon to show the Network Address Translation icon.

    3. Right-click the Network Address Translation icon and select NEW INTERFACE from the flyout menu. The New Interface For Network Address Translation window opens.

      Double-click the public interface. A Properties window opens for the interface.

    4. Select the Public Interface radio button then check the Translate TCP/UDP Headers option and the Enable Firewall On This Interface option. Click OK to save the change.

    5. Double-click the private interface. A Properties window opens for the interface. Select the Private Interface radio button and click OK.

    If you use DHCP, change the configuration settings to point your clients at the IP address of the NAT server. If you do not currently use DHCP but would like to start because of NAT, you can simplify your DHCP setup by using the DHCP Allocator in NAT. You can also use NAT to configure a DNS proxy.

    Open the Properties window for the NAT service and select the Address Assignment tab (see Figure 20.38).

    Figure 20.38. NAT properties showing the Address Assignment tab for configuring the DHCP Allocator.

    graphics/20fig38.gif

    The simplest configuration is to check the Automatically Assign checkbox and leave the address range at 192.168.0.0/24. This is the same range that would be allocated by ICS.

    Select the Name Resolution tab and select Resolve IP Addresses for Clients Requesting DNS. This configures NAT to forward DNS requests to the DNS server assigned to the public interface. Make sure one the DNS server is available before you make this change.

    Enabling ICS and ICF

    After verifying that you have a reliable Internet connection on a public interface, enable ICS by following the steps in Procedure 20.15.

    Procedure 20.15 Enabling Internet Connection Sharing and Internet Connection Firewall

    1. Check that no users have open files or connections on the server. This is necessary because the next steps result in a change of the server's private IP address. Use the Computer Management console, Compmgmt.msc, to check for live sessions.

    2. Open the Network Connections window.

    3. Open the Properties window for the public interface.

    4. Select the Advanced tab.

    5. Under Internet Connection Firewall, select the Protect My Computer option.

    6. Under Internet Connection Sharing, select the Allow Other Network Users to Connect option.

    7. Click OK to save the changes. The system presents a warning that the IP address of the local area connection will be changed to 192.168.0.1 and that this may cause loss of connection to the local network. Click Yes to acknowledge the warning and proceed with the ICS installation. The loss of network connection is temporary until the clients acquire a new network address using DHCP.

    It only takes a few seconds for the updates to take effect. Use ipconfig to verify that the IP address of the LAN interface has changed to 192.168.0.1.

    At each DHCP client, do an ipconfig /release and ipconfig /renew (or the winipcfg equivalent for Windows 9x clients) to obtain a new DHCP address in the 192.168 network. Verify with Ping that you can touch the gateway and the Internet from the client. Open Network Connections at an XP desktop and verify that you have an Internet Gateway icon.

    If you are using an ISDN line to connect to the Internet, keep an eye on usage for a while. The ICS features should not keep the line hot, but you never know what the clients might do after they get access to the Internet. Use Network Monitor at the server to sniff for traffic if the line never goes down.

      Previous Section Next Section