How is a VPN implemented

7 Preliminary Considerations for Implementing a VPN

[Back] [Home] [Next]


7.1 Speed ​​and Performance

A network can only work effectively if all required data can be transported in an acceptable time. This essentially depends on the bandwidth. Mainly 10 or 100 Mbps networks are used within a LAN, typical bandwidths for Internet connections start at 64 kbps with an ISDN line and are limited on the upper side by 155 Mbps with ATM lines. Larger bandwidths are unusual or simply too expensive for private customers.

Encryption and authentication cost computing time. The stronger the encryption, the more computing time is required. With an ISDN connection, the loss of speed will hardly be noticeable. In typical configurations, the first bottlenecks are only to be expected from a bandwidth of more than 1 Mbps. Since very few companies have an Internet connection with more than 1 Mbps, they will hardly have to contend with performance problems or speed drops when using VPN. However, if you use a VPN in the LAN you have to think about what kind of VPN and encryption should be used. With software VPNs you should use your own VPN server, i.e. neither a firewall is installed on the computer, nor is it used as a router. For requirements over 10Mbps, you will no longer be able to avoid using a hardware solution. These can then process bandwidths of up to approx. 100Mbps, but the costs for such devices can quickly exceed € 50,000.

 

7.2 costs

The cost saving is a key argument for using a VPN solution as opposed to conventional leased lines. The savings in line costs can be determined very easily, one only needs to obtain appropriate offers from telecommunications providers. The costs incurred for hardware and software are more difficult to calculate. VPN solutions are already available as freeware (e.g. Free / SWAN, PGPNet); however, the price can also amount to some 10,000 €, especially with higher requirements.

A significant cost factor in VPN solutions is the possible bandwidth, which results from the number of users and the applications used. Software solutions are usually cheaper than their hardware competitors, but they are also less powerful (see chapter "Speed ​​and Performance").

 

The following types of costs arise for the implementation of a VPN [13]:

  • Hardware costs
  • Software costs
  • Internet connection costs (network costs)
  • Installation costs
  • Maintenance costs

 

7.2.1 Hardware costs

With a hardware solution, the VPN hardware itself will initially generate costs. Software solutions require one or more computers on which the VPN solution is installed. A modern PC with a Pentium processor and a clock rate of over 300Mhz should be sufficient for a bandwidth of up to 1 Mbps.

In addition, both types of solution may incur costs for additional routers or other more powerful network components such as switches, hubs, etc. An expensive VPN solution shouldn't be slowed down by an inferior or poor network architecture.

 

7.2.2 Software costs

In addition to the VPN software itself, there may be costs for operating system licenses, monitoring software for observing the VPN or analysis programs for evaluating the log files.

 

7.2.3 Internet connection costs

The costs for the Internet connection depend on the required bandwidth and the provider who provides the dial-in node. The costs for the leased line are calculated depending on the distance to the dial-in node. If only very small amounts of data are exchanged over the Internet, a normal modem connection (up to 64kbps or 128kbps) can also be used as the Internet connection. The distance to the dial-in node no longer plays such an important role, it should only be within a radius of 50 kilometers in order to be able to use the online tariff (as of autumn 2000). The advantage of leased lines is the quick connection setup and the flat-rate costs. With a modem connection there are costs for each dial-in.

If higher bandwidths are required, a dedicated line is the only option or, from a bandwidth of 1 Mbps, the use of ATM lines is also advisable. The line costs initially increase proportionally with the bandwidth, but with ATM lines the costs per Mbps fall again very quickly. The decline in cable prices is very rapid at the moment and this trend will continue in the future, so that it is difficult to give specific information here. In any case, however, different offers from regional and national providers should be obtained and compared.

 

7.2.4 Installation costs

Commercial products provide detailed installation instructions that allow non-professionals to install the VPN. Without sufficient knowledge, however, it can easily happen that you leave a security hole open. Therefore, if you have more complex requirements, you should definitely commission a company with the installation, if this was not already required in the tender.

With freeware products, the installation time is an important cost factor. The actual software is mostly free, but hours of searching for instructions and errors can make costs skyrocket. For commercial products there is usually a hotline or technical support that you can inquire about. With freeware products, you have to rely on FAQs, newsgroups and various websites.

One should not neglect the sufficient testing of the installation or the observation of the behavior of the VPN under heavy load at peak times. Security gaps or errors can still be revealed here that were not taken into account or noticed during the installation.

 

7.2.5 Maintenance costs

Once the VPN is stable, there are only low maintenance costs during operation. The control of the log files should be included in the ongoing security reviews. Costs only arise again if new services or computers are installed in the network. These must be included in the security concept prior to installation and appropriate rules set up or adapted in the VPN.

 

7.3 Compatibility

The compatibility of the various VPN products with one another can play an important role in choosing the right VPN solution. It does not always make sense to use a product from the same manufacturer in every location. A powerful VPN product will be used at the main site, which is oversized and overpriced for branch offices. If a manufacturer only offers high-performance solutions, a simpler solution must be found for the branch offices. A firewall with an integrated VPN can also be installed at the main site, but there is not even a firewall at the branch offices.

In all of these cases it is important that the products used are compatible with each other. The most important criterion is the protocol used. A PPTP-VPN cannot work together with an IPSec-VPN, as these work on a different level. But protocols at the same level cannot communicate with one another either. It is easiest to use products with the same protocol, but problems can arise here too.

