Linux VPN Fundamentals
- Our Conventions
- Considerations
- VPN and Firewall Interaction
- Networking Issues
- Logging
- Performance
- Summary
This sample chapter covers the important issues you need to be aware of before choosing and deploying a VPN solution. It describes various related concepts in the context of VPNs, such as firewalls, routing, and netmasks.
When building VPNs, you should always keep in mind fundamental considerations such as scalability, interoperability, and key distribution. You also need to have a clear understanding of what topology is the best for your scenario, how packets are going to be routed, what parts of your network are protected, the possible points of failure, and so forth. This chapter also describes the maintenance tasks of performance measurement and logging.
This chapter is from the book
This chapter is from the book
This chapter is from the book
Our Conventions
In this book, we describe a number of VPN technologies and packages. For each specific VPN package or setup, we provide examples corresponding to the following three basic VPN scenarios you might have: network-network, host-network, and host-host.
In the network-network scenario, two subnets are connected using a VPN tunnel. Each subnet should consist of a gateway/router and a host. The gateway for each subnet should have two network interfaces: one to the outside world and one to the gateway's internal subnet. You can use this scenario to securely connect to your company's branch overseas, for example.
The host-network scenario can be interpreted as a degenerate case of the network-network scenario. The host-network scenario is used when one of the subnets to be connected consists of just one host. To illustrate, you use the host-network scenario when telecommuting or when you want to securely connect to a corporate network while on the road.
The host-host scenario is formed by further reducing the host-network scenario so that it consists of only a pair of hosts that want to connect to each other. For example, you might want to use this scenario to establish a secure tunnel between two hosts that belong to different networks. This scenario is different from others in that only these two hosts can send secured traffic to each other. If more machines need to communicate securely, a host-network or network-network setup would be more appropriate.
Gateways vs. Networks
In this book, we say that VPNs have the capability to connect networks, for example the host-network or network-network VPN scenarios. All VPNs have two hosts that handle the encryption/decryption of the VPN traffic, the endpoints of the VPN. When one or both of these hosts allows access to a network of machines rather than to just the single host, we call the host a gateway.
The concept of a gateway is already standard networking terminology. For example, the router that connects a business to its ISP is a gateway, as could be a firewall through which all traffic passes. In VPN terminology, a gateway is simply a VPN endpoint that sits in front of a network that has access to the VPN.
In other literature, you might see our three VPN senarios referred to as host-to-host, host-to-gateway, and gateway-to-gateway. The former explicitly mentions the endpoint of the VPN—be it a host or gateway—while the latter two describe what you want to connect—a host or a network. The two forms of terminology are functionally equivalent, but we prefer the "network" form because it is easier to see what you are trying to connect—one or more networks—instead of specifying how this connection is implemented.
For instance, if we use a VPN package and configure it to connect 192.168.1.0/24 and 192.168.2.0/24, we are connecting two networks. Each of the networks will have a gateway (say, 192.168.1.1 and 192.168.2.1) that will forward traffic for its respective network.
Sample Scenario
To help you understand the scenarios just described, we will consider a simple network-network scenario (see Figure 2.1), which is similar to those used in the examples throughout the book.
){kind=link}
As you can see, the network-network scenario shown in Figure 2.1 consists of two networks, one in Chicago and one in Atlanta.
The Chicago network is 192.168.1.0/24, with the VPN server/gateway (Bears) located on the internal network on IP address 192.168.1.1. Several hosts, such as Cubs, Bulls, and Blackhawks, are on the internal Chicago network. Atlanta has a similar configuration, with Falcons as its VPN server/gateway.
Figure 2.1 A network-network scenario example.Both networks use addresses in the private-network range, as specified in RFC 1918. (We detail the RFC 1918 networks later in this chapter.) The IP addresses on the outside (280.8.8.8 and 270.7.7.7) are fictitious Internet-routable IP addresses that the two machines will use for their actual communication.
Our External IP Addresses
You might notice something fishy with our two external IP addresses: 280.8.8.8 and 270.7.7.7. These addresses are not legal; the legal range for any byte in an IP address is 0 to 255. We did not want to use actual routable IP addresses, lest you accidentally type them in and attempt to establish a VPN between you and some unsuspecting party. The examples we provide will do one of the following:
-
Use private IPs as external IPs, explicitly stating that you should replace them with real routable Internet IPs.
-
Use w.x.y.z addresses as external IPs, where w is greater than 255 and is thus illegal on the Internet.
Our network-network scenario can be converted into the host-network one by removing the eth1 interface and the entire 192.168.1.0/24 network from Bears and connecting Bears to Falcons. Similarly, the host-network scenario can be converted into host-host by removing the eth1 interface and the 192.168.2.0/24 network from Falcons and having Falcons and Bears be the only two machines involved in the VPN.