- [Instructor] In our next demonstration we'll be creating a dynamically routed IPsec VPN between two VPCs. This demonstration is similar to the previous one, except that we'll consider BGP to perform route advertisements in both directions. The main difference between this demonstration and the previous demonstration is that we'll configure and use BGP to perform dynamic route advertisements. BGP stands for boarder gateway protocol and is a standardized exterior gateway protocol designed to exchange routing and reachability information among autonomous systems on the internet. The protocol is often referred to as a path vector protocol, but it's sometimes also classed as a distance vector routing protocol. Dynamic routing leverages BGP pairing to exchange routing information between AWS and remote endpoints, known as customer gateways. With dynamic routing you can specify routing priorities, policies, and weights in your BGP advertisements, and influence the network path between your networks and AWS. In this demonstration we'll use cloud formation to provision a fresh environment that contains two new VPCs in the same region. Cloud formation prepares for us the foundational network infrastructure, but does not create the IPsec tunnels. That's for us to do manually. As you can see, our demonstration will consist of a left hand side VPC and a right hand side VPC, each created by their own dedicated cloud formation template. When building our environment we'll utilize a private BGP autonomous system number of 65,000. The left hand side VPC will simulate a corporate on-prem network, meaning that it will host a firewall devise. In this case we'll be using VYOS. VYOS is a Linux-based network operating system that provides software-based network routing, firewall, and VPN functionality. Our VYOS instance will be configured with two elastic network interfaces, external and internal facing. The external facing ENI will have an elastic IP address attached. This elastic IP address will become the customer gateway IP address in our VPN configuration. The right hand VPC will act as our typical AWS cloud site. Within this VPC, we'll provision the VPN componentry. That is the customer gateway, virtual private gateway, and the VPN connection itself. Once the environment is up, we'll manually configure the IPsec tunnels within VYOS, set up dynamic BGP routes within our VPCs, and update respective security groups to allow inbound ICMP requests. Both VPCs will contain an EC2 test instance. The test instances will be used to perform ICMP ping requests to each other, using only their privately-assigned IP addresses. If all goes well we'll be able to see traffic go across our newly-provisioned IPsec VPN tunnels. This time we'll build a dynamically routed VPN that utilizes BGP for our route advertisements. We'll build this environment by launching two cloud formation stacks. Starting from within the AWS console, select an appropriate region into which you will launch both cloud formation stacks. Before we launch either cloud formation stack, ensure that SSH key pair exists within the chosen region, and for which you are in possession of the private key, as this will be referenced by both cloud formation templates. To do this, starting from the AWS console home, click on the EC2 service link. Next, click the key pairs link under network and security. Confirm that an existing SSH key pair exists. And if not, create a new one. You will now launch the first cloud formation stack. Recall that this will build the left hand side corporate on-prem simulating network. Navigate to the cloud formation service. Now click the create new stack button. We then select the upload option, and then click the choose file button. Navigate to and select the cloudacademy.vpc.vyos.vpn.yaml from our recently git cloned repository. Click the next button near the top of the current page. Give the cloud formation stack a name. Here we've chosen to call ours VPC Corp. Select the appropriate SSH key name from the drop down. And then click next. Leave all defaults as is, and click next again. Finally, click the create button. This will launch our left hand side VPC. This will take approximately five to 10 minutes to complete. After this cloud formation stack launch completes successfully, signaled by the create underscore complete status, navigate to the outputs tab, and take note of the outputs. These will be important to us in the coming steps. Next, let's launch the second cloud formation stack. Recall, this will build the right hand side network. Click the create stack button. We then select the upload option, and then click the choose file function. Navigate to and select the cloudacademy.vpc.cloud.vpn.yaml from our recently git cloned repository. Click the next button near the bottom of the current page. Give the cloud formation stack a name. Here we've chosen to call ours VPC Cloud. Select the appropriate SSH key name from the drop down. Ensure that the static route only for VPN option is set to false. Setting this to false will configure a dynamically routed VPN. Set the VPC corp customer gateway IP to be the public IP assigned to the VYOS instance created in the previous cloud formation stack. This is the VYOS instance public IP output value. And then click next. Leave all defaults as is, and click next again. Finally, click the create button. This will launch our right hand side VPC. This will take approximately five to 10 minutes to complete. After this cloud formation stack launch completes successfully, as represented by the create underscore complete status, navigate to the outputs tab and take note of the public IP. This we'll use to SSH onto the EC2 test instance. Now let's head over to the VPC service. Under services, select the VPC service. Next, on the left hand side menu, click the VPN connections link. Select the recently created VPN connection, and then click the download configuration button. In the download configuration popup window, we choose Vyatta for the vendor. The rest of the options are left as is. Click the yes, download button. This downloads the VPN configuration file. We'll now import this into our VYOS instance. Let's now login to the VYOS instance and set up the IPsec tunnels. We do so by SSHing into the instance using its assigned elastic IP. Before we do this, let's first add our SSH key to our SSH authentication agent. We do so as we will later hop from the VYOS instance down to the EC2 test instance in the same VPC. Okay, now let's SSH into our VYOS instance. The first thing we need to do within VYOS is set up and configure the eth1 internal interface. If we run the show interfaces command, you can see that the eth1 interface does not currently have a private IP set. Let's set this up now. We need to first determine the private IP address assigned by AWS to the eth1 interface. We do this by examining it within the EC2 console. Back within the VYOS console, enter into configuration mode by typing conf and hitting enter. Next enter, set interfaces ethernet eth1 address, using the slash 24 private IP address we just collected, and then hit enter. We'll now prepare a VYOS-specific IPsec configuration file. First open within a text editor the AWS Vyatta VPN file we previously downloaded. We now need to substitute the elastic IP address on the local address value for each of the IPsec tunnels with the VYOS eth0 private IP. We now start to paste in the VPN configuration blocks into conf mode within VYOS. Next, we commit and save the changes to make them effective. Let's now take a quick look to see whether we have successfully established an IPsec security association with the AWS virtual private gateway. We do so by exiting the configuration mode and running the following command. Show VPN ike SA. Here you can see that an SA has been successfully established and that both IPsec tunnels are up. We can also take a quick look within the AWS VPC console to check its view of our VPN tunnels. Under VPN connections, click on our VPN connection and select the tunnel details tab. Here the tunnel status of both tunnels is up. And additionally we can see that the AWSN has received a BGP route. Right, next we need to set up some extra dynamic routes in VYOS and in our VPCs. Let's reenter into configuration mode. Within VYOS, we will create a new static route for our left hand side private subnet, n.0.30.0/24, with the next hop set to be the AWS cloud router on 10.0.20.1. Then we update our BGP 65,000 network to dynamically advertise the left hand side private subnet over to the VPC. Again, commit and save the changes. If we go back and look at the VPC VPN side of things, we should now see an extra BGP route coming through. Here you can see that we have two BGP routes per tunnel. Previously, we only had one per tunnel. Let's now jump back into the AWS console. We have a few routing and security group updates we need to make. We'll start by updating our route tables. Head over to the VPC console and click on the route tables menu link. Order the route tables by name. This makes it easier for us to identify them. We need to make a few route table changes. First route table we'll update is the VPC called private subnet route table. This route table hosts a test instance which we will use to initiate IPMP ping tests from. We need to update this route table to route network traffic design`for the other VPC across the VYOS IPsec tunnels. Therefore we need to add the route 192.168.0.0/20 and point it at the VYOS internal eth1 interface. Next we need to update the VPC cloud subnet route table. Rather than add the route in manually, we can instruct VPG to propagate any received BGP advertisements into this route table by clicking on the route propagation tab, clicking the edit button, and then enabling the propagate setting. Finally, click the save button, and then return to the routes tab. You should now see the 10.0.30.0/24 route with the propagated value set to yes. Note here we also have a default route being advertised from the VYOS side. This certainly isn't required. Let's go back and delete this within VYOS and see the changes automatically throw through to this route table. Within configuration mode, enter the following command. Delete protocols BGP 65,000 network, 0.0.0.0/0. Then commit and save. Now go back to the AWS console and refresh the route table. In a minute or two this route will automatically drop out of the route table. This is a good demonstration of the merits of dynamic routing using BGP, highlighting that you only need to manage the routes in one place. The final piece of setup we need to do is update our security groups to allow inbound ICMP ping requests. Specifically we need to allow inbound ICMP on the security groups attached to both EC2 test instances on either side. Additionally, we need to update the security group attached to the VYOS internal eth1 interface to also allow inbound ICMP. Let's go ahead and do each of these. We'll set this source to be anywhere just to speed up the course. Finally everything's in place. We should now be able to SSH into each private EC2 test instance within either VPC, and perform a ping across to the opposing instance. The network traffic generated will flow across the IPsec VPN tunnels and back utilizing the static route that we've manually set up. Let's SSH into the left hand side test instance and ping the right hand side instance. To SSH into the left hand side instance, we bounce there via the VYOS instance. Now that we're in our test instance, let's ping the private IP of the right hand side test instance. Great, it looks like traffic is flowing across our IPsec tunnel successfully. Let's repeat the same test but in the reverse direction. SSH into the right hand side test instance via its elastic IP. Now that we're in our test instance, let's ping the private IP of the left hand side test instance. Great, again our traffic is flowing across the IPsec tunnel successfully.