Windows Dialin Client Issues with Subnet Masks, Gateways and Domain Names

Introduction

This document discusses Windows dialin client issues with subnet masks, gateways and domain names.

Prerequisites

Requirements

Ensure that the following have been verified before implementing this procedure:

The router should already be able to accept dialin calls from the Windows client. If you need to configure dialin, refer to the document Configuring an Access Server with PRIs for Incoming Async and ISDN Calls.

Components Used

This document is not restricted to specific software and hardware versions.

Conventions

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Background Information

Windows PCs do not get IP information for their dialup (PPP) adapters using Dynamic Host Configuration Protocol (DHCP). They rely on IP Control Protocol (IPCP) for that purpose. IPCP is the Network Control Protocol (NCP) negotiated for IP at the end of the PPP negotiation. IPCP includes options for negotiating IP addresses and TCP header compression (RFC 1332 ). Microsoft proposed a set of IPCP extensions (RFC 1877 ) to match their implementation of PPP. These extensions define four more IPCP options that can be negotiated:

• Primary Domain Name Server (DNS) Address

• Primary NetBIOS Name Server (NBNS) /Windows Internet Naming Service (WINS) Server Address

• Secondary DNS Server Address

• Secondary NBNS/WINS Server Address

Cisco supports all six options that define all the IP information currently delivered to a Windows PC when using a dialup (PPP) adapter. Refer to the document Configuring WINS, DNS and DHCP on Access Servers for more information on specifying the DNS and WINS server information to the client.

Note: Additional information such as subnet masks, default gateway, and domain name cannot be passed to the client during IPCP negotiation. This is in compliance with RFC 1877: PPP IPCP Extensions for Name Server Addresses .

This document discusses the effects on dialin connections and possible workarounds.

Default Gateway

The NAS and the Windows PC establish a point-to-point connection that runs PPP. The PC acts as a host that does not route IP traffic between multiple interfaces. The PC automatically uses the IP address of the network access server (NAS) (learned during IPCP negotiation) as the default gateway. The PC knows that if the destination address does not match the local address, the packet should be forwarded to the default gateway (NAS) which is always reached through the PPP link.

Microsoft opted for displaying the address (using winipcfg or ipconfig) assigned to the PC as the default gateway address. This is not an issue if IP connectivity through the dial-up adapter is operating correctly.

Note: If the PC client is connected to a LAN and then connects to a NAS (using dial-up networking), then the PC uses the default gateway of the second connection. This can result in lost connectivity to the LAN. Refer to the following Microsoft article for more information: Q128647: Troubleshooting TCP/IP LAN and RAS Routing Issues .

Subnet Masks

The subnet mask is not needed in the point-to-point environment of dial.

Microsoft opted for showing the classful mask for that address as the subnet mask instead of leaving those fields blank. Typically, Windows NT 3.5 displays a subnet mask of 0.0.0.0; NT 3.51 (and higher), as well as Windows 95 and 98, display a classful mask depending on the IP address class, while Win2k and XP display a mask of 255.255.255.255.

Do not worry about this information if IP connectivity through the dial-up adapter is operating correctly.

For more information on subnet masks refer to the document IP Addressing and Subnetting for New Users.

Screen Captures for Various Windows Platforms

The subnet mask and gateway information is obtained when running the Windows IP Configuration program (winipcfg) on Windows 95 and 98 machines, or running the Windows NT Configuration program (ipconfig) on Windows NT, 2000 and XP machines. The following screen captures are shown as samples:

Windows 95:

Windows 98:

Windows NT:

Windows 2000/XP:

Passing Domain Name Information to the Client

Since the domain name information cannot be passed during IPCP, there are three options:

• The user must use the fully qualified domain name (FQDN) of the resource.

• Manually specify the domain name information in the Windows PC TCP/IP properties. This may be the only feasible option for a NAS with a large Windows 95 or 98 client base. Use bootp and DHCP to obtain this information after IPCP negotiation is complete.

• The Windows client sends a DHCP inform packet to the NAS, which then sends back the domain name information. The DHCP functionality can either be on the NAS itself or an external DHCP server. Currently only Windows 2000 and XP clients support sending DHCP inform. Use the Microsoft website to verify this.

Network Diagram

Manually Specifying a Domain Name on the Windows Client

Configure the domain name within the TCP/IP properties of the client. Refer to the following Microsoft article for more information: Q200211-DUN Clients Do Not Receive DNS Domain Name over RAS/RRAS .

Some Microsoft operating systems (for example, Windows 95 and 98) may not support obtaining domain names from the NAS through DHCP inform. Hence, manually specifying the domain name on the client may be the only viable option. However, we recommend that you refer to the Microsoft website to check whether that functionality is included in the Windows OS version you use.

Using bootp and DHCP to Obtain Domain Information

The router can send additional information to the dialup client using bootp (RFC 1533 ) after IPCP negotiation is complete.

The Windows 2000 or XP client sends a DHCP inform (option 15) packet to the NAS. The NAS then responds with the domain name information. The DHCP/bootp functionality can either be on the NAS itself or on an external DHCP server.

Windows Client Configuration

Windows 2000 and XP clients can send the DHCP inform packet after some changes to the registry. Refer to the following Microsoft article for more information on the client configuration: Q312468-How to Request Additional DHCP Options from a DHCP Server .

We strongly recommend that you verify the client configuration procedure on the Microsoft website prior to making any changes on the Client PC.

Warning: Modifying the Windows registry should only be attempted by experienced system administrators because mistakes can render the system unbootable. Refer to the Microsoft website for appropriate precautions.

Using DHCP on the NAS

To configure DHCP on the NAS refer to the following documents:

• Using the Cisco IOS DHCP Server on Access Servers

• Cisco IOS DHCP Server

• Dynamically Configuring DHCP Server Options

You can specify the domain name that is to be provided to the client using the command domain-name within the dhcp pool configuration. The IOS DHCP feature was introduced in Cisco IOS® Software Release 12.0(1)T.

Using an External DHCP Server

You can use an external DHCP server instead to supply the neccessary domain-name information to the client using bootp. Perform the following steps:

• Configure the DHCP server with the domain name attribute. Refer to the DHCP server documentation for more information on specifying this option.

• Configure the command ip helper-address address on the the Group-Async interface (for modems), or the Serial x:23 (d-channel)or Dialer interface (whichever controls the call) for ISDN calls as appropriate. The address should specify the IP address of the DHCP server that the bootp request is to be forwarded to.

Related Information

• Access Technology Support Pages
• Tools and Utilities - Cisco Systems
• Configuring WINS, DNS and DHCP on Access Servers
• Using the Cisco IOS DHCP Server on Access Servers
• Cisco IOS DHCP Server
• Dynamically Configuring DHCP Server Options
• Technical Support - Cisco Systems