IPSec VPN Design [Electronic resources]

Figure 5-10. Non-contiguous IP Address Ranges on Full-Mesh Topology

[View full size image]

Figure 5-11. Full-Mesh IPSec VPN with Default Internet Hub

Example 5-9.

Example 5-34. Native IPSec Full-Mesh Spoke Configuration with Default

spoke-1-west #show running-config
!
hostname spoke-1-west
!
crypto isakmp policy 10
hash md5
authentication pre-share
lifetime 3600
crypto isakmp key cisco address 9.1.1.10
crypto isakmp key cisco address 9.1.1.134
crypto isakmp key cisco address 9.1.1.138
crypto isakmp keepalive 10
!
!
crypto ipsec transform-set esp-tunnel-internet esp-des esp-md5-hmac
!
! IPsec Proxy sequence 10 removed for hub site. Refer to default below
crypto map vpn 20 ipsec-isakmp
set peer 9.1.1.134
set transform-set esp-tunnel-internet
match address esp-tunnel-spoke-2-west
crypto map vpn 30 ipsec-isakmp
set peer 9.1.1.138
set transform-set esp-tunnel-internet
match address esp-tunnel-spoke-1-central
! IPsec Proxy default for spoke-to-hub including Internet
crypto map vpn 70 ipsec-isakmp
set peer 9.1.1.10
set transform-set esp-tunnel-internet
match address esp-tunnel-internet
!
interface Ethernet0
ip address 10.0.64.1 255.255.255.0
!
interface Serial0
ip address 9.1.1.130 255.255.255.252
crypto map vpn
!
! default route to the backbone
ip route 0.0.0.0 0.0.0.0 9.1.1.129
!
! Protected address ranges from spoke to spoke
ip access-list extended esp-tunnel-spoke-2-west
permit ip 10.0.64.0 0.0.0.255 10.0.65.0 0.0.0.255
ip access-list extended esp-tunnel-spoke-1-central
permit ip 10.0.64.0 0.0.0.255 10.0.66.0 0.0.0.255
! Protected address range from spoke to hub including Internet
ip access-list extended esp-tunnel-internet
permit ip 10.0.64.0 0.0.0.255 0.0.0.0 255.255.255.255
end

The full-mesh VPN is a highly desirable architecture when a large amount of traffic must be sent from any given site to all the other sites. Applications such as VoIP might drive this requirement even when the call control is located at a single site in the VPN. The bearer traffic for VoIP will want to follow the shortest path between two sites. With a full-mesh IPSec VPN, the VoIP-bearer traffic may avoid passing through a hub site where the traffic must be decrypted and subsequently re-encrypted. Another application that requires any-to-any connectivity is IP multicast. Unfortunately, the earlier implementations of IPSec were not designed to handle point-to-multiple traffic peers; therefore, this architecture does not handle multicast streams in the VPN.

In summary, the full-mesh IPSec VPN does allow site-to-site traffic to pass directly between the sites without having to traverse the hub. The advantages of any-to-any connectivity are offset by the additional configuration complexity required to build the full-mesh IPSec proxy statements. In addition, the improper assignment of IP address ranges will further complicate the configuration. We have also introduced additional scalability constraints in the VPN devices because every site must effectively become a hub for its protected address range. Every site must handle the maximum potential number of IKE and IPSec SAs necessary to reach every other site's protected address space. A site with fewer simultaneous traffic demands to every other site might be able to use a less scalable device. This assumption is based on the premise that IKE and IPSec SAs are instantiated only when there are active traffic demands between the two peers.

Some IPSec equipment such as the Cisco VPN 3000 Series devices activate IKE and IPSec SAs once configured in the router. In contrast, the Cisco IOS based devices establish IKE and IPSec SAs only when traffic flows match the IPSec profiles. The tradeoff between the two models is a delay during tunnel establishment versus a permanently allocated resource for idle IPSec tunnels. The IOS devices must negotiate IKE and IPSec SAs prior to passing traffic between the sites. The VPN 3000 devices pre-negotiate the LAN-to-LAN SAs such that traffic may pass immediately through the IPSec tunnel. Clearly, the permanently established full-mesh of IPSec SAs creates a scalability constraint for platforms with limited memory.

There are many trade-offs that the network architect must consider when building the full-mesh VPN. In this chapter, you've seen a few of the more critical design elements. One of the most challenging aspects of full-mesh VPNs built with IPSec is managing the IPSec proxy statements as the VPN evolves. As new sites or IP subnets are added, all of the other sites must be configured to accommodate the address ranges and IPSec termination points. The next section explores the use of GRE to simplify some of the configuration aspects of the full-mesh IPSec VPN.

GRE Model

As you saw demonstrated in the hub-and-spoke architecture, IPSec-protected GRE tunnels simplify the IPSec proxy statements by aggregating traffic flows into a single source/destination IP address pair. The same principles apply to the full-mesh model in which IPSec protects GRE. Even IP multicast and non-IP routing protocols may leverage the IPSec-protected GRE tunnel. As the size of the VPN grows, the configuration complexity still increases as O(N^2); however, noncontiguous IP address ranges do not impact the IPSec proxy statements. The number of IPSec connections is bounded by N(N-1)/2. The configuration complexity is moved to the IP routing at each site. The protected IP address ranges are simply routed into the tunnels. In the absence of a dynamic routing protocol operating through the VPN tunnels, the number of static routes required is modeled as N(N-1) + M(N-1), where N is the number of sites in the VPN and M is number of non-contiguous IP address ranges at any site. The full-mesh VPN using static routes over IPSecprotected GRE tunnels is twice as complex as the native IPSec tunnel model because all the adjacencies must be configured in both the routing plane and the IPSec peer statements. You can simplify the routing configuration by applying a dynamic routing protocol over the GRE tunnels.