PPTP was developed by Microsoft itself, but is not a recognized standard. PPTP is integrated into the Windows NT operating system (version 4.0 or higher) and is therefore compatible with any other Windows NT computer. There are now implementations for Windows 9x, Linux and various other Unix versions. VPN products that use PPTP are based directly on the implementation of Windows NT, so there should be little or no compatibility problems

L2F and L2TP are mostly implemented directly in the router, especially in those of the company Cisco, which L2F developed itself and which has entered into a cooperation with Microsoft for L2TP. Both protocols are defined in RFCs and are therefore precisely stipulated. Every product that uses these protocols must adhere to the RFCs and should therefore work without problems with other products that use the same protocol.

IPSec is an open standard that allows manufacturers certain freedoms (e.g. the encryption algorithm) and that is precisely what causes compatibility problems. You should therefore find out from the manufacturer of the VPN product how compatible it is with other VPN products and which IPSec processes are used. Some manufacturers offer certification for compatibility with their product. The company Checkpoint, which mainly manufactures firewalls, offers, for example, the so-called OPSEC standard (Open Security Platform). The OPSEC certification guarantees that a product is compatible with Checkpoint.

Some manufacturers develop their own protocols, most of which are modified standard protocols. If these products do not offer interfaces to other protocols, only products from the same manufacturer can be used.

 

7.4 data replication

The replication of data, i.e. the local provision of the data at strategically important points, has the advantage that the data is not available via the VPN but via the faster local network. For example, customer data can be replicated in the branch offices so that a query on the local server is possible and does not have to be forwarded to the central computer. Problems arise from the up-to-dateness of the data, i.e. how up-to-date is the data on a local server. Are they updated daily, hourly, or with every transaction?

In any case, a reasonable data replication is influenced by many factors and is highly application-dependent. This makes it difficult to make general statements as to whether data replication makes sense or how it can be implemented. VPN solutions do not offer any support for data replication. So you first have to think about the implementation of the VPN and then decide whether it makes sense to use data replication. This decision can go in circles, since with data replication smaller bandwidths may be sufficient and therefore another VPN solution can be used.

 

7.5 Compression

By compressing the data to be transmitted, larger amounts of data can be transmitted in the same time. This does not involve compressing a single file, rather the entire data stream must be compressed in real time. In order for compression to make sense, it must be done before encryption, since encrypted data can no longer be compressed.

Various types of compression are currently in use. The compression by a modem or a router is done by V.42bis. It can only be used if the recipient receives error-free data. For this reason, an error correction mechanism must be available for remote data transmission. With modems this is V.42 and with ISDN HDLC with X.75 and T.70.

If the compression starts with PPP, the PPP Compression Control Protocol (CCP, RFC 1962) and the Microsoft Point-to-Point Compression Protocol (MPPC) are mostly used. Some products use their own compression processes which, like V.42bis and MPPC, use the “Lempel-Ziv coding” to compress data streams. There are different versions of the Lempel-Ziv coding, all of which are based on the original version LZ77, which was published in 1977 by Abraham Lempel and Jacob Ziv (Lempel, A. and Ziv, J., "A Universal Algorithm for Sequential Data Compression", IEEE Transactions On Information Theory, Vol. IT-23, No. 3, May 1977). LZ77 leads a window over the input data and searches in the input stream for patterns that have already been seen in these windows. In this case, instead of the input, only the index and the length of the pattern are output in the window. During decoding, the window is handled in the same way as during encoding. The dictionary for the recognized patterns is obtained implicitly from the data stream during decoding, i.e. no information about the message has to be transmitted to the compressor or decompressor. The best-known implementation is certainly the LZW coding, which was presented in 1984 by Terry A. Welch. It is so popular that it is often incorrectly referred to as THE “Lempel-Ziv Coding”.

The “Stac LZS compression” (RFC 1974) is often implemented in VPN products. This is a form of Lempel-Ziv coding which has been further developed by Stac Electronics and which has been optimized in order to be able to deal with all file types as effectively as possible. With the normal Lempel-Ziv coding, it could happen that files that were already compressed became larger when they were compressed again. This is to be prevented with the "Stac LZS" [27].

The compression methods mentioned above are used in PPP. PPP works on Layer 2, i.e. VPN solutions that work on a Layer 3 basis can no longer use this compression, because Layer 3 has already been encrypted. In order to be able to compress IPSec, it must already be compressed on layer 3 and that before encryption. This is why the "IP Payload Compression Protocol" (IPComp, RFC 2393) was developed for IPSec, which enables lossless compression of IP datagrams. One IP datagram is compressed before the datagram is changed through authentication or encryption. After the compression, the IP header must be changed accordingly due to the changed size of the packet. Before an IPComp connection can be established, the "IPComp Association Negotiation" (IPCA) must first exchange agreements on compression (compression algorithm, mode, compression parameter index (CPI), etc.). This can be done dynamically through ISAKMP or through manual configuration.

IPComp is only partially implemented in VPN solutions, as this standard has not yet fully established itself or the effects on IPSec have not yet been fully clarified. For this reason, VPN solutions based on IPSec often do not use compression. Only the dial-up connections via slow modems are partially supported by compression.