HOUR 8
Remote Networking

What You’ll Learn in This Hour:

• Reasons for remote networking

• The history of remote access

• Remote access requirements

• Remote access with SLIP, PPP, and L2TP

• Using VPNs and the Internet for remote access

In today’s world of commerce, business is often accomplished on the run as employees travel from location to location to conduct their affairs. People find it advantageous to access their employer’s network from home, a branch office, and other locations. Walk through a hotel lobby, an airport lounge, or even a café, and you will encounter network surfers, busy at work communicating with their company’s information systems...or perhaps busy playing online Scrabble.

Whatever the network session might be, remote access employs several connectivity strategies to provide users connections from a remote site to corporate, institutional, and home networks. Since the 1970s, dial-up modems have provided one way of accessing a corporate network. For the past decade, higher-speed connections and new remote networking standards have expanded options, including the use of virtual private networks (VPNs) over the Internet. In this hour, we’ll explore these strategies for remote connections.

Early “Remote Control”

The first widely used remote access system was Telnet. One example of Telnet was its partnership with UNIX. Users needed to connect to their UNIX host system when they weren’t directly connected to the system’s central processor unit (CPU). Thus, in 1969 Telnet standards were published to provide guidance on building software for a remote client to communicate with a host computer. To the user, there would be no difference between a Telnet session 1,000 miles away and a session with a terminal sitting next to the UNIX host. (In those days, this host was called the mainframe.)

The first PC remote access solutions were built using Telnet’s remote control behavior. It isn’t surprising that remote control was the first method of remote access used for personal computers because initially, personal computers weren’t considered sufficiently powerful to do very much local processing. Because of its age and lack of security features, Telnet has seen diminished use, and many implementations have been replaced with Secure Shell (SSH), which is examined in Hour 20, “Security.”

Remote Control for System Administration

In the early days of PC remote access, when employees needed access to their applications and files while on the road, an information system (IS) person would arrive at their desks with floppy disks in tow. The IS technician would then install remote control software on both the user’s desktop and the laptop computer. The IS person would then instruct the user to put the desktop system into a mode in which the computer waited for a call while the user was out of the office. The user would take his trusty eight-pound laptop on the road, and if he needed to read email, check a schedule, or gain access for any other reason, he would dial in to the desktop computer. The screen of the desktop computer would appear on the laptop, and the user could slowly read email or work with other applications. When the session was over, the user would disconnect the laptop’s modem, and that would be the end of data access for that session. This mode of communicating seems far-fetched now, but not so long ago it was the prevalent method for remote access.

One area where remote control has increased and, in fact, has become one of the preferred methods for remote access to computers is system administration. Some organizations have elected to avoid phone support for their workers, preferring instead to simply install a system management remote control agent on each end user PC. With the agent in place, a user can report a problem with his computer, and an administrator can use the agent to temporarily take over the user’s desktop across a network.

Help desks from Internet service providers (ISPs) or companies such as Microsoft and Dell make extensive use of remote control system administration systems. These technical centers also take control of a remote customer’s computer to diagnose and fix problems.

Modems and Remote Access

We’ve danced around the subject of modems in several parts of Hours 1–7. Now is the time to explain them because they are a vital part of the remote access equation. The term modem stands for modulate-demodulate. A modem accepts digital data in the form of positive or negative voltages from a computer and modulates it into an analog form that can travel over conventional phone lines. At the other end of a connection, another modem translates the analog signal back into a digital format such that the computer on the other end can process it. A general view of the process is depicted in Figure 8.1.

FIGURE 8.1 The modulation/demodulation process

You might ask, “Why are modems necessary at all? Why not just transmit the data digitally?” Modems are necessary for the majority of users who need to access networks because conventional telephone installations are designed to carry analog signals. After all, we humans speak in analog signals, not in binary 1s and 0s.

Unless a user has migrated to digital services, such as digital subscriber line (DSL), the modem remains a vital tool for remote access communications. I have opted for high-speed digital access when possible, but I still use modems when I travel to vast parts of the globe where digital facilities aren’t available. As examples, I have used dial-up modems in places such as the Caribbean, Versailles, France, and Beijing, China, because dial-up was the only way I had to connect to my home and office networks and the Internet.

