Looking at basic connectivity may seem to be an obvious starting point, but it is often the single hardest piece to get correct. With so many options for the local loop--including DSL, cable modem, ISDN, modem and leased lines to a local ISP--the level of configuration and troubleshooting available varies greatly. Making sure you have a stable local loop is only half the battle, and tools such as Ipswitch's WhatsUp Gold can check uptime. Making sure you have adequate bandwidth end to end is another. If your remote offices and central offices are on the same provider's network, you will have an easier time addressing bandwidth issues, because the cloud is owned by one company.

Once you cross ISPs, however, peering relationships put all bets off. Checking performance can be as simple or as complex as you require. Common tools such as ping and traceroute can provide a lot of information about the intervening network between sites. When run at different times, these tools will give you a daily profile. More robust tools, such as NetIQ Corp.'s Qcheck, provide connectivity checks, as well as end-to-end performance statistics between two endpoints. But performance is more than just raw throughput. Not only do you have to ensure you're getting the bandwidth you purchase, you need to keep an eye on latency as well. Latency from end to end can kill streaming media, VoIP (voice over IP) and other latency-sensitive applications, such as database replication.

Out-of-Band Management

Regardless of your connection type or ISP, having an in-bound dial backup for out-of-band management is crucial. For example, there are lots of cases in which a configuration on a router can cut you off. We lost connectivity while configuring a router interface we had telnetted, requiring us to get physical access via a console cable. Likewise, when configuring a set of firewall or VPN (virtual private network) rules, you can lose your connection. Additionally, if remote offices are connected via ISDN, DSL or cable and receive dynamic addresses, the only way to manage them remotely is through an external, analog modem.

Although access via a modem is not the speediest route, it will get you through when all other connectivity goes down. Don't be chintzy with a bargain-brand internal modem, which is good for surfing but requires the PC to be running. Plus, you will have to have a server ready to make the connections for you.

Besides, an internal modem can't easily be moved from location to location--if the desktop hangs or gets shut down, you're out of luck. Most routers have external comm ports available for dial backup. Sticking an external modem on one of those ports makes sense. As long as the router and modem are on a UPS, chances are good you can still connect even when the power is out.

Pick up a good external modem, such as a U.S. Robotics Courier External V.Everything or similar model. The Courier is a good choice because of the wide variety of protocols it uses and its external DIP switches, which can be used for configuration. Some network equipment, such as Cisco Systems and 3Com Corp. routers, can configure a modem through a script, so the requirement for hardware configuration is not as pressing.

Not all network equipment has this capability, however. If you can't configure the modem externally or through the network equipment, you will probably have to connect the modem to a computer, set and save the configuration through a terminal program and then reattach it to the router. If the configuration is erased from the NVRAM (nonvolatile RAM) in the modem (which inexplicably happens often), your modem is pretty much useless until reconfigured.

Regardless of what you connect your modem to, make sure you have adequate security on the server that is answering the call. Don't count on a phone number, even if it is unlisted, to hide your modem. War dialers (programs that call numbers looking for modems) are still very much in use, and unprotected modems offer easy ways into the network. Follow the guidelines for choosing good passwords and, if possible, use an authentication protocol, such as CHAP (Challenge Handshake Authentication Protocol), so the password never gets transmitted in the clear. It's also a good idea to install caller ID on the line so you can track incoming calls and deny calls from phones that block caller ID. (This is usually a free service.) For stronger security, you can use a pair of encrypted modems, such as CryptoCom V.34 modems from Western DataCom Co.

An Open Door

Regardless of whether your remote sites are connecting directly to the home office or connecting to the Internet, having security (at minimum a firewall) at those sites is important. Without security, a remote site becomes a pathway into the home office. Many firewalls, such as the Nokia/ Check Point Software Technologies VPN-1 Gateway, encrypt management sessions, which is useful no matter where your firewall is located. Products from Cisco and NetScreen Technologies require you to use the VPN client for encrypted management. Be sure to check that your firewall can be configured from both the internal interface and the external interface.

If you can configure the firewall only from the internal interface, you will have to get into the network before you can manage it. For example, the NetScreen-100 has the option to deny management from the external interface.

Firewall rules should be in place for both inbound and outbound traffic. Firewalling inbound traffic is obvious, but firewalling outbound traffic restricts activity coming from the remote site, and if a malicious person is on the remote network, it denies the intruder full run of the internal network.

Setting up the VPN takes a little thought. Depending on the VPN products you are using, you may have to touch each VPN device individually to configure the parameters. There are two major problems with this. First, if your management station is behind a VPN gateway, which is typical, you will have to ensure the management connection can pass through the VPN gateway. This is usually accomplished by a policy rule wherein you can specify that communication between the management station IP address and the individual remote VPN gateways passes in the clear. Make the rules as specific as possible by stating in the policy rule the public IP addresses you will be managing.

Once you have established connectivity between your management station and the remote VPN gateways, you can begin to build the VPN between sites. At this point you need to be aware of how VPNs are built using the vendor's management application. Some management applications let you build the VPN and then push the configuration out to the gateways. This allows you to specify the desired parameters. The management application figures out the individual configurations for each device and sends them automatically. This is by far the best configuration model for VPN management--brought to you by Check Point Software, Lucent Technologies and VPNet Technologies--because you make the VPN definitions once on a per-VPN basis.

The other configuration model requires you to set up identical configurations on each VPN device. Not only is this method time-consuming and tedious, but there is a very real possibility of cutting yourself off. For example, if you configure your local VPN gateway first, it may not pass traffic, because it will try to encrypt the traffic first. Alternatively, if you configure the remote ends first and there is a mismatch in the configuration, you may not be able to access the remote gateway. In either case, having that modem installed will give you a workaround if you need it.

Nonroutable Addressing

Because of the cost, it does not make sense in many cases to purchase routable Internet addresses for each of your remote offices. Unless you're offering services to the Internet at large, the extra expense is unnecessary. The alternative is to use nonroutable addresses and hide them.

NAPT (Network Address Port Translation) is commonly used to hide nonroutable addresses from external networks. This is handy if you don't want to pay your ISP for subnets. You can use any of the reserved address spaces (that is, 10.0.0.0, 172.16.0.0 and 192.168.0.0 ranges from RFC 1918) for private intranets. These addresses are nonroutable on the Internet. However, using NAPT, users can still work as normal. NAPT allows connectivity only from the private network to the public network.

NAPT works by mapping the source IP address and port number on the private side to the NAPT public IP address and another port number on the NAPT device's external interface. NAPT has been a boon to companies that can't afford to purchase valid network blocks from their ISPs, as well as to companies that picked their address ranges at random in the early days of IP networking but never registered the blocks. An ugly kludge it may be, but it works. NAPT devices can direct inbound connections from the public network to the internal network through port redirection, but that has to be preconfigured. For example, if a company wanted to host a Web server in the internal network, that company would tell the NAPT device to redirect any connections to Port 80 to a specific host in the internal network at Port 80.

You can purchase multiple hardware and software devices to provide remote connectivity, NAPT, firewalling and other essential services, but that means having to manage multiple devices and ensure they are all interoperating together.

We have seen a lot of consolidation of functions on SOHO (small office/ home office) networking devices, so getting connectivity, NAPT and VPN in one package is common. Of course, if you are using NAPT with a dynamic IP address, out-of-band management is required.

Send your comments on this article to Mike Fratto at mfratto@nwc.com.