- [Instructor] When building on Amazon's Virtual Private Cloud, you have the capability to extend your local corporate on-prem network into the AWS Cloud securely. An AWS VPC can be set up with a VPN concentrator known as a virtual private gateway. The VPG will leverage IPsec to establish a pair of redundant IPsec tunnels. Let's now take some time here and detail some of the important features of IPsec. IPsec is a framework of protocols used to ensure data authentication, integrity, and confidentiality of data as it moves across IP networks. IPsec protects data against potential security exposures by protecting it while in transit through the use of various cryptographic services. IPsec is an open standard framework based on standards developed and administered by the IPsec working group within the Internet Engineering Task Force. IPsec is designed to provide security services that operate at the IP layer of the TCP/IP stack, or equivalently, the network layer in the OSI model. Since IPsec operates below the transport layer, it's effectively transparent to applications, meaning no changes are required in the application layers for them to be able to leverage the security functions of IPsec if enabled. From a data in transit perspective, IPsec provides three important and primary security services. Confidentiality: when data is in transit between two communication network endpoints, IPsec can be used to encrypt the data, ensuring that if anyone were to intercept the traffic in between, then they would not be able to view nor understand its contents. Integrity: when data is in transit between two communication network endpoints, IPsec can be used to ensure the integrity of the data, ensuring that if anyone were to attempt to alter the content of the payload, then this will be flagged at the receiving end. Authentication: when data is in transit between two communication network endpoints, IPsec can be used to mutually assure that both ends are indeed who they say they are before the data is sent, guaranteeing authenticity of both sender and receiver. Additionally, IPsec can be used to prevent replay attacks of data and non-repudiation of data. With non-repudiation of data, the sender of the data cannot, in any future point in time, refute sending that piece of data. Next, let's focus on the intention and use cases of IPsec, who benefits from using IPsec, and how they benefit from using IPsec. Use cases of IPsec technology are widely varied, from corporate online financial institutions to cloud platform providers such as AWS, Azure, and GCP. Basically, any data flow requiring security performed over an open network such as the internet is a good candidate for IPsec. IPsec can be used to provide site-to-site or host-to-host protected and secured network pathways over open networks such as the internet. As we'll see later in this course when we demonstrate setting up IPsec VPN tunnels, AWS VPCs can be implemented in a site-to-site configuration with on-prem corporate networks using IPsec. In doing so, this ensures any and all information in transit between a corporate network and an AWS VPC to be authenticated and protected from both data theft and data corruption. In the corporate world, IPsec is typically implemented through the deployment and installation of trusted firewall appliances supplied from specializing vendors such as Cisco, Juniper, Check Point, to name but a few. We'll now briefly touch on how AWS performs IPsec tunnels and integrates them with a VPC. Later on in this course, we'll dive deeper into the functions of each individual components, but for now, let's just list the required components to be deployed within a VPC. To integrate virtual private cloud with an on-prem corporate network in a private and secured manner, you must provision and deploy a virtual private gateway, customer gateway, and VPN connection. In this diagram, the AWS VPN connection is simplified as a single, logical connection between the gateways. In actuality, a pair of redundant IPsec VPN tunnels are created between the endpoints, as we'll be showing in the next slide. As previously mentioned, each AWS VPN connection created results in a pair of IPsec tunnels. This is done to provide redundancy. When one tunnel becomes unavailable; for example, down for maintenance; network traffic is automatically routed to the available tunnel for that specific VPN connection. AWS allows you to configure either a one-to-one arrangement with a single VPN connection between a virtual private gateway and customer gateway, or, as seen in this slide, a one-to-many arrangement with multiple VPN connections between a single virtual private gateway and many customer private gateways. The one-to-many arrangement can be used to facilitate securely connection multiple independent department networks back to the same VPC. Let's move our focus back to IPsec and review the individual components that make up the framework. IPsec uses two distinct protocols, Authentication Header and Encapsulating Security Payload. Together, the pair of protocols are often referred to as the IPsec Core Protocols. The Authentication Header, or AH in shortened form, provides a mechanism for authentication only. It allows the recipient of a data grab to verify that the supposed originator of a message is, in fact, the one that sent it. The recipient can also verify that the data within the datagram has not been changed by any adversary en route. Additionally, it can provide protection against replay attacks, where a message is captured by an unauthorized user and resent. By itself, AH does not ensure privacy of data within the datagram while in transit. Encapsulating Security Payload, or ESP in shortened form, provides both data encryption and authentication. Encryption translates a readable message into an unreadable format to hide the message content, ensuring privacy and confidentiality. Additional to the core protocols, IPsec provides a standard set of encryption and hashing algorithms, security policies, and security associations, and finally, key management functions. We'll dive a little deeper into the composition of the IP Protocol Suite in the next slide. As you now see, the IPsec protocol suite is decomposed and classified into the following group security functions. Confidentiality, which gives us privacy, is performed through the use of encryption algorithms such as DES, 3DES, and AES. Integrity is performed using the hashing algorithms, MD5 and SHA. Authentication is performed by using pre-shared keys and RSA public key cryptosystem. Key Exchange. It's performed by using Diffie-Hellman key exchange algorithms. Before establishing a secure IPsec VPN tunnel between two communication endpoints, formalities are required to ensure both endpoints are identifiable and trusted. This process is performed and orchestrated by the Internet Key Exchange protocol, and it's done in two distinct phases. IKE phase one: the two endpoints authenticate one another and negotiate keying material. This results in an encrypted tunnel used by phase two for negotiating security associations. Phase one sets up mutual authentication with the peers, negotiates cryptographic parameters, and creates session keys. IKE phase two: the two endpoints use the secure tunnel created in phase one to negotiate SAs. The SAs are what are used to encrypt the actual user data that's passed between the two endpoints. Phase two negotiates an IPsec tunnel by creating keying material for the IPsec tunnel to use, either by using the IKE phase one keys as a base or by performing a new key exchange. A key consideration when deciding to work with IPsec is to determine, choose, and configure the correct IPsec transport mode. IPsec supports two modes, transport and tunnel. The choice of transport or tunnel mode depends on the network topology, and it's dependent on the logical connectivity to be established between communication endpoints. In transport mode, IPsec encrypts only the payload and ESP trailer, so the IP header of the original packet is not encrypted. Transport mode is often implemented for client-to-site VPN scenarios. Transport mode encapsulation retains the original IP header; therefore, when transport mode is used, the IP header reflects the original source and destination of the packet. Transport is most often used in a host-to-host scenario where the data endpoints and the security endpoints are the same. A transport mode encapsulated datagram is rooted or transported in the same manner as the original packet. In tunnel mode, IPsec protects the internal routing information by encrypting the IP header of the original packet. The original packet is encapsulated by another set of IP headers. Tunnel mode is implemented often in site-to-site VPN scenarios, as is the case with AWS VPCs. Tunnel mode encapsulation builds a new IP header containing the source and destination address of the security endpoints. When tunnel mode is used, the out IP header reflects the source and destination of the security endpoints, which might or might not be the same as the original source and destination IP address of the data connection. Note the AWS virtual private gateway VPN concentrator only supports tunnel mode. The manner in which the original in packet is modified depends on the encapsulation mode used. There are two encapsulation modes used by AH and ESP, transport and tunnel. Again, for clarity, in transport mode, encapsulation retains the original IP header; therefore, when transport mode is used, the IP header reflects the original source and destination of the packet. In tunnel mode, IPsec protects the internal routing information by encrypting the IP header of the original packet. The original packet is encapsulated by another set of IP headers. Let's now elaborate our understanding of how we would establish IPsec connectivity to our AWS VPC. As earlier described, to integrate a virtual private cloud with on-prem corporate network in a private and secured manner, we need to provision and deploy the following components. One, virtual private gateway, or VPG in shortened form, represents the VPN concentrator on the Amazon side of the VPN connection. Two, customer gateway, or CGW in shortened form, represents the physical device or software application on the customer's side of the VPN connection. The customer gateway is configured with externally-facing public IP address configured on the device. Three, VPN connection represents an actual connection between a customer gateway and a virtual private gateway. A VPN connection, when created, requires reference to a single customer gateway and a single virtual private gateway. In addition to deploying and configuring the previously-discussed AWS components, we need to ensure that our customer gateway device or appliance can negotiate the following IPsec protocol requirements for both statically and dynamically rooted VPNs: establish IKE security association using pre-shared keys; establish IPsec security associations in tunnel mode; utilize the AES 128-bit or 256-bit encryption function; utilize the SHA-1 or SHA-2 hashing function; utilize Diffie-Hellman Perfect Forward Secrecy in Group 2 mode, or one of the additional DH groups AWS supports; and perform packet fragmentation prior to encryption. Additionally, dynamically-routed IPsec VPNs have the following extra requirements: must be able to establish BGP peerings; must be able to bind tunnels to logical interfaces and act as a route-based VPN; and must be able to perform IPsec Dead Peer Detection. Pricing for AWS IPsec VPNs is very simple. It costs five cents per VPN connection-hour. You're charged for each VPN connection-hour that your VPN is provisioned and available. Please note, a charge still applies even if your VPN and IPsec tunnels haven't yet completed the internet key exchange phases successfully and are, as such, still in a down status. Additionally, standard AWS data transfer charges for all data transferred by the VPN connection apply. It's worth noting a few default soft limits AWS imposes on us when provisioning and running an IPsec VPN: 50 customer gateways per region; five virtual private gateways per region; 50 VPN connections per region; 10 VPN connections per VPC. Each limit mentioned here is a soft limit and can be increased upon request. One other notable limit to mention is that you may only have one virtual private gateway attached to a VPC at any given time. Let's now walk through the high-level provisioning sequence required to stand up a VPN IPsec connection. The following sequence need to be performed: one, the VPC owner creates a virtual private gateway and attaches it to their VPC. Two, the VPC owner creates a customer gateway. This represents the corporate network peripheral firewall device. The key attribute set on the customer gateway is the externally-facing public IP address of the peripheral firewall device. Three, the VPC owner creates a VPN connection referencing both the virtual private gateway and customer gateway components. Four, the VPC owner downloads a matching vendor-specific VPN config file and provides it to the administrator of the corporate hardware device for importing. Five, customer gateway administrator imports and configures VPN settings on the firewall device. Six, the customer gateway device initiatives connectivity to the virtual private gateway. In terms of timing, the first four steps can be completed in a matter of minutes. Steps five and six either also happen very quickly or can sometimes take longer due to troubleshooting and/or other dependencies, such as device maintenance windows, et cetera. Having completed this sequence, if all goes well, a pair of redundant IPsec tunnels will be negotiated. On the AWS side, the status of the tunnels can be examined within the VPC console, as will be demonstrated later in this course. Likewise, on the customer gateway side, an administrator will have some form of ability to run diagnostic checks on the firewall device to determine their status of the tunnels. One key point to reiterate about this sequence is the following: a customer gateway device always initiates connectivity to the virtual private gateway. Let's have a quick discussion on when it makes sense to use IPsec VPNs. For obvious reasons, any time we have a need to secure data in transit over private networks, IPsec VPNs are a great solution. Mostly, IPsec VPN connections can be configured and operational within a matter of minutes and are a good choice if you have an immediate need. IPsec VPN tunnels work well with low to modest bandwidth requirements and can tolerate the inherent variability in internet-based connectivity. Inversely, the following reasons may preclude you from using IPsec VPNs: AWS currently does not support IPv6 traffic through a VPN connection. AWS only supports IPsec connections in tunnel mode. If you're moving massive amounts of data, it may make more commercial sense to provision a direct connect connection, which costs more per month for the service itself but has a cheaper data transfer rate, meaning there is a break even point between the two options that you should appreciate. Finally, the complexity built within the IPsec framework and all of its settings and configuration may be prohibitive and counterproductive to those unfamiliar with it.