Modem Standards and Universal Connectivity

Fortunately, for the data networking industry, all modem manufacturers have settled on a common set of specifications for building their machines. The standards, commonly called the “V-Series” modems, are published by the International Telecommunications Union (ITU) and range from the “ancient” devices that transmitted data at 300 bits per second (bps) to the modern broadband modems, capable of transmissions speed in the megabit per second (Mbps) range.¹

¹ If you want to know the details (now mostly history), look at my book The V Series Recommendations: Protocols for Data Communications over the Telephone Network.

For a while, in the 1960s and 1970s, a few hardware firms were building proprietary modems, notably AT&T. As well, Hayes Communications’ Smartmodem added a command set to the AT&T modems to instruct the modem how to dial numbers, answer calls, and go “on-hook” and “off-hook.” Because AT&T’s products didn’t find extensive success in Asia and Europe, the 1970s saw the beginning of a migration to the V Series modems (along with the Hayes command set).

Cellular and Broadband Modems

Cell phones use modems, and so do broadband connections on cable, satellite, and phone systems. All are classified as modems because they modulate and demodulate analog frequencies. However, these modems employ complex coding and compression techniques to allow megabit data rates. In addition, they are “intelligent” enough to correct certain distortions to a transmission and even to adjust their transmission rates based on the current conditions of a connection. Many of these modems are housed in the same shell as a router. The broadband connection sitting next to my PC is supported by a so-called DSL modem/router.

Modern Remote Access Protocols and Procedures

Over the past several years, a variety of technologies have become available to enable computers to join networks from remote locations as opposed to remote-controlling a remote computer on a network. These factors include the following:

• An increase in the processing power of laptop computers

• The huge increase of Internet use and the universal acceptance of the Internet remote access protocols

• An increase in the installed base of higher-quality analog phone lines

• The increase in high-speed data access provided by cable and DSL modems

• The increased numbers of TCP/IP implementations

• The introduction of enhanced security features to allow the use of the public Internet as a medium for connecting private local area networks (LANs)

The Point-to-Point Protocol (PPP)

The Point-to-Point Protocol (PPP) was developed to solve several problems that evolved as more people began to use computer networks. Several vendors and standards organizations developed network layer protocols (L_3 of the OSI model), such as IP, IPX, AppleTalk’s L_3, and IBM’s SNA L_3. Consequently, machines (such as routers and servers) had to support more than one Layer 3 protocol.

It was recognized that the negotiation of various options between two users would be helpful and efficient. For example, compressing parts of a packet would yield better throughput. As another example, an ISP might want to assign an IP address to a dial-up user. Until PPP was developed (as well as its predecessor, the Serial Link Interface Protocol [SLIP]), these operations were performed with proprietary protocols; or worse, they weren’t performed at all.

In addition, the networking industry had no standard method for “encapsulating” the various vendors’ protocol stacks into a packet. Thus, if a packet arrived at a router, this machine had to somehow figure out if the packet was an Internet Protocol (IP), Internetwork Packet Exchange (IPX), Systems Network Architecture (SNA), Xerox, or AppleTalk packet. Although the router could indeed figure it out, the process was slow and cumbersome.

PPP solves these problems. Although most vendors have migrated to IP, PPP is still widely used for setting up addresses, negotiating a few options, and (especially) authenticating the remote user. Equally important, PPP is also used to ensure the two point-to-point communicating parties have a reliable physical connection with each other before data is sent. Thus, IP cannot send packets until PPP has performed a successful handshake with the other machine, such as an ISP router. Furthermore, PPP will not perform this handshake if the two modems aren’t communicating properly. That is, PPP will be enabled to operate only if the physical channel (L_1) and the Link Control Protocol (L_2, or LCP) are operating properly.

Supporting Protocols to PPP

