My January article, "What's New in Windows NT 4.0 RAS?" generated a lot of great feedback and numerous interesting questions and problems. Many organizations use Windows NT's Remote Access Service (RAS) as the foundation for remote access and WAN connectivity solutions. Several new features in NT 4.0 RAS, such as Point-to-Point Tunneling Protocol (PPTP) and Multilink RAS, turn what was once a simple remote access component into a complex, high-powered networking solution. These new features increase the number of problems for users implementing RAS. This article answers questions and introduces a few new RAS-related tips and tricks. To start this discussion of RAS, I'll answer a few questions from readers.
The Case of the Missing Subnet Mask
When I dial in to my Windows NT RAS server and obtain an IP address, running IPCONFIG to display IP address information shows the wrong subnet mask for the RAS adapter. This problem happens from both NT and Windows 95 clients. Why does this occur, and how can I force RAS to recognize the correct subnet mask?
I've wondered the same thing about RAS since I started using it. We use subnetting and variable-length subnet masks (e.g., 255.255.255.192, etc.) in my organization, and RAS has never correctly displayed the network's subnet mask.
Instead, RAS displays the default subnet mask for the IP address. This default address is based on the first octet of the IP address (e.g., the 192 in the address 192.x.x.x) and determines the IP network class in use. Table 1 shows how these values are derived.
If you've noticed this behavior in RAS clients, you've probably also noticed that RAS works fine anyway. RAS uses the default subnet mask because subnet masks aren't a part of Point-to-Point Protocol (PPP--the industry standard framing method RAS uses), and the system doesn't pass them over the connection. You can stop worrying that your RAS clients are getting the wrong subnet mask: This behavior is not unusual for RAS.
Pump Up the Volume
One thing annoys me about using Windows NT 4.0's Dial-Up Networking (DUN): I like to hear the dialing tones and modem negotiation noises during a RAS connection (the noise reassures me that something is happening). But something turns off my modem's speaker as soon as I hear the dial tone (i.e., before the modem dials the phone number). Adding the string L3 in the Extra Settings field in the Advanced Connection Settings dialog box in the Control Panel Modems applet didn't make a difference. How can I make my modem speaker stay on during dialing and negotiation?
I have experienced this problem when manually adjusting the modem initialization string in RAS/DUN under NT 4.0. Using the slide-tab speaker volume adjustment in the Control Panel Modems applet is a hit-or-miss proposition. If this adjustment doesn't work, try placing the string M1L3 in the Extra Settings field in the Advanced Connection Setting dialog box. (To reach this dialog box from the Modems applet, click Properties, select the Connection tab, and click Advanced.)
If neither method works, and you're using Unimodem drivers and not the old MODEM.INF file entries, try editing the Registry section for your modem's Unimodem driver. To locate this entry, open one of the NT Registry editors (REGEDIT.EXE or REGEDT32.EXE) and open the HKEY_LOCAL_MACHINE\CurrentControlSet\Control\Class key. Under this key, you'll find a many bizarre-looking codes (e.g., "\{4D36E351...etc etc"), one of which represents the Unimodem driver class. The specific subkey you're looking for is \{4D36E96D-E325-11CE-BFC1-08002BE10318\}.
After opening this key, you'll see a subkey beginning with "0000," for each installed modem. Inside this key, you'll find various modem-related sections, including one called Init.
Init has values that are the initialization strings NT uses with your modem. You can add the M1L3 statement here or in one of the other subkeys of this tree.
The M and L registers control modem speaker and volume settings, respectively. Table 2 lists the possible values and definitions (I chose M1L3 to set the volume to maximum until the modem connects; this setting is sometimes necessary to hear a modem with a quiet speaker).
RAS Auto Redialing
I want to configure DUN as a service so that when the server boots, it automatically dials the Internet and makes a connection, without requiring that anyone log in. I had our Windows NT 3.51 server doing this task with the command-line utility RASDIAL. When installed as a service, RASDIAL required no intervention to get the network going. Does NT 4.0 have a feature for this procedure? I don't think the RASDIAL utility works as a service in NT 4.0.
Unfortunately, you cannot run this feature with only NT 4.0 RAS. RASDIAL works fine with
NT 3.51 in this capacity (with Service Pack 3 installed), but doesn't work if you try to run it under NT 4.0 as a service. However, you can easily restore the functionality of RASDIAL under NT 4.0 with the following workaround.
1. Use the AutoLogon utility in the NT resource kit to configure NT to automatically log you on during reboot.
2. Create a shortcut in your Startup group that runs the following command:
RASDIAL
This workaround gives you the functionality you had under NT 3.51. To increase the security of this configuration, set a password-protected screen saver with a short timeout value (e.g., 1 minute). This setup will discourage people from accessing this machine, although it will always be logged on and probably unattended. However, both of these methods present a potential hole in your system security. Take this caveat into consideration when you evaluate these procedures for auto-redialing. Make sure that the logon account you're using (either by the AutoLogon utility or the RASDIAL utility) has only the minimum privileges necessary to enable the functionality you need.
Keeping RAS Lean and Mean
I am trying to connect to a RAS server running NT 4.0 Workstation; NetBEUI, IPX, and TCP/IP are loaded on the server. My RAS client computer runs NT 4.0 Workstation. I've specified all three protocols in the client DUN setup. I can connect using NetBEUI and IPX but get the following error when I try to use TCP/IP:Error 733: PPP control protocol for the network protocol is not available on the server. Error 733: the server supports PPP but does not support the client network protocol. Do you know what's wrong? Doesn't PPP load automatically on the RAS server if you specify TCP/IP on that end?
This question raises several issues. First, determine whether you need to run all three protocols via RAS. The overhead of three protocols running simultaneously slows your RAS connection; so run all three only if absolutely necessary for your LAN.
Second, the TCP/IP error probably doesn't have anything to do with PPP (the framing method RAS connections use). Either you don't have TCP/IP installed on the RAS server or you have it installed without RAS configured to assign TCP/IP to clients dialing in. Double-check your RAS configuration on the server, and be sure to correctly configure the IP address range you assign to RAS clients (i.e., a range that is part of your IP subnet and doesn't conflict with other IP addresses in use). To accomplish the IP assignment, use an NT server running Dynamic Host Configuration Protocol (DHCP) to assign the RAS clients' addresses (the RAS server configuration dialog box has a checkbox for this step). This approach will minimize your IP configuration hassles.
Finally, regarding your PPP question: All your protocols, including NetBEUI and IPX, are running over PPP because RAS uses PPP as a frame type much like Ethernet connections used the 802.2, 802.3 and other framing protocols. The protocols that your RAS server and client mutually agreed on will be transported over the PPP RAS link.
PPTP: An Emerging Standard?
I want to use RAS's Point-to-Point Tunneling Protocol (PPTP) for secure WAN connectivity within my organization. I've heard a lot about two other standards, Layer 2 Forwarding (L2F) and Layer 2 Tunneling Protocol (L2TP). What are they and how do they compare to PPTP?
PPTP, which I discussed in the January article, is one of the coolest new features in NT 4.0's RAS, but it is not without limitations. (For more information on PPTP, see Doug Toombs, "Point-to-Point Tunneling Protocol," June 1997.) Microsoft doesn't support PPTP on all client operating systems. This lack of support creates an obstacle for mixed-environment NT networks.
However, one of Microsoft's suggested scenarios for PPTP is for an organization to outsource its dial-up communications hardware to Internet Service Providers (ISPs) that provide PPTP-enabled dial-up servers. This arrangement lets users with non-NT machines running regular PPP-based Internet connections (i.e., non-PPTP enabled) access resources on their organization's PPTP servers. Outsourcing to an ISP requires that the ISP have support for the protocol on its network, and a non-Microsoft-based provider is unlikely to have such support (mainly because PPTP has been a Microsoft-centric standard).
Because of PPTP's limitations, Cisco Systems (a data communications equipment vendor) has developed L2F, a competing standard to PPTP that has challenged PPTP as the choice for creating Virtual Private Networks (VPNs) in non-NT environments. Although these factors had the potential to crush widespread acceptance of PPTP, recent events have turned the tide.
Several major communications equipment manufacturers, including 3Com, Ascend Communications, ECI/Telematics, and U.S. Robotics, have announced hardware support for PPTP. In addition, the Internet Engineering Task Force (IETF) reached an agreement in June 1996 to gradually merge the disparate features of PPTP and L2F into one unified technology: L2TP. If all parties live up to their part of the bargain, you can expect Microsoft to provide a new version of PPTP that includes L2TP.
The final ray of hope shining on PPTP is Microsoft's PPTP driver for Windows 95. It will increase the acceptance of PPTP in environments using Win95 clients in addition to NT workstations; currently, these machines can't use PPTP to directly access PPTP-enabled NT servers.
PPTP Firewalling
I also received several questions from people about the use of PPTP as a
firewall and specifically about the Enable PPTP Filtering option available in
the Advanced TCP/IP configuration dialog box in the Network Control Panel. The
questions centered on one theme: using the PPTP protocol as a secure WAN
connectivity solution. In my January article, I discussed the steps required to
enable PPTP on a RAS server. However, you can enable PPTP filtering to further
enhance RAS's functionality.
With PPTP filtering, you can disable a RAS server's PPTP-enabled WAN interface for all protocols other than PPTP. Then, only PPTP client traffic can enter the network over the server's RAS interface. This limit provides a level of security comparable to many commercial firewall products.
This feature leverages PPTP's capabilities and creates an extra-secure NT environment--and security is a concern when the network is connected to the Internet. You can enable PPTP filtering in the TCP/IP Properties Advanced dialog box in the Network Control Panel. Launch Control Panel, double-click Network, and go to Protocols. Highlight TCP/IP, and choose Properties. Next, select the IP Address tab, and select the adapter you want to enable PPTP filtering on (the Internet-connected adapter). Now click the Advanced button to bring up the TCP/IP Advanced IP Addressing dialog box, which Screen 1 shows. After you check the Enable PPTP Filtering box, shut down and restart your system for the changes to take effect.
From the Advanced IP Addressing dialog box in Screen 1, you'll see a handy new feature in NT 4.0. Check the Enable Security box to bring up the TCP/IP Security dialog box shown in Screen 2.
From this dialog box, you can enable packet-filtering on your NT server, a feature common to most standalone routers. Although not inherently connected to RAS or PPTP, this feature is useful if your NT RAS server is acting as your Internet gateway. (For example, if you have a dual-homed system connected to the LAN on one adapter and an Internet-connected router on the other, you apply the filtering to the Internet-exposed adapter.)
PPTP Registry Tweaks
As long as we're on the subject of advanced PPTP issues, let's talk about a
few Registry tweaks. The first modification relates to enabling the PPTP
filtering option to block non-PPTP traffic. This feature is great for security
but severely impairs TCP/IP's functionality in several ways.
First, this modification prohibits internal network clients from trying to access Internet-based services through a proxy server on the NT RAS server machine and prohibits external Internet-based clients from accessing other services on the PPTP RAS server (e.g., Web, FTP, DHCP, Proxy, etc.). The PPTP filter disables all incoming non-PPTP traffic types, stopping return packets from Internet servers in their tracks.
However, as of Service Pack 2 (SP2), PPTP can pass such traffic for other services, so you can restore these services without compromising the security PPTP provides. To enable this support, you must have at least SP2 installed (preferably SP3 because of its increased stability) and follow the instructions below to modify the Registry. (For information about the security benefits of SP3, see Mark Joseph Edwards, "Service Pack 3 is Really Security Pack 3", page 113.)
Warning: Using the Registry editor incorrectly can cause serious, system-wide problems. You may have to reinstall NT to correct them. Use this tool at your own risk.
With that warning out of the way, let's get down to the details. To let non-PPTP Internet-based clients access services on the RAS PPTP server, start Registry Editor (either REGEDT32.EXE or REGEDIT.EXE) and locate HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RASPPTPF\Parameters\. Add the following value under this key:
Value Name: AllowPacketsForLocalMachine
Data Type: REG_DWORD
Data: 1 (value of 1 enables, 0 disables)
Next, close Registry Editor, and shut down and restart the RAS server. When you restart the server, the PPTP protocol will coexist with other installed server services, without interference from the PPTP filter. Refer to Microsoft Knowledge Base article #Q164052, for more information about this issue.
Another useful Registry tweak is the ability to restrict incoming PPTP connections by IP address (i.e., specify which addresses can connect to your PPTP server). Although PPTP is encrypted and secure, nothing can stop an Internet hacker from trying to discover the Administrator password through repeated login attempts to your PPTP server. However, if hackers don't come in with the right source IP address, they won't even get to try. (For more information on protecting your system from hackers, see Mark Minasi, "NT Security Scares?" and John Meixner, "Foil Attacks on Your Registry," July 1997.)
To enable this feature, you must make two related Registry modifications that need to be added during the same session. These and the other Registry values mentioned below are in HKEY_LOCAL_MACHINE\SYSTEM\Services\RASPPTPE\Parameters\Configuration. The two values you need to add to this key for IP-based restriction follow. The first value tells PPTP to accept only incoming calls from the IP addresses listed in the second key, the PeerClient IPAddresses value.
Value Name: AuthenticateIncomingCalls
Data Type: REG_DWORD
Data: 1 (value of 1 enables, 0 disables)
Value Name: PeerClientIPAddresses
Data Type: REG_MULTI_SZ
Data: (List IP Addresses here one after the other, in the octet format of xxx.xxx.xxx.xxx)
The next PPTP Registry values worth mentioning are network adapter-specific values that you can enable for each adapter. The first value is related to creating default gateway addresses. On multi-homed NT servers with IP forwarding enabled (i.e., those acting as IP routers), NT automatically creates a default gateway on each of the server's LAN adapters. On servers with one adapter on the internal LAN and one connected to the Internet, you can enhance security by disabling the default route creation on the internal LAN adapter.
To disable the route creation, locate the Registry key related to the particular network adapter. This key will appear in a format similar to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<AdapterName>\Parameters\Tcpip. Once you locate the key, add the following value:
Value Name: DontAddDefaultGateway
Data Type: REG_DWORD
Data: 1 (1 disables, 0 enables adding a default gateway)
Another adapter-specific value lets you specify PPTP filtering, on a per-adapter basis rather than as a global value for all adapters (the value is global if you enabled the PPTP Filtering checkbox I described earlier). To enable or disable PPTP filtering on a specific adapter, add or modify the following value in the adapter's Registry key (the same key listed above):
Value Name: PPTPFiltering
Data Type: REG_DWORD
Data: 0 or 1 (1 enables, 0 disables PPTP filtering on the adapter)
A final noteworthy PPTP-related Registry entry is related to timeouts on PPTP WAN connections. If Internet traffic is heavy and packet latency between PPTP-enabled machines is significant, NT might drop the PPTP RAS connection. To cure this problem, increase the number of times PPTP packets will be retried. Add a value to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters.
Value Name: PPTPTcpMaxDataRetransmissions
Data Type: REG_DWORD
Valid Range: 0 0xFFFFFFFF
Default Value: 9 (may be set higher to increase number of retries for PPTP packets)
PPTP Sessions o' Death
Although PPTP opens a world of opportunities for NT shops, ISPs, and users,
it isn't perfect. I've experienced a few problems with RAS and PPTP in my
travels. Although rare, these problems have ranged from minor to deadly.
The minor problem is a tendency for PPTP sessions to drop off and disconnect, even when the underlying RAS session is active. In some cases, increasing the PPTPTcpMaxDataRetransmissions value has helped.
The serious problem I've encountered with PPTP is the PPTP Session o' Death, which is akin to a Blue Screen of Death in severity. In this situation, a PPTP session from a client to the server is rolling along for about 10 to 15 minutes, with no apparent problems. At the 10 to 15 minute mark, the PPTP session becomes a data-corrupting Session o' Death, trashing any data the client is accessing on the LAN.
This problem happened on my network during a seemingly normal session to my primary NT server. I copied one large file and accessed my mailbox on my Exchange server. However, when I copied the file, Explorer seemed to complete the copy operation faster than it should have. The Exchange session crashed, and I was unable to re-access the Exchange server during the session. I quickly realized something was seriously wrong, so I terminated the session.
When I examined the server, I made some unpleasant discoveries. Although Properties on the icon revealed the correct file size, the file was trashed when I pulled it up. I wasn't able to re-access Exchange because my mailbox on the Exchange server was trashed. In fact, no amount of resuscitation of Exchange via repair utilities could fix it.
I had to fully restore my Exchange database to repair the problem. The scary thing about this situation was not only the data corruption, but the fact that I received no warning before the problem occurred.
This situation never happened before I installed SP2 on both machines (something I wish I had never done), and it hasn't recurred since I installed SP3. My SP3 installation might have fixed this problem, but I was unable to find any references to it in the SP3 documentation. I recommend that you install SP3 on any system that you use PPTP on.
I hope this situation never happens to you, regardless of the service pack level you've installed; however, if you do experience the PPTP Session o' Death, please be sure to let Microsoft know. Microsoft needs to address this bug in a future service pack or hotfix. If you aren't experiencing such problems, don't let this story scare you. (I've seen this problem happen twice, and both times were on the same network.)
Fine Tuning RAS
I've examined some additional aspects of RAS and the PPTP protocol to help
you fine-tune your RAS implementation. With the addition of PPTP filtering, you
can use your Internet-connected PPTP RAS server not only as a
communications backbone for the entire company, but as a solid line of defense
against Internet hackers. The combination of a PPTP-enabled RAS server and a
proxy server such as Microsoft Proxy Server or Deerfield Communications' WinGate
offers an alternative to standard applications-level firewalls.
