Microsoft® Windows®95 Dial-Up Networking 1.3 Upgrade
Release Notes

1. Introduction

The Dial-Up Networking 1.3 Upgrade (DUN 1.3) provides additional features for the Dial-Up Networking components that were first introduced in Windows 95. DUN 1.3 includes all of the features of the DUN 1.2 release, and all of the features of the earlier ISDN 1.1 release. These features include support for internal ISDN adapters, multilink support for two ISDN channels, connection-time scripting to automate non-standard login connections, and PPTP client support.

1.1 Performance Features Added in the DUN 1.3 Release

1.2 Security Features in the DUN 1.3 Release

1.3 Other Features in the DUN 1.3 Release

1.4 Features Included from the DUN 1.2b Release

1.5 Installation Notes

DUN 1.3 can be installed on any Windows 95 system. No prior versions of DUN are required.

>>To install DUN 1.3

  1. Double-click MSDUN13.exe and follow instructions.

=The installation process requires you to restart your computer, and may ask for your Windows 95 installation disk (if you originally installed Windows 95 from a CD). If you encounter a "do you want to keep a newer file" dialog, always keep the newer file.

Note: If the installation process reports that it cannot find a file, be sure that you have inserted the Windows 95 installation CD. In addition, make sure that the dialog shows the correct location for the Windows 95 files. For example, the files on an external CD will be in the directory "E:\win95", while the files for a pre-installed Windows 95 system may be in a directory such as "c:\windows\win95. The correct directory will have a number of CAB files (i.e., filenames ending in ".cab")

>>To uninstall DUN 1.3

  1. Click Start, point to Settings, and double-click Control Panel.
  2. Double-click Add/Remove Programs and then click the Install/Uninstall tab.
  3. Double-click Communications and then click Dial-Up Networking to remove the check in the checkbox.

This will remove Dial-Up Networking from your system. After uninstalling, you can add the original Windows 95 version of Dial-Up Networking by using the same procedure as uninstalling DUN 1.3, except for adding a check in the checkbox.. Alternately, you can reinstall the DUN 1.3 upgrade by executing the MSDUN13.exe file.

Note: An uninstall of the Dial-Up Networking 1.3 Upgrade will completely remove Dial-Up Networking from your system, including any features that depend on it. For example, an uninstall would remove Direct Cable Connection and Virtual Private Networking in addition to the ability to dial out over modems or ISDN devices. If you have installed an ISDN device, removing Dial-Up Networking will logically remove the device and any information that you entered for it. This information will not be restored when you reinstall Dial-Up Networking.

Always use MSDUN13.exe or the Add/Remove Programs icon in Control Panel to add or delete Dial-Up Networking from your system. Do not add or remove individual Dial-Up Adapter or Virtual Private Networking Adapter components via the Network Control Panel applet or from the Device Manager tab of the System applet.

A separate utility (DUN128) is available which will modify an MSDUN 1.3 installation to enable use of 128-bit encryption. This utility can be obtained from the Web site below.
This utility places an entry in the Add/Remove Programs control panel to allow you to remove the 128-bit encryption (leaving the original 40-bit encryption in place).

NOTE: The Dial-Up Networking 1.3 Upgrade relies on features in the most recent version of the Microsoft TCP/IP stack. For that reason, installation of the upgrade will replace your current TCP/IP protocol stack (or add the stack if you do not already have it installed.) The installation will also update the Winsock DLL if an older Winsock is detected.

If you have applications that rely on a third party stack or a custom Winsock, you may want to discontinue this upgrade. If you choose to perform the upgrade, and certain applications stop working, you will have to reload these applications. If you have previously installed the Microsoft Winsock Proxy, you will have to reinstall it after installing DUN 1.3.

1.6 Server Updates

This upgrade is fully compatible with legacy PPTP systems. However, in order to negotiate historyless mode, both the PPTP client and server must support this new mode. Server support for historyless mode and for MSCHAPV2 will be included in Windows NT 4.0 Service Pack 4. For installations which require these features before general availability of Service Pack 4, a hotfix for Service Pack 3 has been created. This can be found on the Microsoft FTP site at Servers running the Routing and Remote Access Upgrade should apply the above, and then apply rras30-fix from the same location.

NOTE: RAS and PPTP servers must be maintained to current Windows NT Service Pack levels. A Windows 95 client machine that has been upgraded to DUN 1.3 will no longer connect to a Windows NT Server that has not been updated to Service Pack 3 or above.