After it has been determined that, say, a client and the client’s ISP have an acceptable modem connection (either dial-up or broadband) and an L_2 link protocol is in place, PPP executes its LCP to set to set up a PPP relationship between the two parties. During this procedure, LCP might also send “Configure” packets to negotiate options (such as the size of an IP packet that will be used during data transfer) and any authentication procedures. For the latter feature, older systems use the Password Authentication Protocol (PAP), whereas newer dial-up connections have migrated to the Challenge Handshake Authentication Protocol (CHAP), which is examined in Hour 20.

After LCP has finished these key handshakes, PPP executes its Network Control Protocol (NCP) to negotiate options specific to the specific L_3 protocol. For example, with IP, compression and IP addresses can be negotiated. As another example, with AppleTalk, network zone information can be exchanged.

Finally, after NCP has completed these tasks, user traffic can be exchanged between the two parties. But “finally” might be an unfair characterization of PPP’s operations, because these negotiations take place almost instantaneously. Also, even if you don’t have a conventional dial-up operation on your network, it is likely your broadband or ISP still use PPP to make certain the link between your network and the provider’s network is operating properly.

Other Useful Features of PPP

As you might have noticed, certain features, such as negotiating which L_3 protocol is to be used during a session, are somewhat antiquated because IP has largely taken over this role. Another feature that was put into PPP to deal with the diversity of protocols but is still useful today is called auto-detection, a service provided at the data link layer (L_2) of the OSI model.

Today, the data communications industry has migrated to a more restricted set of procedures and protocols used for L_2 operations. Nonetheless, the data link procedures for Wi-Fi, Ethernet, Cellular, ATM, Bluetooth, dial-up modems, and so on aren’t the same. They might vary only slightly, or they might vary significantly. This situation could make our life quite complex. After all, how are we to know the minute details of each bit that makes up the control fields of a data link protocol? Even if we know them, how are we to choose the correct hardware and software to accommodate these protocol data units (PDUs)?

PPP helps in this task. It provides the procedure for detecting and interpreting certain (not all) data link protocols’ frame formats. Once again, these operations should remain transparent to you, but knowing this capability might be helpful to you someday.

Following is a list of other services that are part of the PPP platform. Check your network vendors to determine if these options are supported:

• Vendor extensions—Allows the support of a vendor’s proprietary procedures on a PPP link.

• Maximum receive unit—Allows the two parties to negotiate the size of the packet to be used during the session.

• Quality control—Provides a means for monitoring the quality of a link, specifically when and how often a link is losing a packet.

• Compression—Supports the compression of several of the control fields of a PPP packet.

• Loop back—Allows checking for a signal that is mistakenly looped back to its sender.

The Layer 2 Tunneling Protocol (L2TP)

PPP was designed for two endpoints to communicate with each other, such as in a point-to-point dial-up connection. The Layer 2 Tunneling Protocol (L2TP) extends PPP to operate between separate machines across one or more networks.

A tunneling protocol uses the concept of encapsulation, wherein one protocol’s contents (its packet) are placed (encapsulated) inside another protocol’s packet; the latter is called the delivery protocol. Tunneling is quite useful if traffic needs to be sent through an incompatible network or it needs to be placed on a secure path (a tunnel) for transport through a nonsecure, perhaps untrusted network.

For this explanation, PPP packets are encapsulated within L2TP (see Figure 8.2). A user dials in (or is connected through a broadband link) to an L2TP Access Concentrator (LAC). This machine, which could be a vendor’s network access server, is usually the initiator of the tunnel. The telephone connection isn’t carried through the Internet; the physical call is terminated at the LAC.

FIGURE 8.2 L2TP configuration

The LAC is responsible for configuring the tunnel; it builds tables for passwords and makes contact with an appropriate machine to form the other end of the tunnel (where the other party is located). This other machine is the L2TP Network Server (LNS). It’s the server side of the tunnel; thus, it waits for calls (and new tunnels). After a tunnel is set up, the traffic moves bidirectionally between the two parties. These operations are part of the services of a virtual private network (VPN). Other VPN services are covered later in this hour.

