IPSec VPN Design [Electronic resources] نسخه متنی

IPSec VPN Connection Models

Before getting into IPSec VPN architectures, you'll review several IPSec connection models. These connection models are the mechanisms that are used to provide protected communication between VPN endpoints. You might think of them as the basic building blocks of an IPSec VPN architecture. We will explore three connectivity models:

IPSec model

GRE model

Remote access client model

Each of these connection models has unique capabilities and constraints, which you will need to consider carefully when deciding which model will be most effective in the VPN architecture. Each of the models requires the presence of IP connectivity between the IPSec endpoints. The knowledgeable network designer will recognize that a scalable and reliable IPSec VPN architecture may leverage more than one connection model. The intent of this chapter is to guide the network designer in the choice of the connection model in order to achieve the optimal VPN architecture.

IPSec Model

Chapter 2, "IPSec Overview," the simplest connectivity model is achieved by creating an IPSec VPN between two sites, which is commonly referred to as site-to-site connectivity using the IPSec model. The sites can be connected over private IP networks such as Frame Relay or ATM networks running IP using transport mode or over the public Internet using tunnel mode.

Chapter 6, "Designing Fault-Tolerant IPSec VPNs."

The IPSec model is conceptually simple to understandit protects unicast traffic from one subnet to another. The IPSec model is generally the lowest common denominator from the perspective of capability of the IPSec nodes and their ability to establish connectivity between sites. Although the protection model is conceptually simple, the configuration of the model can get quite complex for large VPNs. Operators must explicitly configure a protect profile for traffic between every potential subnet. The addition of a single subnet in the VPN may require configuration updates to all the other VPN gateways in the network. Network designers must carefully allocate IP address blocks at each site in order to minimize the amount of explicit configuration of discrete IPSec proxy profiles. In some cases, network planners may have little control over the address allocation methods, which could result in a network with inefficient subnet addressing. A poorly architected network using the basic IPSec model will quickly become unmanageable. Clearly, there is a motivation to decouple the subnet address allocation from the IPSec policy definitions in order to simplify provisioning.

Another disadvantage of the IPSec model is the lack of support for IP multicast, as the original IPSec RFCs did not accommodate multicast in the IPSec proxy statements. Many IGP dynamic routing protocols (such as OSPF, EIGRP, and RIP) use IP multicast to establish routing adjacencies. Most enterprises rely on Interior Gateway Protocols (IGP) to dynamically discover the optimal paths through the VPN. The IPSec model mitigates the value of the IGP, essentially making the IPSec proxy statements behave as static routes.

Note

BGP may be used in lieu of an IGP because it uses TCP unicast packets to build adjacencies between peers. However, the use of BGP does not mitigate the requirement to explicitly define the IPSec proxy profiles for traffic flowing between all the distinct subnets.

It is evident that the requirement to explicitly define every potential IP flow on every VPN gateway is not a viable method for a large, complex network with hundreds, or even thousands, of subnets. In the next section, you'll explore how routing protocols can be exchanged over IPSec-enabled virtual interfaces in order to simplify the IPSec policies.

The GRE Model

In Chapter 2, "IPSec Overview," you saw that there are certain limitations for support of dynamic routing and IP multicast when using the IPSec model for site-to-site connectivity. One way to overcome these limitations is to use generic route encapsulation (GRE) tunneling of site-to-site traffic protected by IPSec. The notable advantage of this GRE model is that it simplifies configuration for site-to-site VPN connectivity. In the GRE model, all traffic between sites traverses a GRE tunnel that is protected by IPSec; therefore, IPSec profiles in this model are applied to packets that originate and terminate at the GRE tunnel interface. A VPN built with GRE and IPSec protection can be broken into four basic functions:

Creating the GRE tunnel

Protecting the GRE tunnel with IPSec

Providing IP connectivity between the GRE tunnel and IPSec endpoints (routing outside the VPN)

Providing a viable routing path for endsystems through the GRE tunnels (routing within the VPN)

The combination of GRE tunnel and IPSec protection decouples the dynamic routing requirements and subnet-to-subnet traffic flow from the IPSec protection policy. IPSec protection is dramatically simplified by virtue of the fact that a single IPSec proxy profile may be defined for the GRE tunnel that carries all traffic flowing between two VPN gateways regardless of the type, source, or destination. The compromise with using the GRE model, however, is that two routing planes are required:

A routing plane between the VPN gateways routes encrypted tunnel packets

A routing plane between the VPN gateways through the tunnel provides routing paths between the end-user subnets

Therefore, the GRE model minimizes the IPSec provisioning requirements while creating a tunnel overlay network that complicates management and introduces an entirely different set of scalability constraints.

The Remote Access Client Model

Chapter 3, "Enhanced IPSec Features," you saw how a remote access client initiates a connection to its IPSec endpoint, which is typically a hub. Using the advanced IPSec features, the remote access client model allows the client to use a dynamically assigned IP address. It also allows the network provisioning staff to define a policy that is pushed to the client to simplify network operations management. Neither the IPSec nor the GRE model provides this capability. You need a new method to exchange these capabilities and attributes during the establishment of the IPSec connection. You can accomplish the capability and attribute exchange using extensions to IKE. The IKE Mode Config process assigns connection attributes to the client, assuming that it is a single host. The typical attributes assigned include the following:

Private IP address

Private DNS server

Private WINS server

Private domain name

The private IP address is usually assigned from an address pool configured on the hub. Then, an IPSec proxy is created to protect traffic from the assigned private address to a range of addresses protected by the hub. The hub advertises the address pool to other network devices such that a return path is provided to the client. The client typically directs all user traffic to the hub when split tunneling is not allowed.

The remote access client model obviously simplifies the provisioning process by automating the policy distribution to the clients using IKE Mode Config. The protection policies may be centrally defined and managed such that the network operator is not required to configure each remote endpoint. There are a couple of disadvantages with this model. First, the IPSec connections can only be initiated from the client to the server. Second, the connection uses a simple IPSec proxy statement that doesn't support multicast.

IPSec Connection Model Summary

Three IPSec connection models have been presented, each with their own pros and cons. As a network designer, you must assess the scalability requirements, stability requirements, and application requirements in order to select the appropriate connection model. Often, a combination of the connection models is required in order to scale IPSec connectivity over a large enterprise network. Now that you've seen the basic capabilities of the various connection models, you'll see how these tools apply to the various network architectures.

In the remaining sections of this chapter, you will be presented with the variety of IPSec VPN architectures that are possible using the connection models previously discussed, and will delve into the pros and cons of each model. Figure 5-1 is provided as a reference network on which the various architecture models are applied. In many cases, a subset of routers from the reference network is used to provide clarity. Most of the possible architectures are a subset of the following two most common architectural models:

Hub-and-spoke topology

Full-mesh topology

The network designer's selection of topology is driven primarily by the application needs of the VPN. Other important factors are simplicity, scalability, efficiency, andof coursecost.