Front End Processors (FEPs) are dial-up access servers which are capable of creating PPTP tunnels on behalf of dial-up PPP clients. Servers which terminate such compulsory tunnels from FEPs must disable the historyless mode.

2. Feature Overview

2.1 ISDN Support

MSDUN includes support for internal ISDN adapters that was previously delivered in the ISDN 1.1 Accelerator Pack. To assist in the setup process, an ISDN Configuration wizard is automatically installed in the Start menu.

>>To run the ISDN Configuration wizard

  1. Click Start, point to Programs, point to Accessories, point to Communications, and then click ISDN Tools,Follow the wizard instructions.

2.2 Multilink Support

Multilink support enables your computer to use two communications ports as if they were a single port of twice the bandwidth. This feature is most useful to ISDN users, since it allows them to use both sides of an ISDN line for an aggregate bandwidth of 128Kbps. Multilink support is also available to modem users, but on most systems, the serial port overhead eliminates much of the benefit that could be gained from simultaneous use of two modem calls. Multilink is enabled from the properties page of any connection icon in the Dial-Up Networking folder.

2.3 Scripting

Some internet service providers require a terminal interaction with the user at the start of a dial-up connection. The scripting feature included in this Dial-Up Networking upgrade allows you to automate this interaction. Scripting is enabled from the Properties page of any connection icon in the Dial-Up Networking folder. The scripting language is described in the file "script.doc" in your windows directory.

2.4 PPTP Client

MSDUN includes the ability to create a PPTP tunneling client. Tunneling is a networking term describing the encapsulation of one protocol within another protocol. Tunneling is typically done to join two networks using an intermediate network that uses an incompatible protocol or which is under the administrative control of a third party.

2.4.1 PPTP Tunneling

The Point-to-Point Tunneling Protocol (PPTP) is a protocol defined by the PPTP Forum whose specifications are publicly available and supported by a variety of networking vendors. PPTP allows PPP packets to be encapsulated within Internet Protocol (IP) packets and forwarded over any IP network, including the Internet itself. In order to run the Windows 95 PPTP client; you must be able to establish an IP connection with a tunnel server such as the Windows NT®Ò Server 4.0 Remote Access Server (RAS).

Windows Dial-Up Networking uses the Internet standard Point-to-Point Protocol (PPP) to provide a secure, optimized multiple-protocol network connection over dialed telephone lines. PPTP adds the ability to treat the Internet as point-to-point Dial-Up Networking connection. All data sent over this connection can be encrypted and compressed, and multiple network level protocols (TCP/IP, NetBEUI, and IPX) can be run concurrently. Windows NT Domain Login level security is preserved even across the Internet. PPTP can also be used to connect to an intranet that is otherwise isolated from the Internet, even if the intranet has Internet address space conflicts.

PPTP appears as new modem type (Virtual Private Networking Adapter) that can be selected when setting up a connection in the Dial-Up Networking folder. The VPN Adapter type does not appear elsewhere in the system. Since PPTP encapsulates its data stream in the PPP protocol, the VPN requires a second dial-up adapter. This second dial-up adapter for VPN is added during the installation phase of the Upgrade in addition to the first dial-up adapter that provides PPP support for the analog or ISDN modem.

2.4.2 PPTP Connections

The Make a New Connection wizard will guide you through the steps needed to create connection icons for either normal dial-up (modem) calls or PPTP (virtual private network) calls. You indicate use of PPTP by selecting VPN rather than a modem as your device type. Dial-up PPTP Connections

The most typical application for PPTP involves a dial-up PPP connection to the Internet followed by a separate PPTP connection to a remote tunnel server. This "two call" sequence requires two connection icons in the Dial-Up Networking folder, and two "dialing" actions by the user. The results of a successful tunnel over the Internet are two network connections on your computer: one to the Internet, and one to the target network served by the tunnel server. To understand the behavior of your computer in this configuration, see the discussion below regarding Default Routing to Remote TCP/IP Networks. LAN-based PPTP Connections