When a network user accesses the ISP access server (the LAC), the ISP uses CHAP to challenge the authenticity of this user, an important part of the overall operations of PPP and L2TP. After the user is authenticated, the LAC undergoes operations to place the user’s traffic onto an existing tunnel (using parameters and identifiers the user furnishes), or, if needed, create a tunnel for this session. A tunnel is identified with a tunnel ID, and sessions through the tunnel are identified by a session ID.

Again, security is of the utmost concern when using PPP and L2TP. Thus, CHAP and yet another Internet standard, RADIUS (Remote Authentication Dial-In Service), are instrumental to running a secure network. We leave this subject for now and return to it in Hour 20.

Ideas for Enhancing Dial-In Security

For the subject of remote access, following are several measures you can take to enhance your network’s security:

• Ensure that the system logs all incoming calls and login attempts. This procedure can help locate users who are trying to guess passwords.

• Limit login attempts to three or fewer, and lock out any user who hasn’t produced a correct password for a given user ID after repeated unsuccessful attempts to log in.

• Use access tokens in addition to user IDs and passwords. Access tokens are particularly difficult to crack because anyone logging in must have access to a known and trusted user token in addition to a valid user ID and password.

• Change the PPP settings so that the remote user has a secure login. Security protocols such as CHAP can help secure the login process.

• Encourage (force?) users to change their passwords frequently.

No matter how secure you make your network, never cease trying to make it more secure. Security is a process, not a destination.

Using the Internet for Remote Access: The VPN

In the past, dial-up strategies were the only method of establishing a remote connection with a private LAN or WAN. The Internet now provides users the VPN. A VPN is a secure connection established over the Internet between a remote user and, say, a corporate network. The VPN is a conduit (a tunnel) that moves private data across the public Internet, a concept shown in Figure 8.2. To take advantage of VPN for remote access, an organization provides for the appropriate infrastructure:

• Invests in a contract with a national or international dial-up ISP to provide local dial-up phone numbers.

• Provides cable modem or DSL service to users who require high-speed remote access. Indeed, migrating away from conventional dial-up service will lead to more productive operations for all concerned.

• Sets up server/VPN hardware between the organization’s network and the Internet to authenticate users using VPN software. Manufacturers in the networking business sell VPN hardware and software and provide extensive training for their customers. If your network is going to have users spread out over a wide part of a country or globe, you’ll likely need assistance from specialists, because the configurations of the remote networking machines can be involved and complex. Take advantage of the expertise of your vendors’ staffs; before long, you’ll be able to take over and run the operation on your own. If you don’t want to become involved in this level of detail, talk to your vendors about service contracts to help you manage the network.

Again, networking vendors are well acquainted with interworking their VPN hardware and software. You might discover that using the Internet instead of building your own network is less expensive and less complex.

If your organization is set up to do everything locally, dial-in servers that manage PPP connections and authentication are an effective way to ensure effective security on your network. But if you have users who are far apart—from Boston to San Francisco, for example—you might consider using the Internet as the media to connect your remote offices.

VPN offers more flexibility than users trying to dial in to the company network. Although both dial-in remote access and VPN require a remote access server to authenticate remote users to the corporate network, dial-in requires corporate modem pools to service dial-in customers. In the case of a VPN, the only additional hardware that needs to be deployed is the L2TP LACs and LNSs. (For a large enterprise, you might also want to bring in RADIUS servers, a topic for Hour 20.)

With this setup, any user in the world who can connect to the Internet can access the corporate network. Of course, this user must have a username and password that will allow a connection through the VPN remote access server. Cisco Systems, Microsoft, and a host of others provide VPN software that uses IPSec (IP security) for authentication and security. In the long term, this might prove to be the most efficient method for providing remote users access to secured networks.

In the case of Microsoft’s various server products, VPN server capabilities are built into the Network Operating System’s (NOS’s) Remote Access Service (RAS). Figure 8.3 shows the RAS snap-in that’s part of Microsoft Windows Server 2003, which is used to manage and configure VPN access to the LAN.

