Implementing VPN in Linux

Virtual Private Network (VPN) is used to create a private network of computers, virtually. The key word here is, virtually, and it refers to situations where a remote non-LAN computer (or remote LAN) is 'virtually' brought within the network. Another unstated rule of the thumb is that the VPN tunnel is generally encrypted. However, you should know that encrypted VPN tunnel in most implementation of VPN is not by default but by special design.

It would be fair to say, that there exists some serious issues in inter-operability of the various products available in the market. Without getting into the debate of open source vs commercial software, it should suffice to say that the VPN design must be carefully made on the basis of types of clients that you have, the client software that you would want to load, and the type of server side implementation. This extends further to the features that you would like your VPN to support. Unfortunately, there are very few ‘Have-all-features-best-product-mix’ solutions available. Add to it the complexity of modern world real life networks and the hybrid condition of the Indian Internet scenario. Corporations have all types of connectivity from dedicated leased circuits between offices, leased line to Internet, ADSL/DSL, cable, satellite, dial-up, and ISDN. These myriad options throws up challenges of fixed IP vs dynamic IP, real IP vs fake IP, etc. 

Then, there is the issue of defining what exactly is required to be done. VPN in its vastness of definition could mean, two or more networks connected to each other over a public network, securely. It could also mean one roaming user trying to connect to the internal network or server. In many instances, it could mean setting up a secure tunnel over local LAN (PPoE). One needs to clearly define the need and objective of the situation and choose the right mix.

This article attempts to make this segment clutter free, by giving the various options for servers, clients and VPN authentication using Linux. In our next article, we'll cover the prerequisites for configuring a VPN server using FreeS/WAN. And next month, we'll wrap that up by talking about how to configure FreeS/WAN under to VPN configurations: Client to LAN and LAN to LAN.

Options for the server side



Implementing through routers and commercially available firewalls

Some commercially available routers have support for VPN tunnels built into them. While most will require a special hardware, a specialized IOS is a must. IPSec implementation and support is most widely available, however, most routers require a special client to be loaded on the client side to allow them to connect to VPN. Like the routers, there is a possibility 

of using a commercial firewall for delivering the above. Checkpoint, eg can do IPSec based VPN client setup, but then, one has to pay for the respective licenses on the server side and the client side. Some specialized hardware firewall (such as Netscreen) do not require any server side licensing, but require you to have specialized software on the clients. Unless your firewall or router is extremely idle in their current role of firewall/router, you should consider deploying a dedicated device, if you expect many tunnels to connect. This may not be required, if you only want to connect two offices. You may also want to choose the compliant client side application carefully, including their upgrade path and support available. Also pay extra attention to the support of Pre-shared Keys and certificates, as most support only Pre-shared Keys and not certificates.
(Netscreen and Snap Gear do support certificate.)

PPTP

Point To Point Tunneling Protocol (PPTP) on Linux Gateway servers are relatively simpler to install, low on overheads and security, however its widely supported by Windows. To get Windows to do encrypted tunnel with Linux servers, you will need additional software. Installation of PPTP cannot be covered in this article, but it should suffice to state, that an enhanced rpm of PPP and non-buggy OpenSSL is required. Client support is very wide spread and most Windows version have native support for it. However, be forewarned that there have been known situations, where the PPTP passwords have been broken under 4 hours.

IPSec implementation on Linux gateway servers

As with most other open source products line of this class, VPN implementation through IPSec on Linux is fairly easy, inexpensive and relatively low on maintenance. The challenge so far has been a structured approach to making an informed decision on each of the options available. In this article, we try to bridge this gap.

Specialized VPN protocols on Linux gateway servers

Even in the open source space, there are several alternative product lines available, such as cipe, vtun and openVPN. These are fairly simple to install and use. If you intend to simply inter-connect two offices in a 100+ nodes LAN environment, with little worries on Road Warriors, perhaps these fit the bill effectively, however, if you need to effectively support all aspects of the VPN and also integrate with over all organization application network, you should seriously consider IPSec as the underlying base.



Client Options

• A hardware device at the client side. Some commercial products such as Cisco, Draytek or Netscreen exist, that provide a pre-configured device to allow remote clients to the VPN. The obvious and simple advantage is the ease of use in terms of configuration - but the downside is the huge cost associated with the same.
• PPTP - All Windows version above Win 98 have an inbuilt client called PPTP. This is extremely easy to use client and connects to any PPTP server, however, it is not rated very high in security by the industry.
• SSL-based VPNs. These are generally used for specific applications and in true terms allow use of applications. 
• Third-party IPSec clients.There are several third party commercial software that allow you to set VPN clients.
• Functionality of these clients (such as SafeNet SoftRemote, SSH Sentinel or PGP) are generally rated high but the support is dependent on the kind of support contract you have established.
• IPSec with Win2000/XP, configured without inherent L2TP. You will be surprised to note that it is extremely difficult to make Windows do IPSec without the internal L2TP. While doing it on Win XP is difficult, though possible, it will take you several days to get it right on Win2000. It involves getting into the Windows registry and manually deleting, modifying a string of registry entries. Things are slightly easy if you choose a ready made software from e.bootis for doing it.
• Downloading a client MSL2TP from Microsoft site. In addition to the pre-bundled software in Windows, it is possible to download a VPN client from the Microsoft site. This will be required for all versions of Windows below Win2000.
• IPSec/L2TP clients such as Win2000/XP. The simplest of flavors to install and work on, but requires administration of L2TP protocol on the server.
  
  
  
  Authentication Options
• Pre-shared Key (PSK) (non-system based): A Pre-shared Key is a secret password that is shared by both sides of the IPSec tunnel. Preferably, the PSK is distributed through 'out-of-band' medium, such as phone call, paper, face to face, it should not be shared over the public networks. PSK in a Road Warrior setup has an additional disadvantage; all users with dynamic IP addresses will have to share the same PSK - which in itself is a big security risk. However, for small setups, this may not be such a big problem.
  
  
  
  RSA authentication
• In RSA authentication you specify the raw RSA public key of the user in the FreeS/WAN configuration. RSA authentication supports both static and dynamic IP addresses. And is also lightweight in terms of setup. At the time of writing this article, none of IPSec clients with RSA authentication supported L2TP/IPSec implementation, hence for our purposes, we will not be able to deploy this.
  
• Pre-shared Keys in Aggressive Mode
  
  Some IPSec clients support Aggressive Mode. There is a patch for FreeS/WAN, which adds support for Aggressive mode that allows user with both dynamic and static IP address for client. This patch is also included with SuperFreeS/WAN. However, this is considered to be less safer than the regular PSK or RSA implementation. 
  
• XAUTH
  
  XAUTH is an extension to IPSec and is still in experimental stage. Once again, this is bundled in SuperFreeS/WAN, and you are welcome to try the implementation.
  
• X.509 certificates
  
  Almost all L2TP/IPSec clients support X.509 certificates. FreeS/WAN supports it too, through a patch. Our implementation here takes this into consideration and hence the use of specific RPMS on the server side. You will of course need a lightweight implementation of PKI, to create, revoke, user certificates. Further, this can also fit in extremely well for an organization that is keen to create a single-sign on infrastructure for itself. The steps of setting up such an infrastructure is out of the scope of the current article, perhaps we could explain the PKI infrastructure another month.

Alok Sinha