What is VPN?
The majority of typical VPN-related documents define VPN, as the extension of a private network. However this type of definition means nothing and only characterises the VPN concept as a determining factor of a private network, which is still somewhat unclear. VPN is an abbreviation for Virtual Private Network. Everybody knows what a “network” is making explanations pointless. A private network is one where all data paths are secret to a certain extent, yet open to a limited group of persons, for example, to employees of a specific company. In theory, the simplest way to create such a network would be to isolate this network from the Internet. However in the case of a business with some remote branches it is not so simple. Leased lines could be a solution, but a costly one, which would not necessarily ensure the required degree of security. Furthermore, leased circuits suffer from a single faulty link syndrome – the connection that goes down from time to time may create a major or minor disaster for a company. Besides, there is sometimes a need to give access to a part of the resources of a private network to external users, and that would not be possible over a physically separated network. Of course, a solution might be to employ a remote server however it would involve additional fees for phone sessions that may also be long distance. What about the buzz word “virtual”? At present, VPN is far from being a physically separated structure. It uses the existing infrastructure that encompasses both LANs and WANs, and where an IPv6 backbone may be supported as well as any networking, provided that it may be seamlessly integrated with today’s technologies. Transfer of data over a public network is accomplished using one of the available tunnelling technologies and all data can be encrypted to boost security.
After this introduction, the definition of a VPN as a dedicated private network based on the existing public network infrastructure and incorporating data encryption and tunnelling techniques to provide data security, is pretty straightforward.
What are the benefits of using VPN?
There are several reasons to use VPNs. Sensitive data security is undoubtedly a major issue, as well as other matters such as losing passwords, which contrary to popular belief is not the worst possible fate.
For example, if a multi-branch software development company stores its software source files in a central CVS repository, and a rival IT Company manages to intercept network traffic between the branch and the CVS, it may steal some brilliant ideas incorporated in the software programs. The amount of damages involved in such a case may be millions of dollars however possible lawsuits are rarely as quick and straightforward as expected.
From the economic point of view, creation of a VPN may be less expensive than maintaining leased lines, although the cost of VPN firmware may appear to be enormous. In fact, lost data may turn out to be far more expensive. Costly equipment is rarely needed to implement a VPN. In practice, any Microsoft Windows machine can be used as the VPN client and any Windows 2000 or Windows .NET computer can be configured to be the VPN server.
What protocols can be used over a VPN connection?
The VPN networking concept is based, to a certain extent, on point-to-point links. In VPN networks they are emulated using data encapsulation and tunneling i.e. the data is wrapped with a header that provides necessary routing information. In order to enhance data confidence and integrity, packets being sent may be encrypted prior to entering the tunnel and even if intercepted (which is not difficult as they are sent over a public network), they will remain indecipherable without encryption keys. VPN connections permit users working from home or away on a business trip to obtain a remote, dynamically, set up VPN connection with their company’s Intranet. From the user’s perspective, the VPN is a point-to-point connection within the organisation’s server, which logically operates to some extent as a leased line or provides support for dial-in VPN connectivity.
The VPN gear can be built around various protocols depending on both the hardware and software capabilities. For Windows 2000 general use VPNs, commonly recognized protocols are PPTP and L2TP, combined with IPSec.
Between these two protocols, PPTP is older. It is a Layer 2 (OSI) tunneling protocol that encapsulates PPP frames as IP datagrams. For both tunnel creation and maintenance, PPTP uses the TCP protocol. The encapsulation uses an ephemeral (random) client-side port while the PPTP server is associated with port 1723. Packets are encapsulated using Generic Routing Encapsulation (GRE). PPTP encapsulation for payloads is as follows:
– The payload is encapsulated with a PPP frame.
– The PPP frame is encapsulated with a GRE header and trailer.
– The GRE frame is sent as a new payload for a new IP datagram between the client and PPTP server.
Data encryption is a vital part of a VPN. PPTP uses PPP mechanisms to provide data confidentiality. In Microsoft Windows 2000 implementations, the PPP frame is encrypted with MPPE. The keys for encryption are generated from the MS-CHAP or EAP-TLS authentication process, therefore the client must use either protocol for the communications with the VPN server to be encrypted, otherwise all payloads will be sent in plaintext over the tunnel.
PPTP is documented in RFC 2637.
L2TP protocol is a combination of Cisco Systems Inc. Layer 2 Forwarding and PPTP using the best of both. L2TP is more flexible than PPTP, its use, however, implies that a more powerful computer is needed than for a PPTP implementation. L2TP operates in Layer 2 (OSI) tunneling protocol. It encapsulates PPP frames to send them between the server and the client. It has been designed to operate directly with various non-IP WAN technologies. Like PPTP, L2TP encapsulates original IP datagrams over the network. Since encryption for L2TP is provided with IPSec, encapsulation is divided into two layers – the initial L2TP encapsulation and the IPSec encapsulation. The process is as follows:
– The initial payload is encapsulated with a PPP frame.
– The PPP frame is placed in a new IP datagram encapsulated with a UDP header and a L2TP header.
- TheL2TP encapsulated payload is IPSec i.e. it is added with an IPSec Encapsulating Security Payload (ESP) and an IPSec Authentication trailer (AUTH). In this way, integrity and authentication of messages are provided en route. At this stage, tunnelled messages are not yet encrypted. IPSecESP is the mechanism to provide encryption keys to L2TP data. It is possible to have a non-encrypted L2TP connection where the PPP frame is sent in plaintext. However, such an insecure solution is absurd and is definitely not recommended.
L2TP is documented in RFC 2661.
The main differences between PPTP and L2TP are as follows:
-PPTP requires an IP based network transport layer whilst L2TP only requires that the media provide point-to-point connectivity. So L2TP protocol can be used directly over IP Frame Relay, X.25 and ATM. PPTP cannot support non-IP media directly.
– PPTP supports only a single tunnel between the VPN server and the client. With L2TP, multiple tunnels can be supported to transport payloads end-to-end. Therefore, multi-tunnel operations are possible with L2TP corresponding to various levels of the Quality of Service (QoS) and security.
– L2TP protocol provides header compression mechanisms. When this function is enabled, the L2TP header is smaller than the PPTP header, and will result in fewer simultaneous RTP sessions being required to produce bandwidth efficiencies.
PPTP is still more popular than L2TP, and is used in Microsoft Windows 95, Windows 98, Windows NT 4.0, Windows 2000 and Windows XP/.NET systems. L2TP is supported from Windows 2000 onwards. L2TP implementations for older Windows versions may be available as third party products. In practice it might be difficult to find such solutions whereas for economic reasons, upgrading older OSes to Windows 2000 or XP could be less expensive than extensions of the same.
Although L2TP and PPTP are the main tunneling protocols used in Windows 2000, a certain VPN implementation can be built using the IPSec protocol already mentioned in the discussion on tunneled payload confidence ensured by L2TP. IPSec exists as the Layer 3 (OSI) data tunneling model that uses a specific mode – the ESP Tunnel mode that offers strong IP datagram encapsulation and encryption being sent over a public IP network. With this mode, whole IP datagrams are encapsulated and encrypted using ESP. The IP datagram is finally encapsulated with a new IP header and the new datagram obtained is sent over a network. Upon receipt of the L2TP datagram, the recipient processes the data-link frame to authenticate the content and sends the data to the destination site.
What security mechanisms are available through VPN?
Authorisation – VPN connections are only created for users and routers that have been authorised. For Windows 2000, authorization of VPN connections is determined by dial-in properties on the user account and remote access policies. If a user or router is not authorised for such connections, the server will disable them.
Authentication – This is a vital security concern. Authentication takes place at two levels:
- Machine-level authentication – when IPSec protocol is used for a VPN connection, machine-level authentication is performed through the exchange of machine certificates during the establishment of the IPSec connection.
- User-level authentication – before data can be sent over the PPTP or L2TP tunnel, the user must be authenticated. This is done through the use of a PPP authentication method.
Data encryption – the protocols used to create VPN connections allow encrypted data to be sent over a network. Although it is possible to have a non-encrypted connection, this is not recommended. Note that data encryption for VPN connections does not provide end-to-end security (encryption), but only security between the client and the VPN server. In order to provide a secure end-to-end connection, the IPSec protocol can be used once a VPN connection has been established.
Packet filtering – in order to enhance security of the VPN server, packet filtering must be configured so that the server only performs VPN routing. To this end, appropriate RRAS filters should be used (for Windows 2000) on the Internet interface of the VPN.
Connecting to the VPN server in Windows OS
Creating the VPN connection for the client is as simple as configuring dial-up networking. Therefore, the role of the system administrator is reduced to configuring the VPN server and making available information of the connection configuration, while the users may carry out the remaining procedures.
Fig. 1 Windows 2000 comes with a Network Connection Wizard for VPN configuration
In order to create a VPN connection:
– Choose NetA and Dial-up Connections followed by Make New Connection,
– Select Connect to a private network through the Internet,
– Enter the IP address of the VPN server,
– Depending on the configuration of the VPN server, a ROM chip may be used to authenticate the user,
– Determine if you want this connection to be made for all users on the network or for your own use only.
Such an established connection may require additional configuration, for example:
– Indicating the protocol type (PPTP or L2TP),
– Indicating the authentication method.
Fig. 2 The configuration of advanced security settings for a VPN connection
IPSec tunneling in Windows 2000
Knowing how to use VPN makes it easier to create a secure IPSec based tunnel between two remote networks. This is a very simple solution that requires two computers running Windows 2000.
Consider the following scenario:
There are two networks that use private addressing, one is called NetA, and the other NetB. Windows 2000 supports IPSec tunneling for situations where both tunnel endpoints have static IP addresses. Therefore, this pre-empts the use of IPSec tunneling for gateway-to-gateway scenarios although it is possible to create tunnels between the server and router. However it is interesting to note that Windows 2000 does not support protocol and port-specific tunnels. This is worth keeping in mind, because the Microsoft Management Console (MMC) interface is very generic and allows association of any type of IPSec filter with a tunnel. One must remember to use only address information in the creation of a tunnel, because the IPSec tunnel secures only traffic specified in IPSec filters. It is also essential to configure filters in Routing and Remote Access Service (RRAS) to prevent traffic outside the tunnel from being forwarded. Two IPSec rules must be created, since two tunnels are to be established, one from NetA to NetB and other from NetB to NetA. Each tunnel is represented by a rule, so two rules are required to configure an IPSec policy for the gateway internal network computers, and more particularly, two filters must be built – one to match packets going from NetA to NetB, and one to match packets going from NetB to NetA.
Typically, a Windows 2000 gateway is not a member of a domain, so local IPSec policies are created. If the Windows 2000 gateway is a member of a domain that already exists, a local IPSec policy may prevent the gateway from having its local IPSec settings. In this case, creation of an Organizational Unit (OU) in Active Directory is necessary to make the gateway a member of this OU, followed by assigning appropriate IPSec settings.
Fig. 3 An exemplary IPSec tunneling
The first phase in creating a tunnel consists in establishing the IPSec policy outlines. To do this, follow these steps:
– Activate the MMC to work on the IP Security Policy Management,
– Right-click IP Security Policies on Local Machine, and then select Create IP Security Policy,
– Click to clear the Activate the default response rule check box.
It is generally a good idea to give a sensible name to the rule and fill the check box to skip further steps related to the rule issues.
Once a general scheme of the rule has been created, you must build the filters corresponding to the traffic from NetA to Net B and from NetB to NetA. To do this, follow these steps:
– Click to clear the Use Add Wizard check box and then click Add, to create a new rule,
– On the IP Filter List tab, select Add,
– While defining the Source address select A specific IP Subnet, and then insert the data for NetA (assuming that the tunnel from NetA to NetB is to be created first),
– While defining the Destination address click also A specific IP Subnet and fill in the boxes for NetB’s address and mask,
– Click to clear the pole Mirrored, so the rule is not associated with the packets sent from NetB to NetA,
– On the Protocol tab, make sure that the protocol type is set to Any.
Fig. 4 Configuring the tunnel filters
Fig. 5 A versatile character of MMC may be misleading. The IPSec tunneling does not support protocol and port-specific tunnels.
Building a filter list for traffic from NetB to NetA follows the same steps, except that it is necessary to define appropriate addresses of the networks, i.e. NetB as a source and NetA as a target respectively.
Once the filters have been configured, create the tunnel. If it is the case of the traffic from NetA to NetB proceed as follows:
– On the IP Filter List tab, click the filter from NetA to NetB.
– On the Tunnel Setting tab, insert the IP address assigned to the gateway internal network adapter for NetB.
– On the Filter Action tab, click to clear the Use Add Wizard check box, and then click Add to create a new filter action.
– Keep the Negotiate security option enabled and click to clear the Accept unsecured communication, but always respond using IPSec check box.
– Click Add and keep the High (ESP) option selected; or you can select Custom, (but only if you know what you are targeting).
– Once the new filter action has been configured, on the Authentication Methods tab set up the authentication methods to be used. Use preshared keys for testing, otherwise use certificates for product authentication. Kerberos is technically possible, but rarely used. (Kerberos is the perfect solution to deploy secure communications across trusted domains).
The same steps as above should be made for traffic from NetB to NetA, remembering to change the IP tunnel endpoint address of the NetA computer.
In order to verify the functioning of the tunnel, use ping and IP Security Monitor programs. For Monitoring – you can additionally test the traffic using the IPSec formatted packets with a packet sniffer to verify whether the traffic is really encrypted.
Reading about VPN may create a false sense of security, which may be dangerous. Obviously, VPN secures the traffic between networks but internal traffic remains unencrypted and vulnerable to attacks of network sniffers that may intercept sensitive data. It may seem that intruders would not be able to gain access to the internal network but this would be an erroneous assumption. Remember that, from a statistical point of view, more than 80% of network security violation attempts are from within the network! Frequently, networks that are well secured from outside intrusions are sorely lacking in internal network security. IPSec may be an option to enhance corporate security by protecting internal network traffic. If this is to be a Windows 2000 domain-based network combined with Active Directory, creation of appropriate rules and requirements from computer clients is not a complex task and significantly improves internal network security.
Will a VPN implementation solve all problems related to safeguard of sensitive data? No, definitely not. IT security is a large and challenging issue and there is no single panacea for all security needs. However, VPN is a vital component of a secure corporate network.
