Connecting Multiple Computers to Cable Modems

Phil Karn, KA9Q
28 April 1999 Updated 17 May 1999


This document addresses some of the issues involved in hooking up more than one computer to a cable modem. This is mainly about Time Warner's Road Runner cable modem service, but much is also applicable to other cable modem providers such as @Home and Media One, and to ADSL providers and even conventional ISPs. Comments and suggestions are always welcome.

A Word About Servers

May people who want to connect multiple computers to their cable modems also want to run servers on one or more of those computers. In general, running a public web or FTP server on a cable modem is a Very Bad Idea. Cable modems operate on shared bandwidth, and the upstream capacity on these networks is often much less than the downstream capacity, often by a ratio of 35:1. A single popular server can hog the upstream channel and significantly worsen performance for the other users who share it. It will also attract the attention of the cable modem service provider, who may well disconnect your service.

Not every server is bad. If you run a personal SMTP server that merely collects your incoming email, you're actually doing the cable company a favor. You reduce the load on their mail servers without increasing the load on the cable network. (This assumes you've disabled SMTP relaying, which everyone should do to prevent their SMTP server from being abused by spammers.)

An enlightened cable company should also have no objection to running Telnet, FTP or SSH servers for personal use, such as remotely accessing your computer when you're away. Just keep the traffic reasonable.

Connecting Multiple Computers - The Alternatives

There are several ways to share a cable modem among more than one computer. Here are those I can think of, with a discussion of each. If you'd like just a simple summary of the pluses and minuses, click here to skip ahead to the summary.

Swapping the Ethernet cable

You can simply unplug the Ethernet cable going to the modem from one computer and plug it into the other. This is obviously the most expedient thing to do in a pinch, such as when you're visiting a friend with a cable modem and you want to plug in your laptop for a few minutes.

It goes without saying that any special software required by the cable network must be installed on any computer that is to connect directly to the cable modem. For Road Runner, this includes a DHCP client and the Road Runner login program. @Home requires neither program, so you need only configure the second computer with the same IP settings as the first.

You must generally reset the cable modem each time you swap computers. The Motorola CyberSURFR cable modem (or possibly the head-end cable router) appears to enforce the limit on the number of connected computers by memorizing the first client Ethernet link-level address it sees at startup and only allowing packets from that address. In the Road Runner systems, additional computers may be able to obtain IP addresses (i.e., DHCP will succeed) but attempts to actually use those addresses will fail.

Some cable modem services hardwire the customer's Ethernet address into their databases, and a call to customer support is required to change it (some MediaOne systems reportedly do this). The most expedient way to change computers (or Ethernet cards, for that matter) on such a system is to configure the new system or Ethernet card to use the same Ethernet link level address. I don't know if this is possible in Windows 95, but it is easy to do in Linux and BSD. In Linux,

$ ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:60:97:AD:10:55 inet addr: Bcast: [etc]

shows the link level (hardware) address of interface eth0, and

# ifconfig eth0 hw ether 00:60:97:AD:10:55

sets it to the specified value. You must do this before the interface is activated, e.g., with a DHCP client.

Paying for Additional IP Addresses

Some cable modem providers will sell you additional IP addresses for an extra monthly charge ($5 in the San Diego Road Runner system). You may then plug your computers and the cable modem into a 10Base-T Ethernet hub and simultaneously access the net from each computer. As in the manual switching case, you must install any necessary access software (DHCP client, login software) on every computer that is to use the cable modem.

This is a simple approach, but beyond the extra monthly charge it can have some serious limitations. On the San Diego Road Runner system, IP addresses are dynamically allocated from several noncontiguous blocks, and the addresses assigned to your computers are not necessarily on the same IP subnet. This means your computers may have to talk to each other by way of the Road Runner system even though they're plugged into the same hub!

Even if the assigned addresses are on the same IP subnet so that your computers can talk directly to each other, Road Runner may go down. If it stays down for a while (as it often does), the leases on your IP addresses may expire and your computers will stop talking to each other. This problem is exacerbated by the short lease period typically used, only 1 hour on the San Diego system.

For those running Windows systems whose only need for local communications is file sharing, some users recommend using the NETBIOS or IPX protocols for this purpose. Both run directly atop Ethernet without using IP addresses, so it is immune to the problems just described. Because Road Runner cannot route these protocols off your physical LAN, this also has the side benefit of improving security by making it impossible to access your file servers from the outside.

Relay Computers