Now, to consider the impact of a dynamic routing plane through the GRE tunnels. The introduction of dynamic routing through the GRE tunnels minimizes the configuration complexity by eliminating the static routes. Assuming the routing protocol is capable of dynamically building routing adjacencies through the tunnels (for example, EIGRP, OSPF, and RIPv2), the only configuration needed is configuring the IPSec connections for the GRE tunnel endpoints and applying the routing protocol to the tunnel interface. Figure 5-13 shows how the routing is modified based on the association of a routing protocol to the tunnel interfaces.

Figure 5-13 highlights the fact that an IGP routing process will have to evaluate many potential paths when building the routing topology. Each router in the full-mesh VPN must build a shortest path tree that includes every path available between every router in the VPN. Of course, almost all of these paths are discarded because the router eventually converges on the path that is directly established between the two routers. In all likelihood, the loss of a direct path between two routers means that the remote peer is off the network and all the other potential paths are invalid as well. The full-mesh IGP topology places an extreme load on small VPN routers due to the computational complexity.

The configuration listing in Example 5-35 shows how the "spoke" with full-mesh connectivity requires a unique tunnel, crypto map, and access list for each peer in the network. The route process is bound to the entire set of tunnel interfaces such that protected addresses are dynamically propagated and learned through the tunnels. The explicit route statements are required in order to avoid recursive routing loops because the hub will propagate a default route to the spoke via Tunnel0.

Example 5-35. Full-Mesh GRE Spoke Configuration with Dynamic Routing and Default Route via the Hub

spoke-1-west#show running-config
!
crypto isakmp policy 10
hash md5
authentication pre-share
lifetime 3600
crypto isakmp key cisco address 9.1.1.10
crypto isakmp key cisco address 9.1.1.134
crypto isakmp key cisco address 9.1.1.138
crypto isakmp keepalive 10
!
crypto ipsec transform-set esp-tunnel-internet esp-des esp-md5-hmac
mode transport
!
crypto map vpn 10 ipsec-isakmp
set peer 9.1.1.10
set transform-set esp-tunnel-internet
match address gre-tunnel-vpn-gw1-east
crypto map vpn 20 ipsec-isakmp
set peer 9.1.1.134
set transform-set esp-tunnel-internet
match address gre-tunnel-spoke-2-west
crypto map vpn 30 ipsec-isakmp
set peer 9.1.1.138
set transform-set esp-tunnel-internet
match address gre-tunnel-spoke-1-central
!
interface Ethernet0
ip address 10.0.64.1 255.255.255.0
!
interface Tunnel0
ip unnumbered Ethernet0
tunnel source 9.1.1.130
tunnel destination 9.1.1.10
crypto map vpn
interface Tunnel1
ip unnumbered Ethernet0
tunnel source 9.1.1.130
tunnel destination 9.1.1.134
crypto map vpn
interface Tunnel2
ip unnumbered Ethernet0
tunnel source 9.1.1.130
tunnel destination 9.1.1.138
crypto map vpn
!
interface Serial0
ip address 9.1.1.130 255.255.255.252
crypto map vpn
!
router eigrp 100
network 10.0.64.0 0.0.0.255
!
ip route 9.1.1.10 255.255.255.252 9.1.1.129
ip route 9.1.1.132 255.255.255.252 9.1.1.129
ip route 9.1.1.136 255.255.255.252 9.1.1.129
!
ip access-list extended gre-tunnel-vpn-gw1-east
permit gre host 9.1.1.130 host 9.1.1.10
ip access-list extended gre-tunnel-spoke-2-west
permit gre host 9.1.1.130 host 9.1.1.134
ip access-list extended gre-tunnel-spoke-1-central
permit gre host 9.1.1.130 host 9.1.1.138

The simplification of this configuration does not come without a cost. With dynamic routing through the tunnels, the routing adjacencies and IPSec SAs are always established. This requires every site to have its entire set of configured IPSec SAs active. In addition, the routing adjacencies require state management that places additional processing burdens on the processor. These routing design constraints are similar to those incurred when implementing a full-mesh VPN using a classic FR/ATM network. The number of routing and IPSec adjacencies that any given site can simultaneously maintain provides an upper bound for the size of the VPN. The route calculation functions are fairly processor intensive, especially given the number of shortest path trees that a router must evaluate. Dynamic routing protocols such as EIGRP and OSPF provide a rapid means of convergence and fault detection. A large full-mesh network with link-state routing protocols is sensitive to IPSec failures. An excessively large number of routers and paths may extend the initialization or convergence time, making the network unusable. Extreme caution is advised when designing a full-mesh network that approaches one of the router's maximum limits (for example, IKE, IPSec, routing adjacencies, or interfaces).

The full-mesh IPSec-protected GRE network does support Internet access with or without split tunneling. Split tunneling allows the IPSec tunnel endpoints to use the default route to the backbone whereas the private addresses are propagated using dynamic routing over the GRE tunnels. A design that does not use split tunneling requires propagation of the default route from the designated Internet access router. Other routers that receive the default route through the GRE tunnel will need a more explicit path for their IPSec peer IP address that does not use the GRE tunnel in order to avoid recursive routing.

The next chapter presents methods for building more scalable IPSec networks that take advantage of dynamic routing topology. It is evident at this point that the persistent full-mesh of IGP neighbor establishment should be avoided. Likewise, you will have to address the routing protocols limitations with the breadth and depth of the shortest path tree calculations in order for the system to scale to hundreds or thousands of sites.