Implementing Site-to-Site VPN Solutions Flashcards
The three typical logical VPN topologies that you can use in site-to-site VPNs are as follows:
Individual point-to-point VPN connection: Two sites interconnect through a secure VPN path. The network may include a few such individual point-to-point VPN connections that connect sites that require mutual connectivity.
Hub-and-spoke network: One central site is considered a hub and all other sites (spokes) peer exclusively with the central site devices. Typically, most of the user traffic flows between the spoke network and the hub network, although the hub may act as a relay and facilitate spoke-to-spoke communication over the hub.
Fully meshed network: Every network device connects to every other network device. This topology enables any-to-any communication, which provides the most optimal, direct paths in the network and the greatest flexibility to network users.
In addition to the three main VPN topologies, the following are more complex topologies that you can create as combinations:
Partial mesh: A network in which some devices are organized in a full-mesh topology and other devices form either a hub-and-spoke or a point-to-point connection to some of the fully meshed devices. Although a partial mesh does not provide the level of redundancy of a full-mesh topology, it is less expensive to implement. You generally use partial-mesh topologies in peripheral networks that connect to a fully meshed backbone.
Tiered hub-and-spoke: A network of hub-and-spoke topologies in which a device can behave as a hub in one or more topologies and a spoke in other topologies. Traffic is permitted from spoke groups to their most immediate hub.
Joined hub-and-spoke: A combination of two topologies (hub-and-spoke, point-to-point, or full mesh) that connect to form a point-to-point tunnel. For example, a joined hub-and-spoke topology could comprise two hub-and-spoke topologies, with the hubs acting as peer devices in a point-to-point topology.
The figure shows the deployment options for site-to-site VPN deployments:
Basic point-to-point solutions enable you to create simple tunnels to connect two sites, or perhaps a few sites, to corporate headquarters.
DMVPN is a Cisco IOS Software solution for building scalable hub-and-spoke and spoke-to-spoke VPNs with simpler configuration and automatic IPsec initiation.
FlexVPN is the Cisco implementation of the Internet Key Exchange Version 2 (IKEv2) standard. It simplifies large-scale deployments that use multiple VPN solutions, including remote access, teleworker, site-to-site, mobility, managed security services, and others.
GET VPN provides for large-scale, any-to-any connectivity by combining a cryptographic protocol called Group Domain of Interpretation (GDOI) with IPsec encryption. It is a tunnel-less solution that efficiently secures and encrypts IP unicast and multicast traffic. The solution is suitable for deployment over private WANs, such as MPLS.
In a simple point-to-point IPsec VPN configuration:
IKE Phase 1 policies negotiate a Security Association (SA). This step ensures that both peers have compatible encryption, authentication, Diffie-Hellman Group key exchange, lifetime, and hashing algorithm.
Transform sets ensure that both peers transform clear, unprotected packets into encrypted, protected IPsec packets, most likely by using Encapsulating Security Payload (ESP).
Crypto access control lists (ACLs) control which packets should traverse the tunnel and which packets should simply forward normally to the Internet.
Phase 2 crypto maps are where you specify the crypto ACL (what to protect), transform set (how to protect), and the IPsec peer (where to send)
This crypto map then applies to an Internet-facing interface on the peer device.
Instead of applying the crypto map to a physical interface, another option is to use a Cisco IPsec Virtual Tunnel Interface (VTI). This option gives you more flexibility to deploy either static or dynamic point-to-point VTI tunnels with Cisco IOS Software.
The following are the primary benefits of DMVPNs:
Hub-router configuration reduction: Traditionally, configuration on the hub router defines the crypto map characteristics, the crypto ACL, and the Generic Routing Encapsulation (GRE) tunnel interface for each spoke router. The DMPVN feature enables users to configure a single multipoint GRE (mGRE) tunnel interface and a single IPsec profile without requiring crypto ACLs on the hub router to manage all spoke routers. Thus, the size of the configuration on the hub router remains constant even if you add spoke routers to the network.
Automatic IPsec initiation: GRE uses the Next Hop Resolution Protocol (NHRP) to configure and resolve the peer destination address. Thus, this feature allows IPsec to immediately trigger and create point-to-point GRE tunnels without any IPsec peering configuration.
Support for dynamically addressed spoke routers: When you use point-to-point GRE and IPsec hub-and-spoke VPN networks, you must know the physical interface IP address of the spoke routers when you configure the hub router—you must configure the IP address as the GRE and IPsec tunnel destination address. DMVPN enables spoke routers to have dynamic physical interface IP addresses and uses NHRP to register the dynamic physical interface IP addresses of the spoke routers with the hub router.
You will look at ISAKMP operation shortly, but first you will look at ISAKMP configuration. The job of ISAKMP is to negotiate the parameters that associate with SAs. You can make use of the acronym HAGLE (hash, authentication, group, lifetime, and encryption) when considering ISAKMP configuration requirements.
hash: This parameter specifies the hash algorithm that will provide data integrity in the ISAKMP SA. Both policies specify sha256, 256-bit SHA.
authentication: This parameter specifies how to authenticate the peer. Both policies in the example specify pre-shared keys. It is very important to understand that pre-shared keys are not used for encryption. They are more like a password that verifies the peer. The idea is that a secret key is known only by the two peers. Imposters that attempt to negotiate an illegitimate tunnel should not know the key and will therefore fail authentication.
group: This parameter is the Diffie-Hellman group number. Policy 10 specifies Group 2, and policy 20 specifies Group 5. At a high level for now, Diffie-Hellman is simply a process to help derive the keys to use to secure the data between the two peers. You will learn more about the usage of this parameter later in the lab exercise when you explore the operation of ISAKMP.
lifetime: This parameter specifies for how long the ISAMKP SA can be used before it must be rekeyed. The value is specified in seconds. The default is 86,400, which is the number of seconds in 24 hours. Both policies explicitly define 43,200, which is 12 hours.
encr: This parameter is short for encryption, which specifies the encryption algorithm that provides privacy for the ISAKMP SA. Policy 10 specifies AES without an argument, which is 128-bit AES. Policy 20 specifies 256-bit AES.
