Site-to-site Virtual Private Networks (VPNs) are VPNs that are established between dedicated VPN devices. Site-to-site VPNs allow the users residing on the LAN on either side to communicate securely. The advantage of site-to-site VPNs is that they negate the need to install VPN client software on the hosts that reside on either side of the LAN. Instead, the secure connection between the VPN gateways is transparent to the end users. Cisco IOS software supports several site-to-site VPN solutions. These solutions, which are described in the following sections, include the following:
- Traditional IP Security VPN
- Cisco Easy VPN
- DMVPN
- Group Encrypted Transport VPN
NOTE: Before we delve into these specific VPN solutions, the following section briefly describes IP Security (IPsec), which is the core technology used in these solutions.
IPsec is defined and standardized in RFC 2401. Using a combination of hashing, symmetric key cryptographic algorithms, and asymmetric key cryptographic algorithms, the IPsec framework offers the following security services:
- Peer authentication
- Data confidentiality
- Data integrity
- Data origin authentication
- Replay detection
- Access control
- Traffic flow confidentiality
IPsec uses security association (SA) to provide security to a given IP connection. IPsec SAs are unidirectional, which means that two SAs are required for bidirectional data communications sessions. Internet Security Association and Key Management Protocol (ISAKMP) describes the framework for key management, and defines the procedure and packet format necessary to establish, negotiate, modify, and delete SA. ISAKMP offers the identification of the peers only; it does not offer a key exchange mechanism. ISAKAMP is documented in RFC 2408 but was made obsolete by RFC 4306, which standardized the Internet Key Exchange (IKE) version.
IKE is a hybrid protocol combining ISAKMP, Oakley key exchange, and the Secure Key Exchange Mechanism (SKEME) protocol. Oakley describes a series of key exchanges, called modes, and details the services provided by each. These services include perfect forward secrecy for keys, identity protection, and authentication. SKEME describes a versatile key exchange technique that provides anonymity, non-repudiation, and quick key refreshment.
IKE defines the mechanism for exchanging keys. IKE derives authenticated keying material and negotiates SAs that are used for the Encapsulating Security Payload (ESP) and Authentication Header (AH) protocols. IKE uses UDP port 500 and is documented in RFC 2409, and updated in RFC 4306, which is IKEv2 (the current IKE standard).
IKE is a two-phase, multimode protocol that offers the following three methods of authenticating a remote peer:
- The public key encryption method uses a pair of keys, a private key and a public key, to establish a secure authentication communications channel between two peers.
- The pre-shared key method uses statically defined keys and is the most commonly used method because of its ease of deployment; however, it should be noted that this method is not scalable or secure.
- The public key signature method, also referred to as the RSA-Signature method, is the most secure method and requires Public Key Infrastructure (PKI).
IKE phase 1 verifies the identity of a remote peer and the two peers establish a secure authentication communications channel. This phase is primarily concerned with the protection suite for IKE messages. IKE phase 1 also protects the negotiation of phase 2 communication. Phase 1 operations are required infrequently and can use main mode or aggressive mode. These methods of operation are described as follows:
- Main mode is the default method used in most implementations. Main mode defines six message exchanges to establish SA. Messages 1 and 2 are used to negotiate IKE policy, messages 3 and 4 perform an authenticated Diffie-Hellman exchange, and messages 5 and 6 are used to protect the identities of the IKE peers.
- Aggressive mode is faster than main mode because it uses three message exchanges to establish phase 1. However, this means that aggressive mode is not as secure as main mode. In summation, the primary difference between these modes is that aggressive mode uses a 3-way packet exchange, while main mode uses a 6-way packet exchange.
IKE phase 2 is used to protect the data and establish SA for IPsec. This second phase negotiates the protection suite (i.e., ESP and AH), the algorithms that will be used within the protection suite (e.g., DES, 3DES, AES, or SHA-1), the networks or traffic that is being encrypted, which is sometimes referred to as proxy identities or phase 2 identities, and any optional keying material for negotiated protocols.
Unlike IKE phase 1, IKE phase 2 has one mode, which is quick mode. Quick mode uses message exchanges to establish the phase 2 IPsec SA. Phase 2 SA is negotiated for a given proxy or phase 2 identities and a given IPsec protocol, such as ESP. Multiple phase 2 SAs can be established under the same phase 1 SA. Keep in mind, however, that SA is unidirectional.
IPsec can secure data communications using one of two modes, a transport mode and a tunnel mode. Transport mode protects the payload (data) of the original IP datagram. In transport mode, the original IP header is retained while the IPsec header is inserted between the original IP header and the payload. This mode is typically used for host-to-host and end-to-end sessions. Tunnel mode, on the other hand, is used to protect data network-to-network (i.e., between networks). This is the mode used to secure data traversing between two routers in site-to-site VPN implementations in Cisco IOS software. Unlike transport mode, tunnel mode allows IPsec to encapsulate the entire IP packet (i.e., the header as well as the payload) in a new IP packet.
In both transport and tunnel mode, IPsec adds a new header to all the IP packets to provide the required information to secure the data within the original IP datagram. This header may be either an ESP header or an AH, which are described as follows:
- ESP is an IP-based protocol that uses IP port 50 for communication between IPsec peers. ESP is used to provide confidentiality, integrity, and authenticity of the data (i.e., secure data via encryption and authentication). Additionally, ESP provides anti-replay protection services. ESP does not provide any kind of protection for the outer IP header.
- AH is an IP-based protocol that uses IP port 51 for communication between IPsec peers. AH is used to protect the integrity and authenticity of data, and offers anti-replay protection; however, AH does not provide confidentiality protection. In other words, AH does not provide encryption like ESP does. AH does provide protection to the IP header; however, it should be noted that not all fields in the IP header (e.g., TTL) are protected.
NOTE: Additional detailed information on IPsec can be found in the current ROUTE guide, which is available online.
Traditional IPsec VPN
IPsec VPN solutions are very popular and are one of the most commonly implemented VPN solutions. For site-to-site VPN implementations, IPsec VPNs can be implemented simply between two sites, in a full-mesh deployment or even in a partial mesh deployment. In all implementations, the IPsec VPN solution is used to secure communications between locations (e.g., remote and branch offices and the enterprise network) when data is sent across public networks such as the Internet.
In Cisco IOS software, a traditional site-to-site IPsec VPN is implemented between two routers. This allows traffic that resides on the LAN (internal) interface of each router to be secured before it is sent to a remote network across the Internet, for example. In Cisco IOS software, a basic site-to-site IPsec VPN is configured using crypto configuration commands. These crypto commands are used to specify IPsec parameters such as the encryption algorithm to be used, the Diffie-Hellman group, and the shared secret to be used by the peer routers, among other things. In addition to the crypto commands, you must also configure an extended access control list (ACL) specifying the traffic that will (or will not) be encrypted. The traffic matched in this ACL is commonly referred to as the “interesting” traffic that initiates the entire IPsec process.
While you are not expected to configure IPsec in the current TSHOOT certification exam, the example that follows illustrates a basic IPsec configuration on a Cisco IOS router:
| R1(config)#crypto isakmp policy 1 R1(config-isakmp)#encr 3des R1(config-isakmp)#authentication pre-share R1(config-isakmp)#group 2 R1(config-isakmp)#exit R1(config)#crypto isakmp key SECURE address 150.4.4.4 R1(config)#crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac R1(cfg-crypto-trans)#exit R1(config)#crypto map VPN-EXAMPLE 1 ipsec-isakmp % NOTE: This new crypto map will remain disabled until a peer and a valid access list have been configured. R1(config-crypto-map)#description ‘Secure VPN Tunnel To 150.4.4.4 (R4)’ R1(config-crypto-map)#set peer 150.4.4.4 R1(config-crypto-map)#set transform-set ESP-3DES-SHA R1(config-crypto-map)#match address 100 R1(config-crypto-map)#exit R1(config)#access-l 100 permit ip 172.16.1.0 0.0.0.255 172.16.4.0 0.0.0.255 R1(config)#interface Serial0/0 R1(config-if)#description ‘Connected To Internet’ R1(config-if)#crypto map VPN-EXAMPLE R1(config-if)#exit R1(config)#ip route 0.0.0.0 0.0.0.0 serial 0/0 |
The first section, shown below, is used to specify the IKE (ISAKMP) phase 1 parameters for SA. This includes the encryption algorithm, which is Triple DES in this example, as well as the Diffie-Hellman group, which is group 2 in this example:
| R1(config)#crypto isakmp policy 1 R1(config-isakmp)#encr 3des R1(config-isakmp)#authentication pre-share R1(config-isakmp)#group 2 R1(config-isakmp)#exit |
NOTE: Diffie-Hellman, or simply DH, allows two parties to establish a shared secret over some insecure communications channels, such as the Internet. Diffie-Hellman is a public-key distributing system, also known as key-exchange protocol, which uses asymmetric key cryptography. Cisco IOS supports three Diffie-Hellman groups, which are listed in Table 13-2 below:
Table 13-2. Cisco IOS Diffie-Hellman Group Support
| DH Group Number | Description |
|
1 |
This specifies the 768-bit Diffie-Hellman group |
|
2 |
This specifies the 1024-bit Diffie-Hellman group |
|
5 |
This specifies the 1536-bit Diffie-Hellman group |
The next section, which is shown below, is used to define the pre-shared key for the two peers, as well as to specify IPsec encryption and authentication algorithms to be used:
| R1(config)#crypto isakmp key SECURE address 150.4.4.4 R1(config)#crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac |
The final section is used to define IKE phase 2 SA parameters. IKE phase 2 is used to negotiate the protection suite (i.e., ESP and AH), the algorithms that will be used within the protections suite (e.g., DES, 3DES, AES, or SHA-1), the networks or traffic that is being encrypted, which is sometimes referred to as proxy identities or phase 2 identities, and any optional keying material for negotiated protocols.
The ACL referenced in the crypto map configuration defines the interesting traffic. Traffic that matches this ACL will initiate the IPsec process and will then be encrypted. Finally, the crypto map configuration is applied to the Internet-facing Serial0/0 interface. The final section is illustrated below:
| R1(config)#crypto map VPN-EXAMPLE 1 ipsec-isakmp % NOTE: This new crypto map will remain disabled until a peer and a valid access list have been configured. R1(config-crypto-map)#description ‘Secure VPN Tunnel To 150.4.4.4 (R4)’ R1(config-crypto-map)#set peer 150.4.4.4 R1(config-crypto-map)#set transform-set ESP-3DES-SHA R1(config-crypto-map)#match address 100 R1(config-crypto-map)#exit R1(config)#access-l 100 permit ip 172.16.1.0 0.0.0.255 172.16.4.0 0.0.0.255 R1(config)#interface Serial0/0 R1(config-if)#description ‘Connected To Internet’ R1(config-if)#crypto map VPN-EXAMPLE |
NOTE: The remote router (R4) will have a configuration that mirrors the R1 router above.
Cisco Easy VPN
The Cisco Easy VPN (EzVPN) solution can be used for both remote sites and remote or mobile workers. This solution, which is based on the Cisco Unified Client Framework, allows for centralized VPN management, dynamic policy distribution, and configuration simplicity. The EzVPN solution is comprised of two components, the EzVPN Server feature and the EzVPN Remote feature, which are described as follows:
- The EzVPN Server feature allows routers, Cisco Adaptive Security Appliances (ASAs), and the legacy Cisco PIX Appliances to act as headend VPN devices in site-to-site or remote-access VPNs. The feature pushes security policies defined at the central site to the remote device. It can also terminate VPN tunnels initiated by remote workers running the Cisco VPN Client software on computers.
- The EzVPN Remote feature, which is also referred to as the EzVPN Client feature, minimizes the configuration requirements at remote locations by allowing routers, Cisco ASA 5505, Cisco PIX Security Appliances, and the Cisco VPN Client to receive security policies upon a VPN tunnel connection from a Cisco EzVPN Server productivity; it also lowers costs.
Dynamic Multipoint VPN
Dynamic Multipoint VPN (DMVPN) is a Cisco IOS solution that allows network engineers to build and implement scalable IPsec VPNs. DMVPN allows IPsec VPNs to scale better than traditional hub-and-spoke or spoke-to-spoke VPN solutions. With traditional IPsec VPNs, all endpoints must be specified when implementing the crypto configuration. This becomes cumbersome and labor-intensive as the number of sites that need to communicate securely grows. DMVPN allows for such large implementations with relative ease by allowing dynamic hub-to-spoke and spoke-to-spoke (remote branch) IPsec tunnels with minimal configuration.
While both traditional IPsec VPN and DMVPN solutions use standards-based IPsec encryption protocols, DMVPN is different from the traditional IPsec VPN in many ways and offers more advantages for large-scale IPsec VPN implementations. The differences between traditional IPsec VPN and DMVPN implementation include the following:
- Generic Routing Encapsulation Tunneling
- Dynamic Address Resolution
- Dynamic Tunnel Creation
- Dynamic Routing Protocol Support
NOTE: Additional detailed information on DMVPN can be found in the current ROUTE guide, which is available online.
Group Encrypted Transport VPN
The Cisco IOS Group Encrypted Transport VPN (GET VPN) solution allows for VPN service without tunnels by retaining the original IP packet header and encrypting only the payload or data. The GET VPN solution does this by copying the original IP packet header and placing it before the IPsec header. The advantage of retaining the IP header is that policy implementation, such as QoS markings, can be maintained, as this information is not lost or encapsulated. Additional advantages of using the GET VPN solution include, but are not limited to, the following:
- A single SA and key pair is used for the entire any-to-any group communication.
- It allows for any-to-any group communication.
- It uses no overlay (e.g., tunneling).
- It allows the IP header, and the information contained therein (e.g., QoS), to be retained.
- It allows for the use of native routing.