Hub-and-Spoke ArchitectureOne of the most common IPSec architectural models is the hub-and-spoke model shown in Figure 5-2. Figure 5-2. Hub-and-Spoke IPSec VPN ArchitectureChapter 6, "Designing Fault-Tolerant IPSec VPNs." Using the IPSec ModelOne of the most critical aspects of the IP network design process is the proper allocation of IP address subnets; this is also true for IPSec VPNs. Traditional Frame Relay or Asynchronous Transfer Mode (FR/ATM) hub-and-spoke networks place all the Layer 3 routing complexity at the hub, where hundredsif not thousandsof remote sites connect. The network architect will typically assign the IP address ranges at each site such that the address space is assigned efficiently while simplifying the routing processes. The typical hub-and-spoke architecture requires an explicit route at the hub site for each remote spoke's address range. Likewise, each spoke will require a route to the IP address range assigned to the hub site. A reciprocal pair of static routes is all that is required on the connection between the hub and spoke. Dynamic routing may be used between the hub and its spokes to simplify the routing configuration, particularly at the hub site. Note Dynamically exchanging protected routes between IPSec sites generally requires GRE (or IP) encapsulation of the routing protocols. IPSec may then protect the IP-encapsulated routing exchanges. It is easy to see how the scalability of the IPSec VPN comes into question at the hub side. Each site requires a minimum of two IPSec security associations (one for traffic in each direction) and an IKE security association. If the IP address ranges at either end of the site-to-site connection cannot be represented as a single IP address block because non-contiguous IP address ranges are used at the hub or spokes, then additional IPSec SAs may be required between each hub and spoke connection. Therefore, the proper allocation of IP address ranges is of paramount importance for scalability and reducing configuration complexity. Figure 5-3 shows the addressing used in the previous example of an IPSec VPN in a hub-and-spoke topology. Figure 5-3. IPSec Proxy Profile for Hub-and-Spoke VPN Topology[View full size image] Example 5-1 shows the IPSec configuration for the hub site shown in Figure 5-3. Note that a single crypto map is used on the interface with multiple sequence numbers in the crypto map. Each sequence number represents a unique spoke. Associated with each sequence number is the access list that matches transit packets on the interface to the appropriate spoke. The access list associated with each spoke essentially "routes" the packets to that peer. Note also that the only routing statement is the default route to the backbone network. Example 5-1. Native IPSec Hub Configuration
Example 5-2 shows the output listing resulting from the configuration on the hub. A single crypto map is presented for clarity; however, there will be a unique crypto map instance for each spoke. Note also that the route listing does not specify a route to the spoke's protected address; only the default route is needed to force the traffic through the interface where the IPSec access list takes affect. Emphasis should be placed on the source address range that the hub is protecting. Note that the range includes only the LAN connected to the hub site. Example 5-2. Native IPSec Hub Configuration State
Example 5-3 provides the configuration listing for the spoke site with a reciprocal IPSec proxy statement. The spoke may also use a default route to the backbone network with a single crypto map to direct traffic to the hub site. The other spokes would use a similar configuration with the IPSec proxy modified for the address space protected by the spoke. Example 5-3. Native IPSec Spoke Configuration
Example 5-4 provides the configuration state on SPOKE-1-WEST. Particular attention should be given to the address ranges that the spoke protects traffic from and to. This attribute will be exploited as additional functionality is provided. The current configuration protects traffic only destined to the IP address range assigned to the hub site, as opposed to traffic to any other spoke. Refer to Figure 5-3. Example 5-4. Native IPSec Spoke Configuration State
One possible way to reduce the configuration complexity at the hub is to define a crypto profile at the hub that matches any remote site's address range. This approach works only when the spokes initiate the traffic to the hub. The hub cannot initiate a connection to the spokes because the crypto profile does not uniquely identify an appropriate spoke. When the spokes initiate connections to the hub, the inverse of the spoke's IPSec proxy statement will be installed on the hub; it must be a subset of the hub's crypto profile allowing return traffic to be directed to the appropriate spoke. For example, if SPOKE-1-WEST is initiating a connection to VPN-GW1-WEST with protection (FROM: 10.0.64.0/24, TO: 10.1.0.0/24), the inverse of this protection profile is (FROM: 10.1.0.0/24, TO: 10.0.64.0/24). The hub's profile must at least protect (FROM: 10.1.0.0/24, TO: 10.0.64.0/24). In order to support other spokes, the hub's protection profile might be increased to "cover" the addresses (FROM: 10.1.0.0/24, TO: 10.0.0.0/8). The hub's generic profile doesn't provide enough information for it to initiate IPSec connections for outbound traffic to the appropriate spokes; however, the hub can accept IPSec connections from any of the spokes that are protecting more specific subnets than 10.0.0.0/8. Assuming each spoke protects a unique address range and initiates the connection to the hub, the hub will have sufficient information to direct packets to the appropriate spoke if the packets are routed out this protected subnet. Note Mismatched crypto profiles commonly cause IKE phase 2 processing errors, so this model is not recommended. A more appropriate solution to reduce complexity at the hub might be to implement a dynamic crypto map on the hub. In summary, the hub-and-spoke architecture using the native IPSec model provides encrypted simple IP connectivity between the hub-and-spoke sites. Contiguous address assignment of IP address ranges is critical for reducing the complexity of the VPN connectivity. The next section addresses transit routing at the hub site, which highlights the importance of address assignment. Transit Spoke-to-Spoke Connectivity Using IPSecThe simple hub-and-spoke connectivity model described in the previous section provides remote site connectivity services only to the hub site. There is no connectivity enabled between the spokes in this model. Generally, this connectivity is sufficient for many applications such as customersupplier extranets in which the suppliers have no need to communicate among themselves. But, this model doesn't meet the needs of enterprise VPNs where spoke-to-spoke connectivity is occasionally required. This requirement adds an additional provisioning complexity on the IPSec VPN. One option is to build direct IPSec peer relationships between the spokes, effectively turning every spoke into a hub. The subsequent section explores this complex scenario using full-mesh VPNs. For this example, assume that the VPN topology will remain as hub-and-spoke. To achieve spoke-to-spoke connectivity through the hub without building IPSec peer relationships directly between the spokes, the hub site VPN device must provide routing and IPSec protection for transit traffic. You have seen previously that the routing process in a private network provides sufficient information to the hub and spokes such that traffic is directed out the appropriate IPSec-protected interfaces. The same is true for Internet-connected devices for which default routes are common. However, the IPSec protection profiles must be modified to accommodate the new transit spoke-to-spoke traffic flows at the hub. The following sequence of events occurs for transit traffic flows as depicted in Figure 5-4: Packets leaving SPOKE-1-WEST for a host protected by SPOKE-2-WEST will be encrypted by SPOKE-1-WEST with the security association for the VPN-GW1-WEST. The hub VPN-GW1-WEST decrypts the packets arriving from SPOKE-1-WEST. The hub VPN-GW1-WEST routing table decides that the packet is destined to another spoke that is accessible through the same IPSec-protected interface upon which the packet was received. The hub VPN-GW1-WEST encrypts the packet again, which is destined for the remote spoke using the security association with the destination SPOKE-2-WEST. SPOKE-2-WEST decrypts the packet from the hub VPN-GW1-WEST. The remote SPOKE-2-WEST forwards the packet to the destination host. Figure 5-4. Transit IPSec Protection for Hub-and-Spoke Topology[View full size image] In our previous hub-and-spoke example where no spoke-to-spoke connectivity was required, the hub site crypto profile was applied to traffic that originated or terminated at the hub site. For spoke-to-spoke connectivity via the hub, the profiles must be modified to protect every potential spoke-to-spoke source and destination pair. Although the simplest way to achieve this would appear to be by creating a crypto profile that matches any-to-any source-destination pair, unfortunately, this will not work. Recall that the IPSec profiles direct packets to remote crypto gateways following the routing function at the hub site. The key difference is that routing is only directing packets based on the destination address, whereas IPSec directs packets based on the 5-tuplesource address, destination address, IP protocol field, source port, and destination port. The IPSec profiles must associate the subnets assigned to a remote site with that site's IPSec peer endpoint. Likewise, the hub must match the security association with an inverse profile, which the spoke uses to protect its subnet. Figure 5-4 shows the transit routing requirements at the hub site. Note that this method is demonstrated using simple route aggregates in which there is an order of N provisioned crypto proxy statements, O(N), where N represents the number of spokes. With inefficient address assignments, the provisioning may become as complex as configuring O(N^2) proxy profiles. Clearly, you should, at all costs, avoid addressing schemes that don't leverage route aggregation. The topology provides some insight into how the crypto map profiles must be designed. The use of contiguous IP address ranges allows the aggregation of spoke routes using a single CIDR block of 10.0.0.0/16. Table 5-1 shows the discrete crypto proxy matrix required for any-to-any connectivity over the hub-and-spoke topology. Table 5-2 shows the aggregate crypto map profiles required.
As seen in the tables, the aggregate crypto map (that is, 10.0.0.0/8) dramatically simplifies configuration complexity, especially in a large network. The introduction of addresses outside the aggregate address range of 10.0.0.0/0 will increase the configuration complexity. For example, the introduction of an address range of 192.168.0.0/24 on one of the spokes will double the configuration complexity. Also notice that the hub's outbound crypto map profile includes the reciprocal profile for traffic arriving from that spoke. Therefore, the hub knows which peer to use for encrypting traffic for each subnet and also knows which profile to associate for decrypting traffic arriving from each spoke. It is apparent that a properly assigned address space can dramatically simplify the configuration at the hub. The configuration samples that follow demonstrate how the crypto map profiles satisfy the any-to-any communication requirements through the hub-and-spoke topology. The hub configuration for transit VPN traffic is modified such that traffic received from any spoke may be redirected out the same interface (by hair-pinning trafficthat is, by decrypting and re-encrypting a flow) to the appropriate spoke peer. The configuration listing in Example 5-5 is truncated to focus attention on the relevant changes from the previous configuration listing where spoke-to-spoke communication was not allowed. The only change made in the configuration in Example 5-5 is the masked address range for traffic from the hub site. This masked range highlights the importance of a VPN with proper IP address assignment. If any of the spokes protect an IP address range that is non-contiguous with 10.0.0.0/8, then a unique set of IPSec proxies must be defined for each non-contiguous IP address range. Example 5-5. IPSec Hub Configuration for Transit VPN Traffic
Example 5-6 shows the configuration state of the hub site with a source address range in the IPSec proxy that includes traffic from any other spoke. In addition, the IPSec proxy specifies the traffic to be directed to the appropriate spoke even though the hub router only uses a default route to the backbone network. Example 5-6. Native IPSec Hub Configuration State for Transit VPN Traffic
Examples 5-7 and 5-8 show the modified IPSec proxy profile for a selected spoke and the resulting configuration state. The configuration allows the spoke to encrypt and direct traffic to the hub site for traffic destined to any other spoke. Example 5-7. Native IPSec Spoke Configuration for Transit VPN Traffic
Example 5-8. IPSec Spoke Configuration State for Transit VPN Traffic
Note The Cisco IOS product line allows hair-pinning of traffic on the same interfaces. Because the Cisco PIX product line is currently not capable of hair-pinning IPSec traffic on a single interface, a second IPSec-enabled interface is required to hairpin traffic in the PIX. The proper allocation of addresses within the VPN certainly simplifies configuration complexity. Thus far, we have only considered traffic that stays within the VPN. One of the motivations for building IPSec VPNs over the Internet is to provide both VPN and Internet services over a common infrastructure in order to achieve cost optimization. Next, you'll explore how Internet access is coupled with hub-and-spoke topology. Internet ConnectivityInternet access is a typical requirement for most sites within a VPN. In a hub-and-spoke scenario it is possible for the remote spoke sites to have Internet access using split tunneling. Split tunneling is a method of forcing IPSec protection for certain traffic flows leaving an interface while excluding other traffic flows from IPSec protection (for example, Internet traffic). Many enterprises will not accept this model due to increased exposure to security vulnerabilities. The most manageable and secure option for offering Internet access to VPN sites is the centralized firewall option in which all traffic to the Internet passes through a firewall at the hub. You saw earlier that the any-to-any provisioning model at the hub provided insufficient information in order to associate traffic to the appropriate spoke. You also have seen that aggregate profiles simplify configuration complexity. In a properly designed network, the largest aggregate route (that is, any source or any destination) may be used to simplify the configuration. In fact, it may be the only way to get traffic to the Internet because the destination addresses on the Internet are not known a priori. If you consider the requirement for each spoke to send traffic for any address to the hub, the inverse property is for the hub to send traffic with any source to the spoke with the associated destination address. You find in this scenario that all of the transit traffic requirements may be represented by a single aggregated IPSec crypto profile. As a result, the crypto map profiles are significantly simplified, as shown in Table 5-3.
A simple modification to the IPSec proxy profiles on the hub and spoke is all that is required to facilitate Internet access via the hub site. In this example, none of the spokes is allowed to perform split tunneling. Example 5-9 shows the hub configuration listing and Example 5-10 shows the SPOKE-1-WEST configuration modifications. Example 5-9. Native IPSec Hub Configuration for Internet Access
Example 5-10. Native IPSec Spoke Configuration for Internet Access
Clearly, the transit communication model with Internet access simplifies the IPSec profile for both the hub and spoke site. What we have compromised is the granularity of security control mechanisms for protecting specific flows of traffic between the sites. Usually this is not an issue for enterprise traffic. Scalability Using the IPSec Connection ModelThe IPSec VPN hub-and-spoke model introduces new constraints that the designer may not have encountered with traditional VPNs. The fact that the IPSec profiles effectively act as routing entries may simplify the routing protocols where default routes exist; however, the complexity of the IPSec profiles mitigates the advantage. A large IP VPN with poorly allocated address space may require O(N^2) IPSec configuration profiles at the hub, where N is the number of spokes. The use of aggregate IP address ranges can reduce the number of IPSec configuration entries to O(N) if the designer assigns the appropriate address space to the remote sites. Regardless, the scalability of the hub is critical to the proper functioning of the VPN. The hub must satisfy memory requirements for data structures supporting IKE and IPSec SAs. The hub must also satisfy the additional processing requirements for IKE state management and IPSec data traffic forwarding. The processing constraints will limit the number of spokes supported as well as the volume of transit data. In most cases, hardware-accelerated IPSec data forwarding is required due to the processing requirements associated with encryption. Note While dynamic routing updates may be used to provide explicit routing where default routes are inappropriate, the routing updates typically also require protection. The IPSec profiles discussed thus far do not address the protection of routing updates where the source and destinations are associated with the IPSec tunnel endpoints. The addition of IPSec profiles protecting routing updates (for example, BGP peers within the VPN) significantly increases the configuration complexity. Also note that current IPSec standards do not address IPSec protection of multicast and broadcast packets typically used with dynamic routing protocols such as OSPF, RIP, and EIGRP. Aside from IPSec scalability, many other scalability constraints need to be addressed to accommodate the building of large-scale VPN networks. We have emphasized IPSec scalability simply because it is likely to be one of the constraints that the operator will encounter early on. You will find that solving the IPSec scalability constraint will likely reveal another scalability constraint such as queuing, routing, or packet-forwarding constraints. Next, you will look at another IPSec model that presents a completely different scalability model. GRE ModelThe hub-and-spoke architecture built with IPSec-protected GRE tunnels significantly simplifies the VPN design process. The primary difference between the GRE model and the IPSec model is the range of addresses protected by the IPSec crypto profile. In the GRE model, the hub crypto map defines a protection profile for encapsulated data originating from the hub's tunnel source and destined to each spoke's tunnel interface. The primary advantage is that IPSec profiles do not have to reference addresses assigned in the private LAN. All of the private user traffic is encapsulated inside the tunnel that is represented by a single source and a destination address. Likewise, the spoke requires a crypto map that protects the tunnel source and destination address. The simplification of the IPSec profiles may conserve IPSec memory resources if the tunnel hides the non-contiguous private address ranges that do not follow efficient IP address allocation schemes. Figure 5-5 provides the topology for the GRE hub-and-spoke model. Figure 5-5. GRE Hub-and-Spoke VPN Topology[View full size image] The hub configuration for the hub-and-spoke topology is provided in Example 5-11. Particular emphasis is placed on the modifications to the IPSec proxy profiles. The IPSec access list specifies the protection of traffic from the hub's GRE tunnel IP address (9.1.1.22) to each spoke's GRE tunnel IP address (9.1.1.130, 9.1.1.134, 9.1.1.138, and so on). The protected LAN IP addresses associated with the spokes are explicitly routed into the GRE tunnels. The router encapsulates the packet using the specified GRE tunnel parameters. The GRE-encapsulated packets are subsequently encrypted by IPSec and routed out the serial interface to the backbone. Typically, we will use transport mode on the IPSec tunnel protection profile such that the GRE-encapsulated IP addresses are visible after encryption. Example 5-11. IPSec-protected GRE Hub Configuration Listing
Chapter 3, "Enhanced IPSec Features," that uses the 'tunnel protection' command syntax. This configuration model can also be applied for all the IPsec over GRE examples in this chapter. This new model requires the crypto map configuration to be applied only to the tunnel interface and not the physical interface. The only caveat of the 'tunnel protection' configuration model is the lack of support for GRE keepalives. Other than this caveat the newer model is a more efficient configuration method and recommended. The configuration results in a set of crypto maps that protect traffic only between the GRE tunnel endpoints; however, all of the VPN traffic is routed through the tunnels. Therefore, the VPN traffic is always protected while traffic passing outside of the tunnel remains unprotected. Example 5-12 shows the state of the hub configuration. Example 5-12. GRE Hub Configuration State
Note It is critical to note that traffic that is supposed to be routed through a tunnel that is down will be routed out the public interface unencrypted. A common practice is to insert an aggregate static route to a NULL interface for VPN traffic. This drops VPN traffic for an unreachable spoke as opposed to passing it unencrypted to the backbone. The crypto profile associated with the interface Serial1/0:0 in Example 5-11 protects only the traffic that matches the GRE tunnel profiles specifically protecting the traffic to the spokes. It is important to note that the route forwarding established in Example 5-12 will route any traffic not matching a route to a spoke to the Serial1/0:0 interface. This traffic will not match the crypto profile; therefore, it will not be encrypted. This may be acceptable if the traffic is intended to reach the Internet via this path. If that is not the case, then you will want to prevent traffic from inadvertently leaving the protected network. We can do this by forcing all the traffic that doesn't match a spoke to NULL route, thereby dropping the traffic. You can use the following to prevent traffic destined to undefined 10.0.0.0/8 addresses from leaving the VPN:
The reciprocal configuration required of a spoke is provided in Example 5-13. The crypto transform must match the hub (there is no IPSec encapsulation required because GRE encapsulation is used). An important distinction is that you only need to insert a static route for the GRE tunnel endpoint in order to make the tunnel operational. The static route for the hub's protected address space is directed into the GRE tunnel. Example 5-13. GRE Spoke Configuration Listing
Note from the spoke's configuration state shown in Example 5-14 that only the tunnel will be protected. The only traffic passed to the backbone is the encapsulated traffic that is encrypted. All of the VPN traffic will be forced into the GRE tunnel and unreachable destinations are dropped. Example 5-14. GRE Spoke Configuration State
Once the tunnels are defined and protected from each spoke to the hub, the routing plane for tunnel connectivity must be established. The tunnel source address may be associated with one of the public interfaces or a publicly addressable loopback interface. If the remote peer's tunnel destination address is not directly connected, the source VPN device will need a route to the tunnel destination. The routes between tunnel endpoints may be learned via dynamic routing on devices between the tunnel endpoints. Alternatively, the VPN devices may have static routes defined to reach the peer's tunnel endpoint. At a minimum, the peer's encapsulating tunnel address must not be routed into the local tunnel interface. Doing so will create a recursive routing loop that will prevent tunnel establishment. An example of recursive routing is when the destination for a tunnel termination point is routed into the local tunnel interface. Once the tunnel interface is defined and has a viable route to the destination address, the status of the interface will transition to an operational UP state. This is true regardless of the reachability of the peer. Note A tunnel may provide an UP status, yet fail to pass traffic to the tunnel peer. This may occur when a locally defined static route provides a viable route out of the VPN device but an end-to-end tunnel path does not exist. A viable tunnel path assumes that each router between the tunnel endpoints has routes to these endpoints. In addition, an IPSec security association must be capable of being established for the tunnel. By using GRE keepalives, you can verify that a viable routing path exists and that the IPSec security association is established properly. With a viable tunnel path, the VPN routing plane may be established through the tunnel. The simplest case is to use static routes into each tunnel interface. The hub must define a static route into the tunnel for each spoke's protected address range. If the spoke's protected address range is not contiguous, multiple static routes may be required. Likewise, each spoke will require a static route to the hub's protected address space. For complex routing scenarios, we may wish to use a dynamic routing protocol within the VPN in order to avoid installing numerous static routes. This is easily accomplished by associating a dynamic routing process with the tunnel interface's assigned address. The tunnel interface may be bound to a LAN interface, a WAN interface, a loopback interface, or may use an assigned IP address. Figure 5-6 shows several options for binding dynamic routing processes to the tunnel interfaces. Figure 5-6. Routing Protocol Binding Options[View full size image] Note The tunnel interface's assigned address is not the tunnel interface's encapsulating source address. The tunnel interface may have a unique IP address assigned, use an unnumbered address while binding to another interface, or have no address assigned at all. The objective is to bind the VPN routing process to the tunnel interface's assigned address even if the tunnel is bound to another interface. The choices for tunnel address assignment provide great flexibility in determining which routing process will be invoked for the tunnel. As a general recommendation, the model shown in Figure 5-6 provides the most flexibility and control. It does require management of additional address subnet ranges on the tunnels that are distinct from the LAN and WAN subnets. These distinct address ranges assigned to the tunnel interfaces allow explicit control of the IGP routing protocol's scope. A routing process defined on the hub will likely redistribute routes learned from one spoke to another spoke where the hub is defined as the next hop. Perhaps you don't want the spokes to automatically discover routing paths to the other spokes via the hub. In that case, you must consider various methods to avoid or prevent transit routing through the hub. One approach might be to apply static access control lists (ACLs) on the hub to block spoke-to-spoke traffic. This approach becomes quite cumbersome and is prone to configuration errors. A better alternative is to select a routing protocol that allows route filters. Link-state routing protocols (such as OSPF and IS-IS) do not meet this requirement because the routing database must be synchronized on all the nodes. A distance-vector routing protocol such as EIGRP or RIPv2 will suffice. You may install route filters on the hub that only pass IP address ranges associated with the hub to the spokes. Blocking all the spoke routes from being distributed to any other spoke effectively prevents spoke-to-spoke connectivity. The configuration for the hub remains essentially the same as the static routing scenario except for the dynamic routing process. The Example 5-15 configuration listing for the hub shows how the EIGRP routing process is bound to the Ethernet4/0 interface while the tunnel interface is also bound to the Ethernet4/0 interface. The EIGRP process will establish peers over both the Ethernet4/0 and the tunnel interfaces. Example 5-15. GRE Hub Configuration with Dynamic Routing
The EIGRP process will establish a neighbor adjacency over each of the tunnel interfaces and dynamically learn the protected IP address ranges for each spoke. Example 5-16 shows the state of the hub router's IP routing table. Example 5-16. Hub Configuration State for GRE with Dynamic Routing
The configuration for the spoke is also modified to establish a dynamic routing process on the tunnel interface. Example 5-17 shows that the EIGRP routing process is bound to the Ethernet0 interface, as is the Tunnel0 interface. This allows the spoke to establish a neighbor relationship with the hub. Example 5-17. Spoke Configuration for GRE with Dynamic Routing
The configuration establishes an EIGRP neighbor relationship between the spoke and hub. Example 5-18 shows the configuration state of the spoke. Note that the spoke has learned two routes via the Tunnel0 interfacethe subnet from the hub site and a second subnet from another spoke that is currently connected to the hub. This example highlights the default paradigm of providing all routes to all VPN sites. Example 5-18. Spoke Configuration State for GRE with Dynamic Routing
Example 5-19 provides a configuration listing that blocks the redistribution of EIGRP routes at the hub router. The hub will still learn all the routes from the spokes; however, the hub will only advertise the 10.1.0.0/16 subnets associated with the hub's protected IP address range. Example 5-19. EIGRP Dynamic Routing with Route Blocking
The route filter blocks all the other spokes' VPN routes such that each spoke knows how to reach only the hosts at the hub site. Example 5-20 shows the new IP routing state of SPOKE-2-WEST. Example 5-20. Filtered Routes on the Spoke for GRE with Dynamic Routing
The use of dynamic routing within the GRE tunnels in the hub-and-spoke model changes the IPSec tunnel protection paradigm. The native hub-and-spoke model allows connectivity only between those address ranges that are explicitly defined by the IPSec profiles. In contrast, the use of dynamic routing in GRE tunnels protected by IPSec allows connectivity between all sites unless explicitly prevented. We have shown that GRE encapsulation with IPSec protection may significantly simplify the VPN design process. The IPSec profiles are much simpler to define because they are associated only with the GRE tunnel endpoints as opposed to the private LAN address space. Unfortunately, you lose the ability to explicitly define IPSec protection models for different traffic types because the crypto profile identifies only the GRE protocol. The advantage is that you can pass any traffic you chose through the tunnel while avoiding changes to the IPSec profile. With the ability to pass routing protocols through the tunnel, you are able to dynamically build the routing paths between the hub and spokes. You have also seen that the connectivity paradigm shifts from connect-if-allowed to connect-unless-blocked when dynamic routing protocols are used through IPSec-protected tunnels. The next section will show how to exploit this capability when we define transit hub-and-spoke architectures using GRE. Transit Site-to-Site ConnectivityYou have already seen that dynamic routing within the GRE tunnels implicitly provides connectivity between any of the VPN sites. Assuming transit traffic may pass through the hub to the other spokes, the choice of routing protocols is expanded to include link-state routing protocols such as OSPF or IS-IS. The IPSec profiles associated with the GRE tunnels remain the same as in the previous example; however, the routing assumptions must be qualified. First, consider the case in which Internet access is not required. Each spoke will require a route via the hub for all the other spoke's protected address ranges. With the dynamic routing process configured on the spoke and bound to both the private interface and the tunnel assigned address, the protected address range will be propagated to the hub. In addition, any routes learned via this interface may also be propagated to the hub. The hub site will need a routing process that binds to each of the tunnel interface's assigned address. The hub site subsequently relays the routes to other spokes. As a result, all the spokes learn a viable path to the protected addresses on all the other spokes (as well as the hub). The paradigm of allowing all connectivity unless explicitly denied applies in this case. This is true for any address space included in the VPN routing plane; therefore, the designer must use care in associating the routing process with all the interfaces on the VPN device. In order to avoid recursive routing, tunnel endpoint IP addresses should not be propagated through the VPN routing plane. Usually, this is not a problem because the tunnel endpoint addresses are typically assigned from the public IP address space when the tunnels traverse the Internet. If the tunnel endpoints use private addresses from the same IP address block as the protected addresses, care must be taken to ensure that the tunnel endpoint addresses have a preferred path that does not use the tunnel as the next hop. A separate backbone routing plane with a lower administrative weight may be appropriate to ensure that the physical interfaces are always preferred for routing to remote tunnel endpoints. The backbone routing process can be bound to the public physical interfaces and tunnel endpoint addresses. This is common when traversing the Internet. The backbone routing plane uses BGP, whereas the VPN routing plane might use EIGRP. Transit Site-to-Site Connectivity with Internet AccessNow to address the requirement of providing Internet access to the spokes. The use of dynamic routing protocols in the VPN tends to break down in this scenario. Although propagating all the Internet routes to a spoke is possible, it may not be the most viable approach because the Internet routing table is quite large and spoke routers typically have limited routing memory. A more appropriate approach is to provide a default route to the spoke via the VPN routing plane. As a result, the spoke will have a path to any address (including other VPN addresses) via the tunnel. The hub will still need to have a path for return traffic to the appropriate spoke site; therefore, a VPN dynamic routing plane may continue to be useful. In the absence of a dynamic VPN routing plane, the use of hub-and-spoke architecture facilitates a fairly simple model in which static routes easily accommodate the connectivity requirements. Again, a key point is that the tunnel endpoints must be routed outside of the VPN routing plane. This presents an interesting scenario for the IPSec VPN built over the Internet where the traditional destination of the default route is to the Internet next hop using the backbone routing plane. In contrast, you must now use the default route in the VPN routing plane. Therefore, you must replace the default route in the backbone routing plane with an explicit route for the remote tunnel endpoint. In Example 5-21, the EIGRP routing process is bound to the tunnel interfaces; however, doing so only propagates the default route to the spokes. The spokes continue to propagate their respective protected networks to the hub. This allows a host at any spoke to route packets to the hub site where the packets are redirected to the appropriate spoke site. Example 5-21. Hub Configuration for GRE with Default Route Propagation
The routing table for the hub is shown in Example 5-22. Note that the hub learns all of the spoke routes via the tunnels. Example 5-22. Hub Default Routing State for GRE
The spoke configuration requires only a routing process that is associated with the tunnel interface, as shown in Example 5-23. The spoke will now propagate the routes learned via the Ethernet0 interface to the hub router. Note that the static route for the remote tunnel endpoint (that is, 9.1.1.22) prevents the recursive routing of the tunnel. Example 5-23. Spoke Configuration for GRE with Spoke Default Routing
Example 5-24 shows the routing state of the spoke. The spoke uses the default route learned through the tunnel; however, it has not received any updates from the hub on the other spoke subnets. Any traffic destined to the Internet or other spokes will be directed into the tunnel such that IPSec protection may be applied. Encapsulated traffic destined for the hub tunnel endpoint will be routed outside of the tunnel via the Serial0 interface. Example 5-24. Spoke Default Routing State for GRE
The GRE model with transit hub routing provides a very simple method of providing Internet access. In addition, the security model for the spoke is quite simple. The loss of the tunnel (or IPSec connection protecting the tunnel) to the hub removes all external routing paths. The only external path remaining during loss of connectivity is the path to the IPSec peer identity and tunnel endpoint. Scalability of GRE Hub-and-Spoke ModelsThe size of the hub-and-spoke VPN may be constrained by the hub's throughput capacity. The hub must serve as a transit routing node for both Internet and spoke-to-spoke connectivity. Spoke-to-spoke traffic must be decrypted and re-encrypted. This transit traffic doubles the crypto hardware's processing requirements. The hardware encryption capability is usually a gating factor when large packets are sent, because they must pass through the encryption engine twice. Smaller packets typically overwhelm the processing power on the CPU before the crypto hardware's capacity is exhausted. Ironically, when no split tunneling is used at the spoke, Internet traffic initiated from the spoke is encrypted between the hub and spoke while it passes in the clear from the Internet to the hub site. Introducing split tunneling at the spoke eliminates the Internet transit traffic load at the hub; however, it increases the complexity of security. The complexity of IPSec profiles is significantly simplified with the GRE tunneling model. We have shown that GRE tunnels aggregate multiple IP flows (as well as other protocols) into a single IP address pair represented by the tunnel. The IPSec proxy statements are required only to identify the tunnel endpoints as opposed to all the sources and destinations of traffic flowing through the tunnel. As a result, the flow consolidation reduces the number of IPSec SAs. This is particularly useful where the VPN uses non-contiguous IP address ranges that cannot be represented as address aggregates. The number of IKE SAs remains the same as in the native IPSec tunnel model because each spoke still requires the control connection to the hub. The complexity of provisioning is minimized through the aggregation of flows into a single pair of IPSec SAs and one IKE SA. Chapter 6, "Designing Fault-Tolerant IPSec VPNs." In summary, the hub-and-spoke VPN built with IPSec-protected GRE tunnels is very popular. The topology simplifies IPSec configuration while providing the ability to transport multiple protocols. The scalability of the VPN architecture is usually constrained by the capabilities of the hub. The hub scalability limits include packet processing rates, security associations, routing neighbor adjacencies, link-state management functions, and configuration memory constraints. Also, note that the point-to-point GRE tunnels require knowledge of the tunnel endpoints at the time of configuration. This makes the GRE model difficult to use on access environments in which IP addresses are dynamically assigned by the service provider. The next section provides dynamic client connection alternatives for the hub-and-spoke model that may simplify the configuration while addressing some of the constraints identified in site-to-site architectures. Remote Access Client Connection ModelIn this model, the spokes are remote access clients connecting to a hub site. The remote client connection to the hub typically occurs over the public Internet, which means the client IP address could be any publicly routable address in the Internet; therefore, the hub must allow incoming IPSec connections from any IP address that is not known in advance to the hub. This is different from the site-to-site model in which each spoke IPSec tunnel endpoint is known in advance and is statically configured on the hub. Note The IPSec profiles configured at the hub, or referred to by the hub, define the range of protected addresses for the client. The range might limit access to specific networks at the hub site or allow access to the Internet via the hub. Likewise, the hub may exclude protection of specific IP address ranges (that is, split tunneling) such that traffic directed to these sites does not get encrypted and directed to the hub. One of the most commonly excluded addresses is the local subnet to which the client is connected. This feature allows the client to use local resources such as printers and file servers while providing IPSec encryption for all remote services and Internet services. One of the principle advantages of the client connection model is that hub configuration is dramatically simplified. Additionally, the VPN is automatically built with each incoming client connection. Next, you'll explore how this simple creation of a hub-and-spoke VPN can accommodate multiple hosts on a remote client connection. Easy VPN (EzVPN) Client ModeThe client mode works well in a telecommuter situation in which the remote client is just one device that originates the IPSec connection. You saw in the previous section how the client mode simplifies the configuration at the hub dramatically by consolidating the security policy at the hub (or by having the hub refer to a database for security policy). Given the advantage of the client mode, it is worthwhile to extend this model to a site-to-site connection. The EzVPN client mode does just that! In this model, the remote client (instead of being a single PC initiating the IPSec connection) is a router that operates in EzVPN mode with multiple hosts behind the router. From the perspective of the hub, the incoming connection looks like it originated from a single software client. The hub leverages all of the previously defined authentication and authorization models defined in Chapter 3, "Enhanced IPSec Features," whereas the remote site emulates a software client. Let's look at the process of connection establishment in this model. Recall from the previous section that the hub assigns a single IP address to the client during the authorization phase. The obvious question in the EzVPN model is how multiple hosts at the remote site can use a single assigned IP address. The EzVPN solution addresses this through the use of a technique known as Port Address Translation (PAT). Figure 5-7 shows a typical EzVPN deployment scenario. Figure 5-7. EzVPN Client Mode Connectivity[View full size image] Figure 5-7 shows an EzVPN-capable router with hosts behind it while IP connectivity is assumed to be available between the remote router and the hub site. In this model, the EzVPN router is also serving as a DHCP server for all the hosts behind it. All the remote hosts obtain their private IP addresses using DHCP. Now, when a host behind the EzVPN router needs to send traffic to a host on the hub site, the remote host forwards the packet to the EzVPN router that is the default gateway for this host. Once the packet arrives into the EzVPN router, routing configuration on this node determines that this traffic is destined out of the protected interface, and initiates an IPSec session to the hub. It establishes an IPSec connection to the hub and receives an assigned private address. The IKE SA establishes an IPSec proxy profile that protects traffic from the assigned IP address to the hub site addresses. The host source IP address is mapped (using Port Address Translation) to the address assigned by the hub to the EzVPN router. In addition to mapping the source IP address, the original source port address is mapped to a unique port address in order to avoid conflict with other hosts. As a result, the host is represented to the hub as a unique data flow from the assigned IP address and unique source port address. For return traffic to the host, the process is reversed such that traffic destined to the remote site's protected IP address and uniquely assigned port is mapped back to the originating host's IP address and original port. Now that the IPSec session is established between the remote site EzVPN router and the hub, additional application flows may originate from the same host or other hosts at the remote site. Each unique flow (source IP, destination IP, protocol, source port, and destination port) may connect to hub resources with each flow dynamically assigned a unique source port on the remote router's protected IP address. The PAT process makes each flow unique. All of these flows will use the original IPSec SA pair; therefore, the number of IPSec connections is minimized on the hub site. The configuration and routing state supporting the client mode IPSec connectivity model is shown in the following examples. Example 5-25 provides a configuration example of an IOS router allowing incoming IPSec connections from dynamically assigned spoke addresses. The hub does enforce two phases of authentication in the same manner that a software client is required to supply a group name and password as well as a username and password. Example 5-25. Hub Configuration for Client Mode EzVPN Connectivity
Example 5-26 shows the SPOKE-1-CENTRAL EzVPN client that provides a DHCP server for the locally connected hosts within the 10.0.66.0/24 address range. The egress interface is specified for default routes and IPSec protection using EzVPN. Note that the EzVPN mode is specified as client mode. Only the groupname and password is provided in this example; the username and password is requested via the CLI during IKE initialization and authentication. Example 5-26. Spoke Configuration for Client Mode EzVPN Connectivity
The crypto maps established between the hub and spoke are provided in Examples 5-27 and 5-28. Emphasis is placed on the IPSec proxy profiles that protect traffic from the assigned EzVPN IP address (for example, 10.1.0.102 on SPOKE-1-CENTRAL) to the hub's protected address range. In this example, all traffic is protected including traffic destined for the Internet. Example 5-27. Hub Crypto State for an EzVPN ClientConnected Spoke
Example 5-28. Spoke IPSec SA State for an EzVPN Client Connection
The client-connected EzVPN spoke will maintain a translation for each and every unique flow. Note in Example 5-29 that each ICMP Echo packet represents unique flow from 10.0.66.1 to 10.1.0.2. A stream of packets from a TCP or UDP traffic flow would only require a single translation. Each translation is created dynamically as packets leave the spoke site destined for the hub; therefore, connections originating from the hub (or other spokes) cannot reach hosts behind this spoke. Example 5-29. PAT Mapping for an EzVPN ClientConnected Spoke
An obvious drawback to the client mode is the limitation that sessions cannot be initiated from other sites to a host on a remote site. Sessions initiated to a host at a remote site will have a destination port that is not valid on the remote site EzVPN router, and the traffic will be dropped. As a result, the Client Extension Mode is not appropriate for VPN topologies in which servers are located at the remote sites. Note Servers may reside at the remote site; however, they would only be accessible to hosts at that remote site. An architectural model that fulfills this requirement is one in which the remote site server caches data from the hub site. In this connection model, the remote site server must initiate the connection to the hub site server and synchronize data using a single flow. Despite the limitations of the Client Extension Mode, it is still quite useful in a number of VPN architectures. It is particularly helpful for small remote sites where almost all the network resources reside at the hub site. You have seen how the client connection model simplifies the configuration of the hub by dynamically allowing incoming connections. We have augmented this model with the Client Extension Mode enabling multiple remote hosts to use a single IPSec connection from the remote site to the hub. Doing so improves the hub's scalability by reducing the number of IPSec connections. Unfortunately, the dynamic source port allocation and Port Address Translation prevents a number of applications from functioning properly. Next, you'll explore modifications to the Client Extension Mode to accommodate flow establishment in both directions. EzVPN Network Extension ModeThe Network Extension Mode modifies the Client Mode such that a range of protected IP addresses is statically assigned to the remote site router as opposed to a single IP address. The remote site may continue to use a dynamically assigned public IP address. Therefore, the hub must accept incoming IPSec connections from any IP address. The Network Extension Mode deviates from the previous routing models in which the protected IP address is assigned by the hub. Because the IP address is pre-assigned at the remote site, the hub must install a route for this remote IP address range when the remote site is connected. The hub's route to the remote site's protected address range can't be pre-configured. The hub will only learn the appropriate remote site termination point when the IPSec connection is established. During the IKE establishment phase, the protected address range is inserted in the hub routing table using Reverse Route Injection. The hub may propagate the dynamically inserted route to other routers in order to build a viable return path. Figure 5-8 shows the topology that is dynamically built when using Network Extension Mode. Figure 5-8. Hub-and-Spoke VPN with Network Extension Mode[View full size image] The pre-assigned address range allows each host to have a unique IP address. Having a unique IP address for each remote host eliminates the requirement to dynamically map-source ports on flows from the remote hosts. With PAT removed from the process, sessions may be initiated to the remote host's well-known application ports, provided a route exists to the site. Recall that the route is dynamically created in the hub using Reverse Route Injection during the IPSec establishment. Slight modifications are required to the configurations provided in Client Extension Mode. The hub must provide Reverse Route Injection for a remote site's protected subnet in order to establish a return path for packets destined to that spoke's hosts while the spoke must specify the use of Network Extension Mode in order to avoid receiving a dynamically assigned IP address from the hub. Examples 5-30 and 5-31 provide the configuration modifications required on the hub and spoke, respectively. Example 5-30. Hub Configuration Supporting Network Extension Mode
Example 5-31. Spoke Configuration Requesting Network Extension Mode
Note Well-known ports are used for specific services on hosts and routers. Incoming connections must use these well-known ports in order to obtain service. As an example, an SMTP mail server uses the well-known TCP port of 25. Some services, such as VoIP, signal the port address in the call control messages. Modification of the source port through PAT will interfere with the end-to-end connection model and will likely prevent the establishment of the calls. Since Network Extension Mode does not modify the VoIP terminal's IP address and port, IP telephony through IPSec VPNs may be simplified. Also note that remote IP telephony terminals may register with a server at the hub site such that the EzVPN connection is always established. Example 5-32 provides the hub's crypto map and routing state for SPOKE-1-CENTRAL in which emphasis is placed on the IPSec proxy and the static route. The IPSec proxy provides protection for traffic initiated from any remote host assigned a private address by the EzVPN router to any host at the hub site. The static route is dynamically inserted in the hub's routing for the duration of the IPSec connection. Example 5-32. Hub Crypto Map State for Network Extension Mode
Unfortunately, an IPSec connection cannot be initiated from the hub site to the remote site because the remote site's public IP address may not be known a priori. The hub-and-spoke VPN can be dynamically built if each remote site router maintains an IPSec connection to the hub. A simple persistent connection initiated from a remote server to a server at the hub site will sustain the IPSec. Although the IPSec connection may expire, the remote server's persistent connection will likely use a frequent polling mechanism to verify the state of the hub server. The polling mechanism will immediately reestablish the IPSec session, enabling access to the other servers at the remote site. Scalability of Client Connectivity ModelsYou have seen how the client connectivity models enable the dynamic creation of a simple hub-and-spoke VPN, greatly simplifying the configuration requirements at both the hub and spoke. In addition, aggregating each site's route requirements into a single IPSec proxy statement minimizes the number of IPSec sessions. We initially provided a framework for building a hub-and-spoke VPN using the software client mode connection model. The client mode enabled connection capabilities for multiple clients at the remote site by embedding the client connection model in the remote site router. Finally, we enhanced the model with Network Extension Mode. The VPN is still dynamically built while using statically assigned private addresses for each of the sites. The elimination of Port Address Translation enables many more services on the VPN than otherwise. The Network Extension Mode leverages all of the scalability attributes of a client-connected model while providing the look and feel of a more traditional hub-and-spoke VPN. The client connection model provides a reasonably scalable hub-and-spoke network. The number of simultaneously connected remote sites determines the scalability requirements of the hub in terms of IPSec SAs and IKE SAs. The use of Reverse Route Injection eliminates the requirement for establishing a private routing protocol connection between the hub and its spokes. Therefore, the hub is no longer burdened with maintaining routing state. The hub site may continue to use IKE dead peer detection or keepalive in order to validate the IPSec state for each of its connected remotes. The most common scalability constraint incurred by the hub is the volume of data passing through the device as transit traffic. The hub site must route traffic from each of the spokes and mostly likely will provide transit access to the Internet. Most network traffic demands are driven by clientserver connections that tend to be hub-and-spoke in nature. New peer-to-peer applications are slowly changing that paradigm. As these traffic demands increase, the spoke-to-spoke transit traffic passing through the hub becomes a performance constraint. Next, you'll explore how full-mesh architecture addresses this connectivity requirement. |
لطفا منتظر باشید ...