A second application for PPTP involves a tunnel over a LAN to which your PC is already attached. In this case, only a single connection icon is required, and only a single "dialing" action by the user in order to initiate the tunnel. Under this scenario, it is not necessary to have a Dial-Up Networking connection to the Internet to support PPTP. The ability to route packets correctly to the PPTP tunnel server over an IP network is the only requirement for a PPTP connection. Again, see the discussion below Default Routing to Remote TCP/IP Networks or the more detailed discussion in the file About PPTP and Dial-Up Networking 1.3.doc in your Windows directory.

2.5 Per-Connection Encryption Settings

In most installations, the servers settings will determine the level of encryption on a dial-up or PPTP connection. The Windows NT Server 4.0can be set to require encryption for all connections (in which case it will offer 40-bit encryption), or to require strong encryption (in which case it will offer 128-bit encryption). The Windows 95 Dial-Up Networking client will normally accept the servers encryption request.

The DUN 1.3 upgrade adds the ability to require encryption for a specific connection. In the DUN 1.3 upgrade, a checkbox on the Server tab of the connection's property page has been added, allowing you to require encryption for a successful connection. A new registry variable, ForceStrongEncryption, has been provided to allow the client to require strong encryption. If the server proposes 40-bit encryption, such a client would respond by requesting 128-bit encryption. A 128-bit capable server would accept the client's request. Note that a server which is capable of only 40-bit encryption would not be able to accept a client request for 128-bit encryption. A connection request of this type would fail.

The registry flag which forces strong encryption is defined below. By default, the flag is absent. The value of this flag is checked just before a connection is attempted.


DWORD: ForceStrongEncryption

Default: 0x00000000

0x00000000 = No effect; does not force strong encryption

0x00000001 = Requires 128-bit encryption for any connection which already requires encryption

Note:Data encryption is negotiated during the Compression Control Protocol (CCP) phase of the connection. Consequently, the property sheet for a connection must enable either compression or encryption in order for the encryption negotiation to succeed. This is rarely an issue since compression is enabled by default

2.6 Modem Pool Access

PPTP can be also used as a method for a LAN-based computer to make a dial-up connection to a remote computer or network through a modem pool on an appropriately configured access server.

If PPTP connections are established to your network by a PPTP-enabled access server (sometimes called a Front End Processor (FEP)), and if your system administrator has configured the access server with several modems set aside for outbound calls, your PPTP client can cause these modems to initiate a PPP dial-out connection between your client and another computer or network.

To cause such a connection, simply establish a PPTP connection whose tunnel address is specified as "AccessServer<space>PhoneNumber". AccessServer is the DNS name or IP address of the PPTP-enabled access server; and PhoneNumber is the set of digits to be dialed to reach the other site. The access server will bring up a dial-up PPP connection to the digits supplied. On connection, your computer will behave as if it had dialed directly into the remote site. Authentication will be performed by the remote site. For more information see the section Default Routing to Remote TCP/IP Networks or the more detailed discussion in the document About PPTP and Dial-Up Networking 1.3.doc.

Note: This feature is only supported by access servers which support compulsory tunneling. These are servers which receive an ordinary dial-up PPP call, then create a tunnel on the callers behalf, and then insert the PPP traffic into the tunnel. Windows NT RAS does not presently support this feature.

3. Product Limitations and Related Issues

There are network routing issues and product limitations that may affect network behavior when you are using Windows 95 Dial-Up Networking. Network routing issues are discussed in the Default Routing to Remote TCP/IP Networks section below. Product limitations and related issues are discussed in this section.

3.1 Name Resolution Issues

The original release of Windows 95 Dial-Up Networking had limited support for WINS and DNS name resolution when a computer was connected to multiple networks. The Dial-Up Networking 1.3 Upgrade resolves all of the WINS limitations, and applies a Winsock upgrade to resolve the remaining DNS limitations. This Winsock upgrade represents a minor change over the Winsock that was originally delivered with Windows 95.

Microsoft has also released Winsock2, a complete redesign of the Winsock architecture. Winsock2 is fully compatible with the Dial-Up Networking 1.3 Upgrade. If Winsock2 has already been installed, the Dial-Up Networking 1.3 Upgrade will not overwrite it. If you wish to install it, Winsock2 is available from the Microsoft web site at

3.2 Static IP Address, WINS, and DNS Settings

In almost all cases, you should allow the network to define your computer's IP address and to provide WINS and DNS server addresses automatically. This occurs when you start your machine on a LAN, or when you successfully establish a PPP or PPTP connection to a remote network. In the rare cases where an ISP or systems administrator requires you to set an IP address or to define addresses for WINS and/or DNS servers, you should do this in the appropriate connection icon.

