A VPN connection that allows you to connect two Local Area Networks (LANs) is called a site-to-site VPN. Site to site IPsec VPN means that we can communicate securely between two or more areas by encrypting and authenticating the data transfer across the network. Site-to-site VPNs in most cases use tunnels to encapsulate data packets within normal IP packets for forwarding over IP-based networks, using encryption to ensure privacy and authentication to ensure integrity of data. In a site-to-site VPN configuration, hosts do not have VPN client software; they send and receive normal TCP/IP traffic through a VPN gateway. The VPN gateway is responsible for encapsulating and encrypting outbound traffic, sending it to a peer VPN gateway at the target site. Upon receipt, the peer VPN gateway strips the headers, decrypts the content and relays the packet toward the target host inside its private network.
Once an organization has decided that they need to protect the traffic flows between different sites, advantages and disadvantages that each of IPSec technologies provide must be assessed as there might be multiple ways to accomplish the same goal (e.g. do you have a routing protocol deployed, do you use multicast application, are you devices behind NAT, network topology, Internet or MPLS links, etc.), with some technologies more or less optimal than others.
Site-to-site technologies vary in the features they support, the problems they are designed to solve, and the amount of security they provide to the data being transported.
IPSec (technology)
IPSec is a suite of protocols that interact with one another to provide secure private communications across IP networks and a foundation for all site-to-site technologies. These protocols allow the system to establish and maintain secure tunnels with peer security gateways. IPSec provides confidentiality, data integrity, access control, and data source authentication to IP datagrams. When used alone, IPSec provides a private, resilient network for IP unicast only, where support is not required for IP multicast, dynamic IGP routing protocols, or non-IP protocols.
IPsec standard uses two IP protocols: ESP and AH
ESP (Encapsulating Security Protocol)
- core of the IPSec protocol
- encrypts the data portion only and works in conjunction with other protocols (HMAC) for other protections (data-integrity, anti-reply, MITM, etc.)
- It can also provide an authentication of the protected data.
AH (Authentication Header) protocol
- provides a mechanism for authentication only, i.e. lets the receiver verify that the message is intact
- should not be used alone when there is a requirement for data confidentiality as AH cannot encrypt any portion of packet.
- as initially ESP was not providing authentication but encryption only, both protocols were used together to provide both confidentiality and integrity.
IPSec has the following two modes of forwarding data across a network and each differs in its application as well as in the amount of overhead added:
Tunnel mode
- encapsulates and protects an entire IP packet and new IP header is added which adds additional 20 bytes to each encrypted packet
- it is more deployed and considered more flexible and secure IPSec mode as it hides source and destination IP addresses
Transport mode
- Inserts ESP/AH header between the IP header and the next protocol leaving both source and destination IPs exposed
- Susceptible to traffic analysis
- Packet size is smaller as no new IP header is added
IKE (Internet Key Exchange)
To prevent brute force decryption attacks on VPNs, periodic changing of encryption keys is necessary. IPSec solves the problem using IKE, which uses two other protocols to authenticate peers and generate keys.
ISAKMP is the negotiation protocol that lets two hosts agree on how to build an IPsec security association (SA). It separates negotiation into two phases: Phase 1 and Phase 2. Phase 1 creates the first tunnel, which protects later ISAKMP negotiation messages. IKE Phase One has multiple authentication methods: Pre-Shared Keys (PSK) and Public Key Infrastructure (PKI) using X.509 Digital Certificates. Phase 2 creates the tunnel that protects data. IKE uses ISAKMP to set up the SA for IPSec to use. IKE creates the cryptographic keys used to authenticate peers.
Technology deployment
IPSec point-to-point
IPSec point-to-point also know as Standard/Direct IPSec is a site to site VPN technology that provides encryption between two sites only.
Advantages
- Configurations are fairly straightforward
- Low cost
- Broad vendor support and easy interoperability due to RFC compliance
- Dynamic crypto maps can be configured on the headend routers such that new incoming tunnel connections can be established without having to manually provision each new tunnel on the headend router.
Disadvantages:
- No support for IP multicast or non-IP protocols (multi-protocols)
- Questionable SLA over Internet links
- No support for dynamic IGP routing protocols over the VPN tunnel.
- If the primary tunnel is lost, no secondary tunnel is pre-established, so the new tunnel must be established to the alternate headend before traffic can continue.
- Distribution of IPSec tunnels to headend routers can be non-deterministic, because loss of a connection results in remote routers initiating a tunnel to subsequent headend peers in the peer list (e.g. remotes do not automatically switch back to their primary headend after a failure recovery.)
- It is not possible to implement a QoS service policy per VPN tunnel.
Positioning:
- can be used when there is no requirement for dynamic IGP routing or IP multicast to use across the tunnel.
- As well, when branch offices have very few or a single subnet, such as teleworkers and small office/home office (SOHO) deployments
GRE over IPSec
IPSec can be deployed in conjunction with p2p GRE (an IPsec encrypted point-to-point GRE tunnel) to provide additional functionality. With the addition of p2p GRE to IPSec, dynamic IGP routing protocols and IP multicast traffic can be transported over the VPN tunnel.
Two different designs are common when deploying GREoverIPSec:
Single Tier Headend Architecture
In a Single Tier Headend Architecture, both the p2p GRE and crypto functionally co-exist on the same router CPU. Headend routers service multiple p2p GRE over IPsec tunnels for a prescribed number of branch office locations. In addition to terminating the VPN tunnels at the central site, headend routers can advertise branch routes using IP routing protocols.
Dual Tier Headend Architecture
In a Dual Tier Headend Architecture, the p2p GRE and crypto functionally exist on different routers. There are p2p GRE headend routers, as well as crypto headend routers, that together service multiple p2p GRE over IPsec tunnels for a prescribed number of branch office locations.
Advantages
- IP multicast supported
- non-IP protocols supported
- Simple configuration
- Dynamic IGP routing protocols over the VPN tunnel are supported.
- QoS service policies can be configured per p2p GRE over IPsec tunnel
- Distribution of IPsec tunnels to headend routers is deterministic, with routing metrics and convergence choosing the best path.
- All primary and secondary/backup p2p GRE over IPsec tunnels are pre-established, anda new tunnel does not have to be established in the event of a failure scenario
Disadvantages
- Configuration of each p2p GRE tunnel interface is static and can lead to lengthy headend configurations.
- Provisioning of new branch offices typically requires a configuration change/addition to the headend router(s).
- Limited scalability
- Per-tunnel QoS service policies are limited in scalability as processes depending on the platform can be CPU intensive (executed in software)
- Multicast replication issues because multicast replication must be performed before tunnel encapsulation and encryption at the IPsec CE (customer edge) router closest to the multicast source.
Positioning:
- commonly used when there are requirements for routing and/or multicast over encrypted WAN network that connects small number of remote sites and requires fast provisioning
Cisco DMVPN
DMVPN (Dynamic Multipoint VPN) is a point-to-multipoint Layer 3 overlay VPN enabling logical hub and spoke topology supporting direct spoke-to-spoke communications depending on DMVPN design (Phase 1, Phase 2 and Phase 3) selection.
It allows users to better scale large by combining the following technologies:
mGRE (multipoint GRE): mGRE allows a single GRE interface to support multiple IPSec tunnels and simplifies the size and complexity of the configuration.
Next Hop Resolution Protocol (NHRP): A client and server protocol where the hub is the server and the spokes are the clients. The hub maintains an NHRP database of the public interface addresses of each spoke. Each spoke registers its real address when it boots and queries the NHRP database for real addresses of the destination spokes to build direct tunnels.
IPSec tunnel protection: DMVPN by default doesn’t provide encryption. IPSec is optional and used primarily over public networks.DMVPN support IPSec encryption configured using Tunnel Protection. As well, DMVPN in public networks can use GETVPN which allows grouping of tunnels to single Security Association (SA) and speeds up establishment of the tunnels while utilizing less resources than standard IPSec at the same time.
Overlay Routing: Tunnel routing is required for utilizing DMVPN efficiently. Tunnel routing is agnostic of underlay routing and separate routing protocol with its own policies is configured and used.
DMVPN phases
DMVPN phase-selected influence spoke-to-spoke traffic patterns, supported routing designs and scalability.
Phase 1: DMVPN phase 1 only provides hub-and-spoke tunnel deployment. This means GRE tunnels are only built between the hub and the spokes. Traffic destined to networks behind spokes is forced to first traverse the hub. The hub is used for control plane of the network and is also in the data plane path. Some of disadvantages of this phase are the following:
- encapsulation/encapsulation overhead for the spoke-to-spoke traffic
- spoke-to-spoke traffic has sub-optimal path by detouring to the hub and then reaching the remote spoke
Phase 2: Phase 2 improved on Phase 1 by allowing directly established spoke-to-spoke tunnels. Spoke-to-spoke tunnels are on demand based on spoke traffic triggering the tunnel. The hub is used for control plane only. Spoke-to-spoke tunnel on demand in Phase 2 come with these restrictions:
- Both, Hub and spokes must use multipoint GRE tunnels
- The spokes must receive specific routes for all remote spoke subnets (summarization or default route advertisem*nt not possible)
- Full routing tables must be maintained on the spokes
- The next hop of the entry in the routing table must list the remote spoke as the next hop
Phase 3: Phase 3 overcomes this restriction using NHRP traffic indication messages from the hub to signal to the spokes that a better path exists to reach the target network. “NHRP redirect” and “shortcuts” take care of traffic flows. Using these features, the overall design is lot more scalable as the Hub can send a default route only to each of the spokes. In case of spoke-to-spoke communication, the redirect command tells the hub to send the NHRP traffic indication message while the shortcut command tells the spokes to accept the redirect and install the shortcut route.
DMVPN IPv6
In DMVPN for IPv6, the public network (the Internet) is a pure IPv4 network, and the private network (the intranet) is IPv6 capable. The intranets could be a mix of IPv4 or IPv6 clouds connected to each other using DMVPN technologies, with the underlying carrier being a traditional IPv4 network.
Per-Tunnel QoS for DMVPN
The Per-Tunnel QoS for DMVPN feature lets you apply a quality of service (QoS) policy on a Dynamic Multipoint VPN (DMVPN) hub on a per-tunnel instance (per-spoke basis). The QoS policy on a DMVPN hub on a per-tunnel instance lets you shape tunnel traffic to individual spokes (a parent policy) and differentiate individual data flows going through the tunnel for policing (a child policy). The QoS policy that the hub uses for a specific spoke is selected according to the specific Next Hop Resolution Protocol (NHRP) group into which that spoke is configured.NHRP group-to-QoS policy mappings are configured on the hub DMVPN GRE tunnel interface.
The Per-Tunnel QoS for DMVPN feature provides the following benefits:
- The QoS policy is attached to the DMVPN hub, and the criteria for matching the tunnel traffic are set up automatically as each spoke registers with the hub (which means that extensive manual configuration is not needed).
- Traffic can be regulated from the hub to spokes on a per-spoke basis.
- The hub cannot send excessive traffic to (and overrun) a small spoke.
- The amount of outbound hub bandwidth that a “greedy” spoke can consume can be limited; therefore, the traffic cannot monopolize a hub’s resources and starve other spokes.
Different designs are possible with DMVPN:
Multiple DMPVNs
- Best for Hub and Spoke deployment
- Routing metric can be adjusted for load balancing over multiple links or multiple ISPs
Single DMVPN
- Best for spoke-to-spoke as spoke-spoke communication is possible only within DMPVN
- Hierarchical DMVPN design is possible for networks with huge number of remote sites.
Advantages:
- Scalability to thousands of remote sites using server load balancing
- High availability with routing-based failover and dual hub designs
- Hub Router Configuration Reduction due to single mGRE interface and a single IPSec profile
- Zero-touch deployment as the configuration on the hub remains constant even if the spoke routers are added to the network
- Dynamic Creation for Spoke-to-Spoke Tunnels
- Supports IP unicast, IP multicast and dynamic routing protocols
- Spokes can be behind dynamic while Hub can be behind static NAT
- Can be used with or without IPSec encryption
- VRF awareness – allows segregation of customer traffic
- 2547oDMVPN – MPLS switching can be encrypted over DMVPN tunnels
- QOS – per tunnel QOS
- IWAN support
Disadvantages:
- Requires overlaying a secondary routing infrastructure through the tunnels, which results in suboptimal routing while the dynamic tunnels are built and adds complexity to the overall design
- Overlay routing topology reduces the inherent scalability of the underlying IP VPN network topology
- Vendor proprietary technology
- No support for non-IP protocols
- Multicast replication on hub router only
- Two independent convergence processes (routing + NHRP)
Positioning:
- Large number of remote sites with spoke to spoke communication requirement
- VRF tunneling segregation
- Encryption requirement
- Connecting ISP edge MPLS devices over IP network
GETVPN
To provide a true full mesh or even dense partial mesh of connectivity, tunnel-based solutions require the provisioning of a complex connectivity mesh. The GETVPN solution is based on technology which helps utilize the power of underlying MPLS/shared IP network.
Cisco‘s Group Encrypted Transport VPN (GETVPN) introduces the concept of a trusted group to eliminate point-to-pointtunnelsandtheirassociatedoverlayrouting.All group members (GMs) share a common security association (SA), also known as a group SA. This enables GMs to decrypt traffic that was encrypted by any other GM. In GETVPN networks, there is no need to negotiate point-to-point IPSec tunnels between the members of a group, because GETVPN is tunnel-less.
Following are the key components use in GETVPN:
GDOI
The IETF standard Group Domain of Interpretation is an integral part of GETVPN. The GDOI group key management protocol is used to provide a set of cryptographic keys and policies to a group of devices. GDOI is used to distribute common IPsec keys to a group of enterprise VPN gateways that must communicate securely. The GDOI protocol is protected by Internet Key Exchange (IKE) SA.
Key Servers
A key server (KS) is a device responsible for creating and maintaining the GETVPN control plane.All encryption policies, such as interesting traffic, encryption protocols, security association, rekey timers, etc., are centrally defined on the KS and are pushed down to all GMs at registration time.
The KS is the most important entity in the GETVPN network because the KS maintains the control plane. Because redundancy is an important consideration for KSs, GET-VPN supports multiple KSs, called cooperative (COOP) KSs, to ensure seamless fault recovery if a KS fails or becomes unreachable
Group members
A GM is a device responsible for actual encryption and decryption i.e.a device responsible to handle GETVPN data plane.A GM is only configured with IKE parameters and KS/Group information.
Group SA
Unlike traditional IPsec encryption solutions, GETVPN uses the concept of group SA.All members in the GETVPN group can communicate with each other using a common encryption policy and a shared SA. With a common encryption policy and a shared SA, there is no need to negotiate IPsec between GMs; this reduces the resource load on the IPsec routers.
Rekey process
In the unicast rekey process, a KS generates a rekey message and sends multiple copies of the message, one copy to each GM and GM replies with an ACK.
In the multicast rekey process, a KS generates a rekey message and sends one copy of the message to a multicast group address that is predefined in the configuration. In multicast rekey GM doesn’t reply with an ACK as KS doesn’t have a list of active GMs. With multicast rekey, the same process is happening for 1 or 1000s of GMs which improves stability as number of sites grows. The drawback is that multicast must be enables in the core network.
Header preservation
In the case of GETVPN, IPsec protected data packets encapsulate the original source and destination packet addresses of the host in the outer IP header to ―preserve the IP address. The biggest advantage of tunnel header preservation is the ability to route encrypted packets using the underlying network routing infrastructure. Because of tunnel header preservation, GETVPN solution is very well suited for MPLS, Layer-2 (L2), or an IP infrastructure with end to end IP connectivity.
Advantages:
- Instantaneous large-scale any-to-any IP connectivity using a group IPsec security paradigm
- Takes advantage of underlying IP VPN routing infrastructure (optimal routing) and does not require an overlay routing control plane
- Seamlessly integrates with multicast infrastructures without the multicast replication issues typically seen in traditional tunnel-based IPsec solutions.
- Seamless integration of QoS and Traffic engineering
- Preserves the IP source and destination addresses during the IPsec encryption and encapsulation process.
- L2/L3 agnostic as long as NAT is not used
Disadvantages:
- Private networks deployment only due to header preservation
- Proprietary protocol
- No NAT supports
- No support for non-IP protocols
Positioning:
- deployments over private WAN (MPLS/VPN or VPLS) networks that require encryption, allowing the utilization of underlying MPLS/shared IP networks using header preservation.
- requirement to have fully optimized secure Multicast or deployment of voice/video or any other application that require any-to-any encryption.
