Archives ||  About Us ||  Advertise ||  Feedback ||  Subscribe-
Issue of August 2002 
[an error occurred while processing this directive]
 Home > Focus - VPNs
 Print Friendly Page ||  Email this story

Focus: VPNs
VPN considerations

VPNs are the most common means of ensuring secure connectivity between diverse locations. A look at the implementing VPN services in the enterprise. by Graeme K. Le Roux

As the name suggests, a VPN (Virtual Private Network) is a network within a network based on the simple premise that the payload of an IP datagram can be anything including another IP datagram or even a packet from a lower ISO/OSI layer.

If you simply pick such a payload up from one location, wrap it in an IP datagram, carry it via normal mechanisms to another location and unwrap it, then the payload will act exactly as if the two locations were connected in a more traditional manner i.e. via a leased line, or an Ethernet network.

There is a useful side effect of this method of transport the payload of an IP datagram does not interact with the network carrying it. For example, you don't expect a Web page that you are downloading to interact with the TCP/IP session carrying it. The reverse is also true a router in an IP internetwork doesn't make routing decisions based on the contents of a particular datagram's payload.

Of course if you wrap an IP datagram in another IP datagram, you end up with two complete and distinct sets of IP headers including all the option fields, etc. which effectively doubles your network overhead. If given reasonable network capacity this is tolerable in most cases. However, care has to be taken when running VPNs over analogue modems. You also incur some extra processing overhead if you try to run a VPN between older hosts.

In the case of VPNs in a TCP/IP environment, the most interoperable way of implementing VPNs is via IPSec operating in tunnel mode. There is another IPSec mode called transport mode which is intended for a direct connection between two hosts rather than for connections which have to pass through gateways. Tunnel mode can be used between two hosts. In fact, this is one of its more important uses as this is usually how a remote host uses a VPN over the Internet to access a network, with teleworking being the most common example.

What kind of VPN do you need?

An IP VPN is commonly defined as a routed link between two or more points across a heterogeneous network topology, with various degrees of security that ensure privacy for all parties. The idea behind the IP VPN is to leverage on the Internet's reach and low cost, in order to eliminate the more expensive dedicated links common today.

You can set up VPNs in several ways, but Customer Premises Equipment (CPE)-based IP VPNs and network-based IP VPNs are the most common approaches. The difference lies in the network architecture: In CPE-based VPNs, the routing intelligence resides at an end-user site, while in carrier-based VPNs, it resides at the provider's edge, where it can be extended out to many end-user locations.

There are three types of VPNs. First, remote-access VPNs allow telecommuters or home workers to access their corporate data networks. Second, site-to-site VPNs connect remote offices over the Internet. Site-to-site VPNs use secure point-to-point connections in a mesh topology overlaid on the Internet, or even on a single provider's network.

Third, extranet VPNs connect a "community of interest," such as a company, its partners, suppliers, and customers, and so on, to an enterprise network and perhaps other relevant destinations.

In extranet VPNs, an authorized third-party user arrives at the enterprise firewall after traversing the public network, and the destination (often the home office) VPN gateway terminates the traffic and grants trans-firewall access where appropriate.

When it's time to engineer your VPN, you need to consider many issues, such as the timeline for deployment and what applications the VPN will serve.

For intranet and extranet users, you need to consider what type of data is involved and whether you ought to set priority levels based on the type of traffic. You also need to know the number of users, how many classes of users you have, and what specific restrictions apply to these user groups. Consider also the type of resource access to grant, as well as assigning QoS levels.

Next, decide whether to use a CPE- or network-based solution. Each approach has pros and cons, but remember that most first-generation network-based solutions encrypt data only from service provider edge to service provider edge the access link isn't secured.

It's also possible for service providers to install devices they own and control on the customer premises. Alternatively, some software overlay VPNs offer a mix of CPE- and network-based equipment or service options.

Another common usage of the IPSec tunnel mode is to connect two physically separate IP networks that use private addresses across the public Internet.

Consider two networks which have one router each and where each router has a single physical connection to the Internet and a single physical connection to their respective LANs. Because we are using private addresses in each LAN, the routers have to perform NA(P)T (Network Address and Port Translation) to provide Internet access for all hosts on each LAN. By implementing IPSec on each of these routers, they can act as in IPSec terms Security Gateways (SGs).

We can now establish an IPSec tunnel between the LAN interfaces of each router and thus avoid the need to perform NAT (Network Address Translation) on traffic flowing between the networks. In most cases (Windows VPN services being an example), such IPSec tunnels are implemented as a Virtual Network Adaptor to which a separate IP address is assigned.