To manually configure the IP address

  1. Right-click the Dial-Up Networking icon that you want to modify.
  2. Click Properties.
  3. Click the Server Types tab and then click TCP/IP Settings.
  4. To specify an IP address, click Specify an IP address and enter the appropriate information.
  5. To specify a DNS address, click Specify name server address and enter the appropriate information.

Generally, you should not set TCP/IP properties for dial-up adapters or LAN adapters from the Network icon in the Control Panel without specific instructions from your network administrator.

NOTE: There have been cases where cable modem installation instructions required the user or installer to use the network control panel applet to define a DNS server and to define a DNS domain suffix search order for the LAN card serving the cable modem. (This information is on the TCP/IP properties sheet for the affected LAN card.) Defining a DNS suffix search order will cause timeout delays when a tunnel is used to reach another network, unless the suffix for that network is included at the top of the list.

3.3 Remote Access after Physical Disconnection from a LAN

An addressing problem can occur when a computer that has been directly connected to a private TCP/IP network is physically disconnected and then attempts a dial-up or PPTP connection. For example, when a laptop user disconnects an Ethernet connection from the corporate network and then tries to dial in from home. If the network card is still installed, TCP/IP may be configured so that the computers that could be reached through the card, still appear reachable. Even after a modem Dial-Up Networking connection or a PPTP connection is established back to the same network, TCP/IP will continue to send all traffic for computers on the local network out the netcard.

To fix this, if the computer originally booted from DHCP, run the winipcfg utility and select the Release option.


  1. Click Start and then click Run.
  2. Type winipcfg in the Open box.
  3. Click Release.

If this does not fix the problem, the netcard may have been manually configured through the Control Panel, and will have to be disabled through the Control Panel.

3.4 Accessing Network Shares Across Private Networks

When two networks are under Windows NT domain login security and they are in different, non-trusted domains, it is not possible to tunnel across one network to reach hosts or servers on the second network. Windows 95 logs into the first domain and cannot log in to a second domain. The workaround is to skip the initial domain login (Cancel) and log into the second network when the PPTP connection is established.

Note that since the Internet does not employ domain login security, this problem will not occur when tunneling across the Internet.

3.5 Multi-homed IPX Support in Microsoft Client for Networks

A computer which uses the Client for Microsoft Networks may have problems communicating with a remote IPX network over PPTP if IPX is simultaneously bound to a LAN adapter. These problems do not occur in an ordinary dial-up connection. These problems do not occur in a computer which is running the Client for NetWare Networks.

3.6 Suspend Mode for Laptop Computers

You can suspend operation of a laptop computer by selecting Suspend from the Start menu. Many machines offer a hardware Suspend button, but some of these do not provide adequate time for the software components of Windows 95 to safely stop operation. On some platforms, use of the Suspend feature will result in a disabled machine on Resume. You should always use the Start menu to suspend execution on any laptop.

3.7 ISDN1.0 Accelerator Pack Drivers

Windows 95 now supports ISDN NDISWAN drivers that are binary compatible with Windows NT. This has been the case since the release of the ISDN Accelerator Pack 1.1, which required the use of Windows NT-compatible ISDN 1.1 drivers. Consequently, most ISDN vendors supply ISDN 1.1 drivers with their hardware. Drivers compatible with the Windows 95 ISDN Accelerator Pack 1.0 no longer work.

For more information, a list of known vendor drivers is on the Web site

3.8 ISDN Driver Installation

Many vendors bundle the old ISDN1.1 Accelerator Pack with their own device drivers on their installation diskette to simplify the installation process. As a result, if a vendor's install procedure is run on a system that has been upgraded to 1.3, the install procedure may overwrite some of the upgraded files and leave various portions of the system unusable. Typically, the vendor install will ask you if it is OK to install ISDN 1.0 or ISDN 1.1. Click No when this question appears.

If you think that the vendor's install has overwritten Dial-Up Networking, you should immediately run the Dial-Up Networking 1.3 Upgrade installation routine MSDUN13.exe.

As a general note regarding ISDN driver installation, make sure you know the ISDN switch type, SPIDs, and phone numbers. This information is available from your telephone company. You should have it before you proceed.

3.9 Multilink Operation

