Troubleshoot these RAS-breaking DHCP problems

In IS manager at a large organization recently consulted me about a problem with his Windows NT RAS server. He had configured the RAS server to use DHCP to assign IP addresses to RAS clients. The problem was that certain IP addresses that the DHCP service assigned to LAN-based workstations didn't let the workstations communicate with their primary NT server. However, other addresses the DHCP service assigned from the same DHCP scope worked perfectly. I concluded that the only reason the IP addresses didn't work was an IP address conflict. So, if an address conflict was the problem, why didn't the system send notification of the conflict on each conflicting machine?

The problem was that the RAS server was assigning incoming RAS clients IP addresses that other LAN clients were already using. Thus, the problem was indeed the result of an IP address conflict, but it was a conflict that NT can't identify. After some investigation, I discovered that the conflict was between the client workstation that couldn't connect and an IP address that the RAS server had obtained from the DHCP service. The mysterious address was an unexpected NDISWANx adapter binding. (NDISWANx is the name NT gives each RAS-created virtual network adapter. The x variable is the number that represents the relative RAS adapter on the system.) I used Ipconfig to reveal that NT was binding the same DHCP-leased address that the LAN-based workstation received from the DHCP service to the RAS server's NDISWAN adapter. The DHCP Manager showed no evidence of this lease, so DHCP assigned the same address to the LAN-based workstation.

Recreating the DHCP scope and removing and reinstalling the DHCP service didn't solve the problem, but these processes proved that DHCP wasn't the culprit. NT was the malefactor—the OS wrote an incorrect RAS NDISWAN adapter Registry entry on the RAS server. To resolve the conflict, I removed and reinstalled RAS via Control Panel's Network applet and reinstalled the RAS adapters. These actions forced NT to rewrite the Registry entries and bindings for each adapter. This solution worked, and the DHCP Manager correctly listed all IP addresses that were currently leased to clients, including the RAS server and its clients.

This scenario is evidence that NT occasionally writes incorrect network adapter-related Registry settings—particularly RAS NDISWAN adapters' settings. If your RAS server and DHCP service are acting strangely, try removing and reinstalling each of the RAS (i.e., NDISWANx) devices in the Network applet to force NT to rewrite the adapters' Registry settings. If this solution doesn't resolve the conflict, try reinstalling RAS.

In another common DHCP problem, the DHCP server assigns its address to a DHCP client. Any IP address conflict is bad, but a conflict that involves a critical network server can be catastrophic. The source of this problem isn't DHCP or NT, but a configuration setting on Ascend Communication's (http://www.ascend.com) routers. Ascend's routers offer a special proxy-mode feature, which the company designed to help minimize the cost of dial-on-demand connections. The feature emulates a network connection to clients, rather than let the clients physically connect. An ugly side effect of this feature occurs when the router is on the same network segment as an NT DHCP server. DHCP becomes confused and offers its IP address to requesting DHCP clients. The solution is to disable the routers' proxy-mode setting, which is enabled by default. For more information about this problem, see the Microsoft article "Some Routers May Cause 'Duplicate IP Address' Error Message" (http://support.microsoft.com/support/kb/ articles/q176/2/08.asp).

A final DHCP-related RAS tip is to be sure that the binding order under the DHCP Server Service shows that the DHCP service is bound to the LAN adapter before it's bound to any remote access WAN wrapper entries (i.e., RAS-created virtual adapters). To find this listing, select all services in the Show Bindings for text box on the Bindings tab of the Network applet. If your system binds RAS adapters to DHCP ahead of LAN adapters, DHCP might exhibit bizarre behavior, including an inability to offer DHCP addresses to LAN-based clients.