This way, each router's single LAN interface has two IP addresses one for direct access to the Internet via NA(P)T in the normal way, and a second for apparently direct access to the remote LAN. At each site the local IP address for Internet access remains as the LAN's default gateway, while the local IP address for the VPN is advertised as the route to the remote LAN.

We can effectively restrict Internet access by simply advertising the IP address that gives Internet access only to those hosts which are permitted such access. This is easy to implement with DHCP. For example, you might set DHCP to provide the VPN's local IP address as the default gateway to all workstations while setting up your mail server to use the IP address for the Internet as its default gateway.

Note that if you have mail servers at both sites set this way, they would send e-mail between each other via the public Internet rather than the VPN. To avoid this, you could set up a secondary route for mail.

To try this sort of configuration, simply use Windows' built-in routing service and VPN capabilities, as well as a standard tracert utility. Later Cisco routers also provide a good platform for experiment. One caveat though: try not to experiment your alternate mail route on a live system.

We can force traffic between two networks across the Internet using simple NAT. But NAT can't provide privacy.

Just wrapping one datagram inside another does not disguise the content of the original datagram, or prevent someone on the Internet from intercepting it, reading it and even editing it and then forwarding it.

Obviously, if you are going to use the Internet as a backbone transport for your company network then this is unacceptable.

For this reason IPSec provides a standard framework to support encryption algorithms, from NULL (i.e. no encryption) to triple DES, IDEA, etc. It supports both symmetric and asymmetric (aka public key) algorithms. For the paranoid, you can use IPSec to encrypt every packet on your company network using a public key algorithm to ensure that only specific hosts can read the contents. The aggregate processing overhead would be huge, but it can be done.

VPNs that are based on IPSec are probably best used with higher bandwidth access services such as cable or ADSL. While VPNs can be used over Internet connections based on analogue modems, their processing overheads can be withering. Where a standard TCP/IP connection will incur about 11 percent overhead, a VPN will incur about 20 percent, or one-fifth of the available bandwidth.

If you are going to try this, consider very carefully just what types of data you want to transfer over your VPN. Text is best and heavy graphics is worst. In addition, the stronger your VPN encryption, the more CPU time your connection is going to use up. If you are using a laptop from batteries, this can mean not only slow application response but shorter battery life.

Selling VPN
VPN implementation tends to be a rather technical subject and is probably not something you can discuss the finer points with the company board. Fortunately, the business case for the use of VPNs is something which tends to be a lot clearer.

To present a case for VPN, first of all work out how many of your leased line services can be replaced with cheaper Internet access services such as ADSL or cable, as well as the cost of such links. Remember that you will need a fixed Internet IP address to enable you to establish a VPN.

This does not mean a static IP address range has to be allocated; it just means that whenever the session to any local ISP is reset, the IP's authentication server has to assign the same IP address to the new PPP (or PPPoE) session.

This is a software setting in most authentication schemes (RADIUS, TACACS, etc) and most ISPs will be happy to set it up for you. Next, you need to work out the cost of the security gateways you will need at each site. This may be a new box or an upgrade of an existing device. If all these are not significantly cheaper than your existing system, forget about using VPNs between your offices.

Follow that by doing the same sort of calculations for the teleworkers in your company, particularly those who take laptops home; using a VPN means you can assign a private address to a remote host.

This allows you to extend your security wall to the remote host-along with your security policies. In fact, if you can get a suitable broadband connection to the teleworker's home you can provide them with a Windows Terminal instead of a laptop. This will be cheaper and a lot more secure.

Using IPSec and a suitable encryption algorithm will also allow you to provide a much higher level of general security in your network. This is because VPN encryption keys can be easily and quickly changed in the event of a security breach, such as if a laptop has been stolen or an employee urgently sacked.

The swiftness afforded by IPSec means that there will be minimal impact on operations. Most companies will look favorably on anything that will allow them to provide clients with an assurance of greater data security and integrity, especially if it makes economic sense.

What you have
Another point in favor of VPNs in a Windows environment is that you already have most of the software required, since the basics are built into Windows.

If you use routers from any of the major vendors you may find that you have IPSec support built into your routers as well.

In fact, a good place to start a VPN deployment is with the management interfaces for your network; set your routers to accept management connections only via encrypted VPNs.

You can probably do this without board level approval, and when you have done it successfully you may find it easier to convince management to allow you to at least investigate applying the same technology to the rest of your network.

Graeme K. Le Roux is the director of Morsedawn (Australia), a company which specialises in network design and consultancy and writes for Network Computing-Asian Edition.

- <Back to Top>-  

Copyright 2001: Indian Express Group (Mumbai, India). All rights reserved throughout the world. This entire site is compiled in Mumbai by The Business Publications Division of the Indian Express Group of Newspapers. Site managed by BPD