After your additional devices are configured using the procedure outlined in the previous section, you are ready to dial your Multilink connection. When you dial the connection, Dial-Up Networking dials the primary number of the primary device specified for the connection. Once the first connection is established, Dial-Up Networking will then dial the other devices specified in the Additional Devices list.

Once the connections are established, you can view status information about the link by double-clicking on the communicating computers icon displayed in the taskbar, or you may disconnect. The status information includes the number of bytes sent and received, the network protocols negotiated for use on the connection and a list box showing each of the additional devices. As you highlight a device in the list box, a Suspend or Resume button is displayed. If a Suspend button is displayed, then the device is now in use and bundled into the Multilink connection. Clickingthe Suspend button disconnects that line and removes it from the bundled connections. If the Resume button is displayed, then clicking on the button dials the connection and adds that line to the bundle. You may suspend and resume individual links without dropping the connection.

3.10 Limited IP-IP Dial-in Server

Previously, Windows 95 could only act as a dial up server for IPX and NetBEUI traffic. This new feature lets a Windows 95 machine answer a dial up call for machine to machine applications such as Microsoft NetMeeting (which supports application sharing, chat, video conferencing, and IP based telephony). The Dial-Up client is always assigned, and the server is always The Point-to-Point IP Server is enabled by default, and can be enabled/disabled in the advanced properties for the Dial-Up Adapter.

4. Security Related Notes

PPTP employs existing PPP features to enable secure, encrypted access to a private network for selected clients on the Internet without providing access to all of the potential clients on the internet. The PPTP tunnel server controls this access by authenticating connection requests from the clients that request tunnel connections to the private network. Security can be further enhanced by enabling static PPTP filtering on the tunnel server, or by placing the tunnel server behind a firewall, or by enabling IP filtering on a Windows NT4 tunnel server equipped with the Routing and Remote Access service. For more information, see the User and Administrator Guide on Installing, Configuring and Using PPTP with Microsoft Clients and Servers located at:


This release supports a new MSCHAP (MSCHAP V2) which provides the following security features:

For VPN connections, a Windows NT Server 4.0 will negotiate MSCHAP V2 before negotiating the original MSCHAP. A DUN 1.3 Windows 95 client will accept this offer and use MSCHAPV2 as the authentication method. To ensure that no VPN clients authenticate using MSCHAP, the server can be set to require MSCHAP V2. This will prevent legacy clients from presenting their credentials in an MSCHAP or PAP or CHAP exchange, and is a likely configuration for networks that require the most secure authentication method.

If there are special circumstances in which you wish to ensure that your computer uses only the new MSCHAP V2 for all VPN connection attempts, a new client-side registry flag, SecureVPN, can be used to force this behavior. When this flag is set, your computer will only accept MSCHAP V2 authentication for any VPN connections. In addition, this flag will require data encryption for all VPN connections. Dial-up connections are not affected.

NOTE: Most users will not need to use the Secure VPN flag. This flag should be used with care because it will affect the behavior of all VPN connections from your machine. In general, the required use of MSCHAP V2 and data encryption can be enforced more easily on the server.

The registry setting which will force a Windows 95 client to use only the new MSCHAP V2 secure mode and require data encryption for PPTP connections is defined below. By default, this registry variable is absent, meaning "do not force secure mode on PPTP connections". The value of this variable is checked just before a connection is attempted.


Default: 0x00000000


Value: 0x00000001 == Force secure mode (MSCHAP V2 plus data encryption) on all PPTP connections

Value: 0x00000000 == Do not force secure mode on PPTP connections

4.2 LMhash Suppression

This release also provides a new registry variable which prevents the client from sending the LM response to a legacy MSCHAP challenge, as defined below. This will prevent use of the LM response in either an MSCHAP response or in a change password response. By default, this variable is absent, meaning that the client should send the LM response (in order to maintain compatibility with legacy servers). This variable affects both dial-up and VPN connections; its value is checked just before a connection is attempted.

NOTE: Most users will not need to use this registry variable. The new secure mode MSCHAP V2 will not send the LMHash response, so this registry value is most useful when connecting to older access servers which use the original MSCHAP. Setting this variable on a Windows 95 client will prevent the client from connecting to a Windows 95 server.


DWORD: UseLmPassword

Default: 0x00000001

0x00000000 = Do not send LM challenge response (send only NT challenge response)

