Moving Beyond Basic Access: VPNs and LAN Extension

I have mentioned VPNs previously and have identified them as key service offerings for
addressing the business community. Many enterprises, both large and small, choose to set
up VPNs on their own without any service provider intervention, but the smallest businesses
frequently lack the in-house expertise to manage a VPN, and, in such cases, the service provider
can offer the provisioning of a VPN as a value-added service. Increasingly, broadband
service providers are doing so, and the wireless broadband operator who hopes to compete
successfully in today’s access market must be prepared to meet this need.
Here perhaps a bit of history is in order: VPNs arose out of the understandable desire
on the part of organizations with geographically distributed offices and operating centers to
provide branches with full access to the centralized databases at the corporate headquarters
and thus to avoid having to duplicate network resources at each location. Up until the late
1990s, wide area enterprise networks were generally connected through leased circuit connections
such as T1s or DS3—inevitably an expensive proposition when multiple locations were
involved, particularly where any-to-any connections were mandated. Alternately, ATM or
frame relay virtual circuits could be used with nearly equal reliability and at substantially lower
cost, though frame relay did not scale well when multiple remote locations were involved. Any
of these legacy connectivity technologies provided a high degree of service reliability and consistency
as well as a fair measure of inherent security, but the pricing of such services was such
as to place them out of reach for many businesses.
VPNs, even in their developmental stage, took a number of forms. VPNs could be
restricted solely to the branch locations of a single business or governmental agency, in
which case they were known as intranets, but many enterprise managers chose to extend them to close business partners, particularly those with whom they had ongoing relationships
and with whom they performed frequent transactions. If a trusted contractor were making
daily claims on the resources of a company, it made sense for the host company to eliminate
bureaucratic processes as much as possible and allow the contractor direct access to relevant
databases. When such an outside party was involved, the VPN would then be termed
an extranet.
As a VPN grew to encompass organizations outside the individual enterprise that had originally
set it up, the problems in administering it grew as well, because at that point network
administrators had to deal with two or more sets of internal IP addresses, some of which may
overlap. They may also have to deal with various multicast groups, each of which would receive
certain information intended for it alone. Worst of all, administrators, because of a flurry of IP
standards activity, faced difficult decisions as to which standards-based approach to implementing
VPNs would best meet the needs of their operations. Accordingly, at the time of this
writing, VNP administration has become almost a discipline unto itself.
Any complete discussion of VPN setup and administration goes far beyond the scope of
this book, but I will outline the basic approaches and indicate where they are apt to produce
the most satisfactory results. The following sections consider the practical implications of VPN
administration from the service provider perspective and in particular how to make a business
out of supporting VPNs.