FIGURE 8.3 NOSs, such as Microsoft Windows Server 2003, provide utilities for configuring and managing VPNs.

Remote Access Hardware: Build or Buy?

Even though Internet-based remote access is becoming increasingly common, some organizations will build their own remote access solutions. The following discussion deals with the ramifications of doing so and provides some insight into what’s involved in building a robust remote-access architecture.

Remote access hardware comes in various options from numerous manufacturers. It would be pointless to attempt to list them all here. Instead, this section focuses on the build or buy question that faces people who have to purchase and deploy remote access solutions.

Whether to build or buy a remote access solution is a difficult question. The answer depends on a variety of variables, including your company’s size, how fast your company is growing, how many people will be using the remote access system, and how easy or difficult it should be to upgrade.

The process of selecting hardware for a user base that is growing by leaps and bounds has been compared to buying clothes for a child. By the time you bring the clothes home and get the child dressed, more often than not, the kid has outgrown them. Alternatively, if the clothes do fit, the child doesn’t like them and won’t wear them. Over time, a rule of thumb—somewhat of a joke, but not entirely—has emerged for remote access equipment: Figure out how many simultaneous users you’ll have, and then at least double that capacity (unless of course, you aren’t in a growth industry. The current real estate market comes to mind).

Building a Remote Access Solution

If you have only a few users, it’s possible to create a remote access solution based on connecting two or more modems to a server computer. Most server operating systems offer solutions for remote node access, including Microsoft’s Remote Access Service (RAS) and Novell’s NetWare remote connection services. UNIX and Linux distributions also provide remote access services.

These systems offer several positive attributes, including the capability to use an operating system’s built-in security and login handling. Typically, home-built remote access systems provide fine performance at a reasonable cost. The downside of building your own remote access server solution is that it can be difficult to support if you have a problem. All too often, the operating system vendor blames a problem on the multiport card vendor and vice versa, which gets you nowhere.

Buying Turnkey Remote Access Solutions

The alternative to building a remote access system from standard hardware and parts is to purchase a dedicated system. Dedicated systems usually don’t follow conventions and might or might not interface directly with your operating system. In spite of their proprietary architecture, or nonstandard vendor-dependent designs, many of the dedicated remote access solutions available in the market offer great value for what they do.

In the case of VPN, some companies also provide VPN hardware, including Cisco and Nortel. In the case of Cisco, an entire line of VPN routers is available that provides data encryption and a web-based device manager. Many of the VPN routers available are deployable right out of the box and provide a good alternative to attempting to deploy VPN as a service of a particular NOS.

Summary

In this hour, we discussed what remote access is and why it has become so important over the past several years. PPP was highlighted because of its wide use. L2TP was also examined because of its increasing use. The hour concluded with an analysis of the alternatives for deploying a remote access system.

This is the end of Part II of this book, “The Basics.” You should now be familiar with fundamental network concepts. Part III, “Building Networks,” provides guidance on building a network, starting at the planning stages, and winding up with the system that will take care of your networking needs.

Q&A

Q. What is a remote node?

A. It’s a computer connected to a host system, such as a mail or file server across a communications link or a network.

Q. Which protocol is commonly used for remote node communications?

A. The Point-to-Point Protocol (PPP) is often used for remote node communications.

Q. The PPP was designed for dial-up links. Will it operate over dedicated DSL?

A. Yes, as long as the link is up and running, PPP doesn’t care if the link is dial-up or dedicated.

Q. Why use L2TP?

A. PPP was designed to operate over a conventional dial-up link, not through a network or networks. L2TP extends the capabilities of PPP across internets and the Internet.

Q. What is a virtual private network (VPN)?

A. The term virtual private network is used in two contexts. In the first, it means the use of a public network whose throughput and response time performances give the user the illusion he’s using a highly tuned network—that is, highly tuned to this user’s needs but without extensive security or quality of service (QoS) operations. In the second context, it means the use of a public network whose access and egress nodes provide extensive secure communications services (at a minimum) to the user.