0x00000001 = Send LM challenge response

4.3 PPTP Filtering

Static PPTP filtering can be enabled on a tunnel server, and if enabled, allows only PPTP packets to pass into the tunnel server. This immediately limits Internet access to PPTP clients. When setting up a tunnel server, keep in mind that the ICMP Echo packets used by ping will not pass through this filter and are simply discarded. Consequently, it may be useful to disable PPTP filtering during the shakedown period, and then enable PPTP filtering for production use.

4.4 Firewall Compatibility

PPTP traffic will pass through a properly configured firewall. The PPTP tunnel control channel uses TCP port 1723. Data packets are transmitted over IP using protocol ID 47 (GRE) with a GRE Protocol field of 0x880B. The firewall filters must be properly set to admit this traffic into the private network and to exit from the network. Note that there are a few firewall products that cannot be configured to accept protocol 47. If you need enhanced PPTP filtering capability look at the Routing and Remote Access service which can be downloaded from .

4.5 GRE Packet Filtering

Some networks utilize GRE messages for internal operations and have set their routers to prevent GRE packets from entering or leaving the network. If the PPTP tunnel is configured correctly, but transmits no data, your internet service provider may be screening GRE packets. Contact your ISP to resolve this issue.

4.6 Use with Microsoft Proxy Server

The Proxy Server and a RAS tunnel server can be located on the same server hardware. In this configuration, the Proxy Server supports local users on the LAN who wish to access the Internet in a protected manner, while the RAS tunnel server allows remote users to reach this LAN via the Internet in a secure manner.

The only limitation to this configuration is that a client on the local LAN cannot originate a tunnel to a remote tunnel server while configured to use Winsock Proxy for Internet access. It is not possible to pass a PPTP session from a client running the Microsoft Winsock Proxy through a proxy server to a remote tunnel server. In order to originate a tunnel, the client must have direct route access to the remote tunnel server, and must disable the Winsock Proxy for the duration of the PPTP session.

5. Network Routing Behavior

When a PPTP connection is established, the client network protocols will see an additional dial-up adapter become active. PPTP itself uses TCP/IP to tunnel network packets, so at least one adapter in the client must be bound to, and running TCP/IP. This adapter can be a NIC, in the case where the client is connecting to a PPTP server on a LAN. The TCP/IP adapter can also be a dial-up adapter, in the case where the client is dialing into a RAS server or ISP, and then connecting to a PPTP server across a private intranet or the Internet. The client must also support the network protocol of the target (private) network. The behavior of NBF, IPX and TCP/IP clients are described below

5.1 NBF Clients

It is assumed that the PPTP client is connecting to an NT RAS/PPTP server. NetBIOS Frames (NBF) will work as expected. The PPTP client will be able to see both the original network and the new network concurrently. The client will be visible to computers on both LANs, but the networks will not be joined through the client. The client's ability to see computers on the new network is provided by the Windows NT Server's NetBIOS gateway.

5.2 IPX Clients

Once connected via PPTP, only the target network will be visible with IPX at that time. This is unchanged from current Window°95 dial-up IPX connections. Currently, when IPX is selected in a phonebook entry and IPX is active on a NIC, a dialog is presented to the user explaining that NetWare servers on the local LAN will no longer be visible once a connection is established to the remote LAN. Users will see this same dialog when establishing a PPTP connection.

5.3 Default Routing to Remote TCP/IP Networks

All TCP/IP host computers (including your Windows 95 computer) share a routing limitation that is important for Dial-Up and PPTP users accessing remote TCP/IP networks. Host computers rely on a routing scheme called default gateway routing. This mechanism is simple: to reach any computer not on the local network, and not specified by any other routing table entries, forward the traffic to a specified default gateway router. The gateway router generally knows how to forward the traffic correctly. This approach has the advantage that your Windows 95 computer can connect to millions of other computers without complex routing tables. This approach has the disadvantage that it assumes that there is only a single connection to all of the external networks it may wish to reach.

The default gateway concept works particularly well for a stand-alone computer that is dialing into a remote network. When a dial-up connection is established, a default gateway is assigned to route traffic through that connection.