The next three methods all use one of your computers to relay traffic between the cable modem and your other computers. They are:

  • Network Address Translation (NAT)
  • IP-in-IP tunneling
  • Application gatewaying

    You may not even need an Ethernet hub if you only have two computers. You can add a second Ethernet card to your relay computer and then connect one interface to your cable modem and the other to your second computer, using a "crossover" cable for the latter connection. Even if you do have a hub, you may still wish to dedicate an interface on your relay system to the cable modem. This can improve security (by isolating the cable modem from your LAN) and performance (by not having all the data to or from a user machine pass over your LAN twice.)

    These three relay techniques share several significant advantages. You only need one IP address from the cable company. You can use fixed IP addresses on your LAN to avoid the hassle of dynamic addresses on arbitrary subnets that may change arbitrarily or go away when the cable network goes down. This is especially important if you use your machines as local servers for each other. For NAT, the fixed local IP addresses can be in a private address block as specified in RFC 1918. In the case of IP-in-IP tunneling, you use globally unique IP addresses.

    The main disadvantage of all three relay approaches is that you have to leave the relay machine up and running for the other computers to access the cable modem. The relay system need not be dedicated to the task; it's easiest if the relay functions can be performed on a machine you'd leave on anyway. Many people who run Windows on their primary computers resurrect their old dusty 486s or slower Pentiums, bring up Linux and use them as dedicated relays. Still, this consumes electricity and generates noise.

    Network Address Translation

    NAT, also known as IP masquerading, works as follows. When the computer acting as the NAT relay between the LAN and the cable modem receives a packet from a local computer destined for the outside Internet, it replaces the source address in the IP packet header with its own address and the source port in the TCP or UDP packet header with another value chosen out of a local pool. It then recomputes the appropriate header checksums and forwards the packet to the Internet as if it originated from the relay host using the IP address assigned to it by the cable modem service provider. When reply packets from the external Internet are received over the cable modem by the NAT relay, the original IP source address and TCP/UDP source port numbers are written into the destination fields of the packet (since it is now moving in the opposite direction), the checksums are recomputed, and the packet is delivered to its true destination. This is possible because the NAT relay keeps a table of the IP addresses and port numbers of the local systems currently using it.

    NAT is very popular, and it works very well for many people. But it is not without problems. The most important limitation is that every computer on the LAN that uses a NAT relay must, without exception, originate every transaction to the external Internet. In other words, computers on the LAN behind the NAT relay can only function as clients; it is impossible to access a server running behind a NAT relay from the outside Internet (though one may run on the NAT relay itself, using the IP address assigned to it by the cable service provider.)

    Another problem with NAT appears when application protocols pass IP addresses to their peers. Because the applications are unaware that NAT is in use, the IP address sent from behind a NAT relay may not be the one seen on the connection by the recipient. The most common offender in this regard is FTP, the file transfer protocol, where by default the FTP server opens a TCP connection to the client for each data transfer. Fortunately there exists a "passive" command in the protocol that tells the server to allow the client to open the data connection to the server. This must be used whenever a FTP client connects through a NAT relay.

    Additional problems appear with NAT when a transport protocol other than TCP or UDP is used, because the NAT relay may not be able to translate its port numbers (or the protocol may not even have port numbers at all). This problem is most serious with the new IP Security Protocol (IPSEC), where all transport layer information is encrypted and thus inaccessible to the NAT relay. If IPSEC is to be used in conjunction with NAT, the IPSEC end point will have to reside on the NAT relay system itself. NAT is not a barrier, however, to encryption schemes that operate above the transport layer, such as SSL (secure web pages), SSH (secure login and file transfer) and PGP (secure email).

    NAT is already incorporated in the Linux kernel, although it may have to be recompiled to enable this option. Here are links to pages with information on how to use this feature in Linux:

    Several NAT packages are available for Windows platforms. I do not have any personal experience with them, as I cannot understand why anyone would pay good money for proprietary software when the same feature can be had for free in open source software that is invariably of higher quality. But if you don't want to do this, a list of many different NAT products for Windows can be found on The NAT Page.

    IP-in-IP Tunneling

    An alternative to NAT is IP-in-IP tunneling or encapsulation. In this scheme, each packet from the LAN to the outside Internet is wrapped inside another packet by the relay system that is addressed to a system on the external Internet that can unwrap the packet and send it on its way. Encapsulation escapes the problems with NAT described above; it is the best way to provide all the computers on your local network with static, globally routeable IP addresses while using only a single dynamically allocated address from the cable service provider.

    Once again, the necessary features are provided in Linux; see my earlier essay IP-in-IP Tunneling Over Road Runner With Linux for the details.

    On the downside, an IP-in-IP tunnel is significantly harder to set up and maintain than a NAT relay, an external system to serve as the tunnel end point is required, and performance can be less because of the extra packet header overhead and suboptimal routing that must always include the tunnel system.

    IP-in-IP tunneling also aggravates the Path MTU Black Hole problem. Although the fault is actually in the configuration of the servers and firewalls you're (trying) to reach, it may be easier to work around the problem locally by lowering the MTU (maximum transmission unit) on the network interfaces of your computers behind the tunnel relay machine by 20 bytes to allow room for the extra IP header added by the encapsulation process.

    This is simple and straightforward with Linux, which allows the MTU to be specified on a per-route basis in the routing table, e.g.,:

    $ route add default dev eth0 gw mss 1480

    TCP connections using the default route will ask their peers to limit the size of the packets they send to 1480 bytes (the normal limit for Ethernet is 1500), and they will also limit the size of the packets they send. (Note the use of the term mss in the route command when mtu is properly meant; this is a minor goof in Linux). The TCP maximum segment size (mss) actually used on a connection will be 40 bytes less than the MTU to allow for the IP and TCP headers, or even smaller if header options such as TCP header timestamps are used.

    Application Gatewaying

    Some important applications can be handled by running an application layer gateway on the relay machine. Clients on the local network are configured to talk to the servers running on the application gateway system, which in turn establishes its own connections as necessary to the outside world.

    SMTP, POP and HTTP are the protocols for which this is most easily done. Popular mail and web clients such as Eudora, Netscape Navigator and Internet Explorer all support the use of gateway servers. For SMTP and POP, servers such as sendmail, qmail and popper are universally used on Linux, BSD and UNIX systems.

    HTTP (web) transactions can be gatewayed through any of several caching web proxy packages, such as squid. An alternative is my own httproute package, written in Perl. It is not as efficient as Squid, but in addition to web caching it provides additional features such as HTTP routing, banner ad blocking and cookie cutting. Both squid and httproute are open source software designed for UNIX, BSD and Linux.

    Running your own caching web proxy has the advantage of allowing your local users to share copies of web objects that would otherwise be downloaded more than once over the cable modem to the different computers on your local network.

    Application gatewaying can be used in conjunction with NAT or IP-in-IP tunneling; the application protocols not gatewayed can be NATed or tunneled.

    I understand that similar functionality is available for Windows systems with after-market packages, but again I see no reason to pay for something I can get for free in an open-source operating system. One such gateway product for Windows is Wingate.


    Swapping the Ethernet cable

  • Expedient for temporary use, e.g., when visiting a friend's house with your laptop. No extra hardware (such as an Ethernet hub) is required.
  • Obviously, only one computer can use the cable modem at a time.
  • All computers must run whatever software is required by the cable provider to log in.
  • It may be necessary to reset the cable modem each time the swap is made, or in some cases to configure all Ethernet cards to use the same Ethernet address.

    Buying extra IP addresses from the cable company (if available)

  • Simple and expedient; you just get a 10Base-T hub and plug all your computers into it along with the cable modem.
  • Each computer operates independently; there's no need to leave one particular computer on all the time so another can access the net.
  • The monthly cost of the extra IP addresses.
  • The IP addresses you're assigned may not even be on the same IP subnet, making it difficult for the computers on your LAN to communicate locally.
  • If the IP addresses are assigned dynamically with DHCP, they may expire if the cable network goes down for an extended period, interrupting your local connectivity.

    Network Address Translation (aka IP Masquerading)

  • No extra monthly costs; all your computers look like a single computer to the cable company.
  • Relatively simple to set up; the necessary support is already included in Linux and several other open source operating systems.
  • You can use static IP addresses within your LAN, simplifying local communications and making them immune to cable network problems.
  • The relay computer must be up and running whenever a client system wishes to access the external Internet.
  • No external access to servers running behind the NAT relay (though the NAT relay itself can run externally accessible servers).
  • Problems even with some client applications that transfer IP addresses in the application layer protocol, e.g., FTP (use "passive" mode).
  • Inability to support certain transport protocols that either lack the notion of "ports" at the transport layer, or encrypt the transport layer headers so the NAT relay cannot translate them.

    IP-in-IP Tunneling

  • The "purest" approach to the problem; every computer on the LAN can have its own static, globally unique IP address even when the cable modem provides only a single dynamically allocated address.
  • Servers can be reached from the outside Internet.
  • Transport protocols like IPSEC can work normally.
  • Both the local and remote tunnel systems must be running whenever a local computer wishes to use the cable modem.
  • Relatively complex setup.
  • Need for a tunnel peer on an external network.
  • Aggravation of Path MTU Black Hole problems.

    Application layer relaying

  • Avoids some of the problems with IP-in-IP tunneling, such as the need for a remote tunnel system and the Path MTU Black Hole problem, and with NAT, such as the use of IP addresses in application layer protocols.
  • Can provide extra application-level functionality such as web caching.
  • Like the NAT relay and the IP-in-IP tunnel, the local relay system must be up to support local computers wishing to access the outside network.
  • A separate relay program must be provided for every application.
  • Loss of end-to-end integrity checks.
  • Each local client system must explicitly configure its applications to use the gateway system.