So far in the cryptosystems series, we have taken a look at general cryptographic terminology and the SSH cryptosystem (including configuration). In today's article, I'll start off with how VPNs work and then concentrate on the IPSec standard.
A VPN, or Virtual Private Network, is a cryptosystem that allows you to secure your data as it travels over an insecure network such as the Internet. While this may sound similar to the SSH cryptosystem, VPNs have a different purpose. SSH was designed to allow a user to login securely to and remotely administer another computer. A VPN is designed to allow a user to access transparently the resources of a network. As far as the user is concerned, she will be able to do anything she normally would be able to do, even when she is away from the network. Because of this, VPNs are popular with telecommuters and with offices that need to share resources over physically separate locations.
Before configuring a VPN, you should be aware of the terminology it uses and some of the configuration pitfalls. Let's start with some terminology. A VPN always consists of a point-to-point link known as a tunnel. The tunnel itself occurs over the insecure network which is usually an Internet connection. A point-to-point link means that it is always between two computers which are referred to as peers. Each peer is responsible for encrypting the data before it enters the tunnel and decrypting the data as it leaves the tunnel.
Even though the VPN tunnel is always between two peers, each peer can set up tunnels with other peers. For example, if three telecommuters were to establish a VPN to the same office, there would be three separate VPN tunnels to that office. However, each tunnel would share the same office peer. This can occur because it is possible for a peer to encrypt and decrypt data on behalf of an entire network as seen in Figure 1:
Figure 1 -- a VPN gateway to a network
When this occurs, the VPN peer is also known as a VPN gateway, and the network behind the gateway is referred to as the encryption domain. It makes sense to use a gateway for several reasons. First, all users are required to go through the same device, which makes it easier to administer a security policy and control which traffic is allowed in and out of the network. Second, it would quickly become unworkable to set up separate tunnels for every PC a user wanted to access. (Remember, a tunnel is a point-to-point link). With a gateway, the user initiates a tunnel to the gateway and is then allowed access to the network, or encryption domain, behind that gateway.
It is interesting to note that no encryption occurs within the encryption domain. This is because that portion of the network is considered to be secure and under your administrative control while the Internet is considered to be insecure and beyond your control. This also makes sense when using two VPN gateways to connect two offices. It ensures all data is encrypted as it traverses the insecure link connecting the two offices. Figure 2 shows a VPN connecting two offices:
Figure 2 -- a secure network over an insecure network
Network A is considered to be the encryption domain of VPN Gateway A, and Network B is the encryption domain of VPN Gateway B. When a user on Network A wishes to send data to Network B, VPN Gateway A will encrypt the data and send it over the VPN tunnel. VPN Gateway B will decrypt the data and send it to the destination in Network B.
Remember transport mode and tunnel mode from Cryptographic Terminology 101? Whenever two VPN gateways are used to connect two networks, they always use tunnel mode. This means that the entire IP packet is encrypted and a new IP header is added. That new IP header contains the IP addresses of the two VPN gateways. This adds an extra benefit in that a packet sniffer will only see the IP addresses of the gateways. There is no way to identify a source computer in the first encryption domain or a destination computer in the other encryption domain.
Compare this to Figure 1, which shows the other use of a VPN, allowing remote users with laptops and users who work from home to access the resources at the office network. In order for this to work, the user needs VPN client software installed on their PC to negotiate a VPN tunnel with the office VPN gateway. In this scenario, tunnel mode is still used as the remote user wants to access the resources within the encryption domain rather than the resources on the VPN gateway itself. The only time transport mode is used is when one computer wants to access another computer directly.
There are many options for VPN gateways and VPN clients. There are hardware VPN appliances and VPN software that can be installed on routers or PCs. Your FreeBSD system comes with software that allow you to set up either a VPN gateway or act as a VPN client. There are also additional applications in the ports collection, which allow interconnectivity with other VPN peers on non-FreeBSD systems.
Fortunately, there are also plenty of VPN resources, FAQs and configuration tips on the Internet. My favorites include Tina Bird's VPN Information, VPN Labs, and the Virtual Private Network Consortium (VPNC).
Regardless of the VPN software being used, all VPNs share the following behaviors:
- Both peers authenticate each other before establishing the tunnel to ensure the encrypted data will be sent to the expected peer
- Both peers require a pre-configured policy stating which protocols can be used to encrypt the data and provide data integrity
- The peers compare their policies to determine which algorithms will be used; if the peers are unable to agree upon the necessary algorithms, the tunnel is not established
- Once the policy is agreed upon, a key is created which will be used by the symmetric algorithm to encrypt and decrypt the data
There are several standards which dictate how the above occurs. You may have heard of some of them: L2TP, PPTP, and IPSec. Since IPSec is the standard that most VPNs support, and it also has the most acronyms to wade through, I'll devote the rest of this article to IPSec.
Pages: 1, 2