The concept breaks down when your computer already has a default gateway, and a second default gateway is assigned by Dial-Up Networking to reach a new network. This could happen, for example, if your computer had a default route for its local LAN and then dialed an additional connection into a remote network. It could also happen if your computer dialed into the Internet and then made a second PPTP connection to a remote tunnel server. In both of these cases, the first gateway is replaced by the most recent gateway, and computers that were reachable though the first gateway will no longer be visible. Note that a DNS or WINS name server that may be one of the computers that is hidden. This will result in the inability to resolve computer names on the affected network.

In summary, TCP/IP default gateway routing is designed to work with computers that connect to a single network. A PPTP connection over a Dial-up link, or a Dial-Up connection from a LAN-based computer, result in two network connections.. In each case, the default route will point to the most recent connection. When the PPTP or Dial-Up connection is released, all connectivity to the first network will be restored.

5.3.1 Static Routes

The workaround is to add a route entry to destination network or computer by using the route command from a DOS prompt. For matching traffic, TCP/IP will use this route rather than the default gateway.

The following example walks through the case of dialing into an ISP and then establishing a tunnel to a private network. The abbreviated output below shows the default gateway after the dial-up connection has been established. The ping command is used to demonstrate that can be reached across the Internet:

C:\OSR2>route print

Active Routes:

  Network Address        Netmask     Gateway Address    Interface     Metric           1
	(other route table entries can be ignored)


Pinging [] with 32 bytes of data:

Reply from bytes=32 time=149ms TTL=58
Reply from bytes=32 time=144ms TTL=58
Reply from bytes=32 time=133ms TTL=58
Reply from bytes=32 time=135ms TTL=58

The default gateway is the entry with the Network Address of This is the simple case of being connected to a single network (the Internet). There is only a single default gateway.

The output below shows the assignment of a second default gateway after a PPTP connection has been established to a private network across the Internet. The more current gateway has the lowest Metric, and will be used to provide access to the private network. The gateway with the Metric 2 will not be used again until the PPTP connection is released.

C:\OSR2>route print

Active Routes:

  Network Address          Netmask  Gateway Address    Interface        Metric

The result of this is that we can no long ping


Pinging with 32 bytes of data:

Request timed out.

Adding a static route in this form solves the problem:

C:\OSR2>route add


Pinging with 32 bytes of data:

Reply from bytes=32 time=164ms TTL=58
Reply from bytes=32 time=160ms TTL=58
Reply from bytes=32 time=157ms TTL=58
Reply from bytes=32 time=144ms TTL=58

The first number in the route add command is the IP address of the target computer and the second is the default gateway that has the Metric of 2.

Notice that we pinged by using the IP address returned from the previous ping, rather than the name Why? The process of converting an Internet computer name to an IP address is called name resolution, and uses a computer on the Internet called a Domain Name Server (DNS). The DNS computer IP address was entered for this dial-up connection in the phone book entry. Unfortunately, the DNS server itself becomes invisible after the second default gateway becomes active. A ping by name will fail because the DNS server cannot be contacted to resolve the name.

Bad IP address

The important thing to notice here is that the ping did not fail. It didn't even get started because the name could not be translated into an address for ping to use. Adding a route to the DNS server itself fixes this.

C:\OSR2>route add


Pinging [] with 32 bytes of data:

Reply from bytes=32 time=164ms TTL=58
Reply from bytes=32 time=160ms TTL=58
Reply from bytes=32 time=157ms TTL=58
Reply from bytes=32 time=144ms TTL=58

Note that some DNS servers resolve the same name to different IP addresses at different times, typically for load-balancing. The only workaround for this is to add network route entries for all possible IP addresses. This is beyond the scope this document.

Finally, note that since a static route references the IP address of the dial-up connection, it can only be defined once the dial-up or PPTP connection has been established.

Information in this document is subject to change without notice and is provided for informational purposes only. The entire risk of the use or results of the use of this document remains with the user, and Microsoft Corporation makes no warranties, either express or implied. The names of companies, products, people, characters, and/or data mentioned herein are fictitious and are in no way intended to represent any real individual, company, product, or event, unless otherwise noted. Complying with all applicable copyright laws is the responsibility of the user. No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

© 1998 Microsoft Corporation. All rights reserved.

Microsoft, MS-DOS, MS, Windows, Windows NT, are either registered trademarks or trademarks of Microsoft Corporation in the U.S.A. and/or other countries.

The Windows 95 PPTP client is based on code developed by 3Com Corp.

Other product and company names mentioned herein may be the trademarks of their respective owners.