Create Site-to-Site VPNs

0:00Welcome to the content on implementing a site-to-site VPN in AWS. The concept is relatively straightforward. The implementation is a bit more complex. We want our on-premises or other Cloud resources to reach our resources privately and securely that are hosted in AWS. This is the true mark of a hybrid environment, and it's critical to understand how to implement this in many environments today. In this set of demos, we're actually going to build a site-to-site VPN between AWS and Azure.

0:36But I want to stress this right now. The exam really only wants you to know the AWS side of things, because it's hard to assume you know how to implement a site-to-site VPN on every appliance that exists in the world today. The other end of a site-to-site tunnel could be connected to Hasysco Appliance, Maraki, Juniper, Barracuda, Palo Alto, Checkpoint, and so on, and so on, and so on. So really, you need to focus in on the AWS side of things for the exam, but of course, in order to successfully implement one, you have to implement it on both sides.

1:08So to make things nice and easy, I'm going to implement it between AWS and Azure.

0:00Now, wait a minute, this is an AWS course. Why would I have the Azure portal up on the screen? Well, I've also got AWS logged in here. That's true. I've got both because here's the thing, a really important part of today's entire technology ecosystem hinges on hybrid environments. Now, when we talk about hybrid environments, what are we really talking about? Let's give myself a little more room to doodle here for a second. When we talk about hybrid environments, we're really talking about something plus a cloud environment.

0:38I know this kind of goes down a rabbit hole just a little bit, but one of the real reasons we like having cloud environments is for the elasticity of it all. That's why you see a lot of the ease scattered throughout AWS, EBS, EC2, yada yada. That all stands for elasticity. The ability here is that we can quickly adapt to changes in demand. We can scale up, we can scale down, we can scale out, we can scale in and deploy resources on demand relatively quickly.

1:11It's a pay per month, kind of pay as you go, style service where you're focused in on operational expenditures or topics. Now, this being a advanced cloud course, the assumption is that you kind of understood these concepts already, but we're getting to why I'm talking about this in just a second. The other piece of this puzzle is very frequently things like an on-prem environment or a co-location slash data center environment.

1:45But here's the other thing that you probably didn't consider. This could also be another cloud. Hybrid environments aren't just physical and cloud, it could be cloud to cloud environments. You could have hybrid cloud environments. For very large enterprises, some of your applications might be built in AWS and some of your applications might be built in Azure. Ah, now that's why I had Azure up on the screen. And ultimately, we need all of these resources talking to each other.

2:19And yeah, that's what the internet was made for is to basically transfer traffic from point A to point B geographically. But the internet isn't very secure, isn't. Again, advanced networking course, we already know this. So knowing that I can't have confidential data that was generated in cloud one, transferred to cloud two over the internet, what's a network engineer to do? Well, this is what VPN tunnels solve.

2:49This is what the problem is and what they solve. This is a virtual private network. And the idea, the very fundamental idea with a VPN is that we have an appliance running on one end here that is going to attempt to establish a secure connected encrypted tunnel to an appliance that exists on the other side. These are going to be connected via the public IPs that are part of the internet.

3:21That is how they reach each other is over the public internet. But they immediately do start establishing encrypted tunnels to each other. So when they want to transfer traffic from cloud A to cloud B or data center to cloud B or on-prem HQ to cloud B or vice versa, they're going to encrypt the data first, send it to the given public IP who is configured to receive and decrypt this data before transferring it inbound to the target location.

3:55Now, there are a bunch of different kinds of VPNs. The kind of VPN we are focused in on right here is known as a site to site VPN. Ultimately, the goal is that our private addresses right here like 192.168.whatever.whatever can communicate directly to our private addresses like 172.16.whatever.whatever on the cloud side of things. So a host from 192.168 generates a packet destined for 172.16.

4:32And without doing NAT or any type of stuff like that, we actually encrypt and encapsulate the payload, transfer it to the public IP of this appliance who then decrypts it and then is able to make a forwarding decision moving it on inbound that way. Now, site to site VPNs work really well because this stuff isn't changing. We're not mobile here. This building, this data center, this on-premises location is fixed and the subnets inside of it are for the most part fixed.

5:04Same thing with the cloud. We have a VPC up and running and it's going to have the subnet inside of it which is relatively fixed. So being that these resources aren't constantly on the move, we can deploy a tunnel to always be up and route traffic back and forth to each other. This stands in contrast to something like a remote access VPN where we have our end user who has a laptop and they're out there in the field. They can be coming from anywhere.

5:35In this case, this is really an on-demand VPN which is an entirely separate configuration and an entirely separate topic outside of what we're talking about today. Our core AWS exam objective in domain two is to establish site to site connectivity. Now, the last thing I'm going to say before we move on to the nitty gritty and the how to is on the AWS side of things. That's really what we're focused in on in this set of videos. Don't dwell too much on the Azure side of things.

6:08The thing is is when you establish a site to site VPN, you have to have both ends of it to bring it up. And your results are going to vary depending on what firewall or appliances you're working with. In your on-prem environment, you could be working with Muraki, Cisco, which is, you know, owns Muraki, Juniper. You could work with Barracuda, you could work with Palo Alto, the list goes on and on and on and the setup of a site to site VPN is different from one appliance to the next.

6:43So AWS doesn't really care if you know how to set up these appliances or if you know how to set up an Azure Cloud VPN. That's not going to be on the exam. What's going to be on the exam is how do you do it on the AWS half of things? But you're not really going to know if you did it right unless you can figure the other half of the tunnel, right? So that's why I'm going to use Azure because it is, well, elastic. I can just deploy a virtual network gateway, which is the resource that you need to establish the other half of the site to site tunnel.

7:19So now you have an idea of where I'm going with this. In the next video, we're going to start talking about the nigh gritty details. Like what does it take to actually bring a site to site tunnel up? I hope this has been informative for you and I'd like to thank you for viewing.

0:00So now we're going to talk about the guts of IPsec. And the interesting thing about this is when you do Azure to AWS, you actually don't have to worry about this. You can really just accept the defaults and it just works. But of course, if you're working with on-premises appliances like Cisco, Juniper, Yada, Yada, Yada, yeah, you're going to have to absolutely know these and understand the two phase negotiation. You see, when we've been talking about site-to-site tunnels, the trick is it's not just a tunnel, it's actually two tunnels.

0:36Let's first talk about this because this is a really important thing to understand. You're going to see this even in the AWS configuration as well as the Azure configuration. Let's say this greenish-blueish color here is going to be my Azure appliance. And let's pretend it has a public IP of 1.1.1.1. I know that's CloudFlares DNS server. We're just keeping it simple, hypothetical, bear with me. I promise, this all makes sense. Over here, we're going to have AWS's appliance.

1:10This is actually called a virtual gateway. In fact, both of these have really similar names with virtual gateway and virtual network gateway. So I'm just going to put VRT GW right here. It attaches to a VPC and it is able to basically make routing decisions while also handling the encryption of the data before it goes over the tunnel. We'll set this public IP to 2222. When we configure the site-to-site VPN, we tell it you are going to talk to 1.1.1.1 and you are going to talk directly to 2222.

1:50IPsec is a protocol just like everything else in networking, so it's very rigid. It's very by the book. You don't get a whole lot of wiggle room to do here. So what's going to happen is the first thing they're going to do is they're going to establish what I'm going to call the control tunnel. Basically, we're going to establish a tunnel where just these two appliances talk back and forth to each other. We're basically saying, hey, I've got some data over here that I want to send to you.

2:23And you're going to say, hey, you've got some data that you want to send back to me. So let's use this tunnel right here, this encrypted tunnel, to determine, to basically negotiate how we're going to encrypt this data. So this is known as the phase 1 tunnel, also sometimes known as the Ike tunnel as an internet key exchange. And for a phase 1 tunnel to come up for them to even begin negotiating how to encrypt the data, there's a lot of parameters that have to be matched.

3:00We're going to talk about those parameters in just a second. Once we've established the phase 1 tunnel, then we can begin negotiating how the phase 2 tunnel, also frequently known as the IPsec tunnel, comes to life. So we use the phase 1 tunnel to negotiate how we're going to encrypt the data. Then once we've agreed how we're going to encrypt the data, we then create the tunnel inside the tunnel.

3:32So when data comes along from a server or something and it needs to be sent over here, it's going to be routed to the appliance. The appliance sees, oh, it's destined over here. Therefore, it must go over this tunnel. Therefore, it must be encrypted in this exact way. So that when the data transmits over this tunnel, this endpoint, because it knows how it was encrypted, because that's what we just negotiated, decrypts the data and then forwards it on to the endpoint like so.

4:06And return traffic has treated the exact same way. IPsec tunnels are two phase tunnels. And now you've seen how an IPsec tunnel comes to life. So now that we understand the phases, in the next video, we're going to talk about what actually gets negotiated for phase 1 and phase 2. It's one of my favorite things to talk about. And truth be told, I learned this from Keith Barker himself. I used to be a CBT Nuggets learner for a very long time before I ever worked for CBT Nuggets.

4:38So I want to stress this right now that Keith Barker taught it this way before I go into this. And it's just the best way that I'll ever remember how an IPsec tunnel comes to life. And I hope it drills its own for you. But for now, I hope this has been informative for you and I'd like to thank you for viewing.

0:00So that negotiation thing is a pretty big deal. What gets negotiated? What has to happen in order to bring a tunnel to life? I remember this because of what Keith said. Haggle. Negotiations can be a haggle, and in this case, they're quite literally a hagg le. Phase one and phase two both require every parameter of haggle to exactly match in order for it to come to life. So what is haggle?

0:30The first one is the hashing algorithm. Hashing is more or less an authenticity check. Has the data been changed before it's transmitted? If I have data that I'm trying to send from point A to point B, what I might do is I might have my appliance generate a SHA-256 hash before it gets transmitted. Then it might come up being something like, you know, A, B, C, one, two, three.

1:03The data gets transmitted over the wire where the other appliance picks it up and it receives the data. And before it does anything else, it'll also generate a hash. Now it could generate if it's using it now, obviously it needs to use SHA-256 so that it hopefully generates the same exact hash assuming the data hasn't been changed while in flight. If we were using, say, SHA-1, which is not safe at all, it's been proven to be broken at this point, you know, it obviously wouldn't come up with the same hash.

1:40So that's why we have to have the hashing algorithms check so that way or matching so that way we can ensure that the data hasn't been tampered with on both sides as it's in flight. So what comes next? We'll move a little bit down the spectrum of colors here and the A is for authentication. Do I actually trust the appliance on the other end? How do I know that it's really them at the end of the day? We can use traditional authentication methods.

2:1399% of the time, I'm going to tell you, people use a pre-shared key like, hey, do you know what key you're supposed to be using right now, send the key back to me and I 'll double check it. Now you can also use certificates as long as, of course, everybody trusts the same CA that generated the certificates, but that's what the authentication method does . Pre-shared keys are going to be really important. And I'm going to tell you right now, we're going to get the pre-shared key from the AWS side of things.

2:44AWS is going to generate the pre-shared key and we're going to drop it in the Azure side of things when we're done. Now this part is interesting. This is the G here. I didn't go in the, I know I didn't go in the order of the colors. I'm mixing it up a little bit. The G here is actually short for the Diffie Hellman group, very frequently known as just the group. The Diffie Hellman group is an algorithm for generating shared secrets, for generating secrets.

3:24When we actually go to encrypt the data itself, we can use a seed basically to help generate that data. The Diffie Hellman group is going to give us an algorithm where we can generate and agree upon a seed to use an encryption. If you're not seen Diffie Hellman groups, you usually see them written something like DH1, DH2, they get up to like weird numbers, they skip a lot and go to something like DH12 or 13 or 14.

3:57You'll see when you can start digging into it that the Diffie Hellman groups are kind of like, they got just, you know, kind of scattered all over the place. Now what comes next in our haggle? I'm going to switch down to pink for this one, lifetime. How long in seconds should our tunnels be up for? This can be different for phase one and phase two. The idea is that we're rotating or generating new seeds for encryption every so often. You can even automate changing or rotation of pre-shared keys on the same schedule if that's what you want to do.

4:32You would just have to reconfigure the appliances to use the new pre-shared keys on that same schedule. Lots of times you see this as 28,800 seconds. That's kind of just been the de facto standard. Sometimes you see it as 3,600 seconds. And of course, the very last one, you know, the moment you've been waiting for, the thing that we all came here for in encryption itself. What is the encryption algorithm that we're going to be using to transmit the data?

5:04Lots of times you see this as things like AES-256, but we're even seeing bigger elliptical curve algorithms, encryption algorithms coming to market these days. So be on the lookout for whatever appliance you're using. You might use something even more secure and more robust than AES-256. Now phase one and phase two can both have different configurations for each of these. You can use one hashing algorithm for phase one and a different one for phase two.

5:37You can use a different PSK. Well, actually the pre-shared keys get a pre-shared keys going to stay the same . I take that that part back. But you can use different Diffie-Hellman groups. You can have different lifetimes. And you can have different encryption algorithms between phase one and phase two. But it even gets cooler than that. When we configure our appliances, we actually can create proposal suites, basically saying, "Here's one of the haggle configurations I'm willing to accept."

6:11And if you don't have that one configured, let's fall back to the next one. And if you don't have that one configured, let's fall back to the next one. And they literally propose back and forth during phase one and phase two. They just negotiate back and forth until they find a matching proposal suite. Understand that the tunnel is not going to come up unless both sides have been configured to communicate directly to each other in the first place. So once we've got them pointed at each other's public IPs, we then have to have matching proposals for our haggle negotiations for both phase one and phase two.

6:54Now again, the interesting thing when configuring a site to site between Azure and AWS is you don't need to know any of this. You can just accept the defaults and it'll come up on its own. They have matching proposal suites somewhere in there already. The other good news is if you're not doing AWS to Azure, you'll configure your AWS configuration and then you'll say, well, I'm using Cisco on my side. I don't know what to do from here. It will literally download a script for you to run.

7:26It shows you all the commands you need to run on your appliance to bring the tunnel up. So in my opinion, they have made it relatively easy and straightforward to bring a site to site to AWS to life. Now, what have I done up until now? What have I scaffolded in preparation for that? Let's talk about that in the next video. Now we have the site to site fundamentals down. I hope this has been informative for you and I'd like to thank you for viewing.

0:00So what have I done in preparation for this deployment? Absolutely nothing in AWS. I got NADA up and running in AWS. But in Azure, I went ahead and scaffolded a very basic virtual network. It's this one right here called site to site demo. Pretty straightforward. Now I want you to take a careful look at right here, the address space. 10, 1, 0. That's the block that's used inside of this. Now much like AWS's VPCs, we have subnets inside of it.

0:30Azure requires the VPN gateway to get its own dedicated subnet when you deploy it. So I've already gone ahead and provision that. For the most part, you don't really have to worry about this because nothing else can attach to that subnet, just the VPN gateway. My servers, though, are going to run in 10, 1, 0. So I went ahead and deployed a basic virtual machine right here called site to site AZ. It does have a public IP that I can use to SSH in and configure it, but it's got a private IP address 10, 0, 0, 0, 4 right there.

1:01I want to be able to ping from my private IP address to a private IP that's running in AWS or vice versa, regardless of what my public IP says. And in order to do that, it'll traverse over a virtual network gateway. Now I especially went ahead and pre provisioned this before I started recording because this thing takes a really long time to deploy, like at least 40 minutes is what it takes to deploy one of these. So go ahead and click in here.

1:32You should consider this the equivalent of an on premises firewall. And this public IP is going to be crucial in figuring out how to connect in. Obviously, AWS is going to need to know this public IP so that it can start to establish the tunnels. Now, this is all that I've done on the Azure side of things. If this was over your head, don't worry. We have Azure training here on CBT nuggets, specifically the advanced virtual networking course, which you can find in the AZ 700 certification exam.

2:05So if you want to learn more about the Azure side of things, check that out. If you're working with things like Meraki or Cisco or Palo Alto or Fortinet or any of that stuff, hey, hit that search bar in the top right corner of your screen and go find that content. Like I said, we're here primarily to talk about the AWS side of things because that's this is an AWS exam. And of course, this is where we're beginning. So I'm in US East to right now. My Azure region is actually south central US.

2:38So for sure, we're, you know, going across the country for this. So what I'm going to do is I'm going to stand up a fresh new VPC to do my work. This video is going to be primarily focused on just establishing the resources that I need. Let's create a VPC. I like VPC and more. We'll just give this a name like S two S for site to site. We see it's going to be called site to site VPC. Now I can't use the same block here, can I? No, I need to use an entirely separate block. So I'm going to create this block is 10, 10, 0, 0, slash 16.

3:11I'm not worried about using IPV six right now or tenancy. I'm fine with two availability zones. I really only need one public subnet, but two is going to be fine. Since I have two availability zones, I don't need any private subnets for this deployment. I don't need a net gateway. I don't need an S three gateway. I'm good to create this VPC. Except I've got the maximum number of internet gateways already deployed. Whoops, let's clean up my mess. OK, so clean up some mess. We create this real quick zero on the private subnets, notes, the S three gateway, create VPC.

3:46And now we're looking a lot better. Great. So got the VPC up and running immediately. What I'm going to do now, so I'm going to attach a workload to it. Let's jump over to EC two and spin up just a very quick EC two instance. I'm going to hit launch an instance. We'll call this something like site to site demo. Very simple. I'm OK with using Amazon Linux for good measure. I'll put this on something like free tier eligible Amazon Linux to rather than the 2023 image.

4:16I'll go ahead and just create a new key pair from scratch. I'm going to be using the PEM file. You feel free to change what you want. So I'm going to call this site to site PEM. If you're using putty, use the PPK will create the key pair. It immediately downloads the key pair. Great. Now let's go ahead and edit the network configurations and make sure I'm setting this to be in the correct VPC. We're going to put it in the public subnet. Of course, what I want to do is make sure I get a public IP so that I can SSH into it.

4:47And of course, I've got SSH open in this case in my security group rules. I'm going to add a rule to allow ICMP. Don't go scroll too much. We're going to allow all ICMP from anywhere just to allow ICMP and ping traffic in to confirm that the machine is up and running. So I'll launch the instance very quickly. This won't take but just a second. So I want to jump over to my EC2 instances. My filter of instance running, obviously, the instance isn't alive just yet.

5:19If I remove the filter, I see that it's open. Now it's running. It's coming up actually. It's an initializing status right now. So I'm going to let this run for a little bit and let it catch up and, you know , get hydrated and brought to life. So a little bit of refreshing and the checks have passed. So that looks good. Now my SSH management tool is secure CRT. So what I'm going to do is I'm going to add a new session for my EC2 instance here. We'll jump on over into it right here. I'll grab it by the instance ID. I'll grab the public IP address right here and I'm going to paste it in.

5:54The username for an Amazon Linux is EC2 user, of course. We'll hit continue, continue. And I'll just call this AWS site to site. How about that? And press return. Now, with that being said, I'm going to change this properties real quick and make sure it uses those SSH keys. So when I go into SSH to highlight public key, I hit the gear and I point it to a different public key pair. So the public key pair is selected. I click OK, I click OK, and now I should be able to SSH in without any issues.

6:28Looks good. Here I am. So I'll give it a pseudo Sue, elevate myself into the root user. I'll make a directory real quick called AWS and then move into AWS. That way I can quickly tell that I'm on my AWS server prompt. That's really all there is to it. I'll get a similar session going here for my Azure server. So let me jump over here into my Azure virtual machine. I'll grab the public IP right there. And I set this one up with password authentication. So this one should go much easier.

7:00We'll say new session. Next, there's the user account or excuse me, the IP address and the user account. I'm going to edit this to not even bother with key pairs. I want to go straight into password authentication and I'll set the password right now. I'll just go ahead and type it in real quick, confirm my password right now real quick and hit enter to SSA gen looks good.

7:31Same drill, give it a pseudo Sue to elevate myself to root, make a directory called this one Azure change into Azure. Now I know I'm on my Azure server. So obviously I should not be able to ping these from the inside to the inside right now. If this one is 10, 0, 0, 4 should definitely not be able to ping from my AWS side of things to the Azure side of things. There's no encrypted tunnel and you can't ping from private IP to private IP over the internet.

8:02A quick IP address shows that I'm coming from 10, 10, 27, 168. So naturally test on both sides. Nothing's looking good here. So we'll cancel that. So with these resources stood up, I've got a little bit of lab environment that I can start working with. Now, in the next video, we'll start building out the components we need to get the AWS side working and ready for a site to site tunnel. I hope this has been informative for you. I'd like to thank you for viewing.

0:00Cool. So what's next? Now we actually start focusing in on the AWS side of things. This is what I want you to know about AWS and really Azure in general. I'm just going to use this little white space right here. When we have our VPC, which of course has a block of IP addresses, there's two things that we do. Again, this is the same fundamental thing that we do in Azure as well. The first is the thing that really represents our firewall appliance. And like I said, that was a virtual network gateway.

0:34This is going to get a public IP address. And this is where ultimately our external appliances are going to connect to. We're also going to have to tell this virtual network gateway how to connect to the what they consider the local network gateway. Again, this is the same between Azure and AWS. So I want you to understand this concept. They consider the VPC, the remote end of it. And where you're sitting, pretending maybe you're in an HQ, this is considered your local side of things.

1:10This is the nomenclature of it. So when you're in the AWS console or the Azure portal, they're going to be referring to the cloud as remote and you're on-prem environment as local. So for the virtual gateway to connect to the local environment, we create a logical resource called the customer gateway. And this basically contains the public IP of your local firewall and the subnets of your local environment that's going to allow to come over.

1:48So the virtual network gateway here, we'll be able to see, ah, this is the resource that I'm connecting to, which really just points it to the on-prem environment. This again is identical to what Azure does too. So watch this. We're going to jump over to the VPC section here. Let's go into VPCs. And the first thing I'm going to create is the virtual network gateway. We scroll down here to virtual private network. And here we see the customer gateways.

2:20We're not there yet. We're going to start by creating our virtual private gateway. So we'll give this a click and this is just going to establish the appliance itself. I don't know why I show you in this deleted one. We can just feel free to ignore that. We're going to create a new virtual private gateway. And we'll call this AWS to AZ for Azure. I'm going to allow it to use the default ASN or autonomous system number. If you want to use BGP to share subnets and learned prefixes back and forth to each other, that could greatly simplify your workload rather than having to custom configure static routes.

2:58For small deployments like this, though, where we're really only talking one or two subnets on each side of the tunnel, perfectly acceptable to use static routes. Now, of course, if you were using custom ASNs, in this case, you would be typing in private BGP ASNs. I'm not worried about tagging this, so I'm just going to create the appliance. So it'll take just a moment to create the appliance. It's in a detached state by default, which is perfectly fine. What do we need to do now? Well, we need to attach it.

3:28We get to pick the VPC that we want this to attach to. So we say attach to VPC under the actions. We choose our VPC, which in my case was project VPC, because I had to recreate the VPC and I forgot to name it site to site VPC. You get it. We're going to go attached to VPC, and it's in the attaching state. It can take a minute or two to attach, so we'll just refresh it and wait for it to get done attaching. Okay, so now it is attached, which is a great sign.

3:59Got a little bit more work to do, a few more resources to create. So what I'll do under my VPC section, I'll scroll back down, and now we'll create the customer gateway. So as you can tell, I've already been trying to lab this up, you know, in preparation, but we'll create a new fresh one real quick. We'll call this Azure CGW for customer gateway. I'll leave it as the standard BGP right here, ASN of 65,000, even though we can choose not to use BGP if that's what we want to do. What's the public IP address of my Azure appliance?

4:33Well, if I jump back to Azure here, I'm going to grab. This is my virtual machine. That's not it. We need to go into the virtual network gateway right here, and I'll see the public IP address 20, 97, 0, 242 right there. I'll copy it. I'll jump back here and paste it in, and I'll create the customer gateway. So at this point, I have a customer gateway, and I have a virtual private gateway. If I select this virtual private gateway, you can see a little bit more details about it, not a whole lot here that's given away.

5:09We can go into the virtual gateway ID IP, and you can see it doesn't really give you a lot of information aside from the Amazon ASN and the VPC that it's connected to. So obviously what I need to do now is I need to create the customer gateway, or what Azure calls the local network gateway, representing the AWS side of things. So that begs the question, how do I find my virtual private gateway's public IP ? One of the easiest ways to do that is to actually set up the site-to-site VPN connection now on the AWS side of things.

5:45That's what we'll pick up in the next video. For now, we've built out our gateways and got them attached. We'll configure the AWS connection next. I hope this has been informative for you, and I'd like to thank you for viewing .

0:00So what I'm going to jump into immediately is creating a VPN connection primarily so that we can get the public IPs to create the local network gateway in Azure. We'll create the VPN connection here, and I'll call this VPN to AZ. This is going to be a virtual private gateway. This is a two way street site to site from public IP to public IP. If we were actually building a hub and spoke topology where my spokes could be on Prem or colo or VPCs or other clouds.

0:47Any combination of these around here, we would create a transit gateway. Basically this is a virtual private gateway where we're built to handle many connections and then forward learned prefixes to the remote spokes. That's what the transit gateway is built to do. So in this case, since I'm just doing a one to one connection, I'm going to use a virtual private gateway, which gateway appliance. Well, the only one that we 've got clicked on that drop down.

1:19What's the destination. This is why we created the customer gateway. Now if we want to use dynamic, we can establish the BGP peer to peer connectivity. Since I've got a small network to work with here, I'm just going to set these to be a static IP prefix. Now it's important to understand this is not going to update the actual routing of your VPC. This is just to help the virtual network gateway understand what are the remote subnets that it's going to transmit traffic to.

1:52So if I jump over into Azure back into my virtual network back into site to site demo, I see my block space right here 10, 1, 0, 0, I'll copy it. Paste it in under static prefixes like this. Looks good. I think, wait, right? There we go. I got an extra space in there. We'll click it and now we've got it in here. Now if I wanted to start filtering out like only allow traffic from this subnet or destined to the subnet again, look local and remote.

2:28It's that key terminology local equals customer on premises remote is AWS side. So these are the subnets that we can define that are allowed to communicate over the tunnel right here. We can say the local subnets that are allowed to communicate right here and the default or in the AWS subnets or the remote subnets that are allowed to communicate over the tunnel are right here. Now these are optional. We can leave these unchecked and that will allow anything. Now remember, haggle. That's what tunnel one options and tunnel two options are all about.

3:01This is the phase one tunnel. This is the phase two tunnel. So if you look at your tunnel one options, take a scroll down and you'll start to see things like what's the prep of the pre share key. Do you want to edit the tunnel options? Click this and this is where you start to see phase one encryption phase two encryption phase one phase two phase one phase two. If you help me in like lifetime rekeying like it's a lot. It's a lot of stuff.

3:36But with all of these checked, that means there's some combination of proposal suite that could be matched by the remote peer in an ideal scenario. You don't have everything checked. You have only what you need checked. But for Azure to AWS communications and simplicity sakes, this is what we're going to do. Now I did just say this is phase one and phase two. That's actually not correct. What the virtual private gateway does is it actually gets to public IPs and you can establish two IP sec tunnels in a truly redundant hybrid environment.

4:10You would have a rack with two firewalls, wouldn't you? And you could do active active load balancing or active standby load balancing and failing over to the alternative public private IP sec tunnel. The Azure virtual network gateway is also configured to have two public IPs and set up to establish tunnels, but you only have to have one. The interesting thing is, is you can adjust the parameters for tunnel one versus tunnel two. So maybe you could even have Cisco on one side and Palo Alto on the other and they might support different encryption algorithms.

4:50You got flexibility and controlling how that works. So what I'm going to do is I'm going to create the VPN connection and it's going to be an appending state for a little bit. If I actually click on the VPN ID, we can scroll down and now I can see my public IPs for each of the tunnels. Both are in the downstate. And here's the thing that I want you to understand, because this can be very stressful the first time you do it in both AWS and Azure. The tunnels come up and don't reflect it in the console or the portal for several minutes and you'll be sweating bullets like, oh, the tunnels are down because it says down on the screen.

5:31But if you actually try like a ping test, it might actually work. So now that the tunnel has been configured on the AWS side of things and I have outside public IPs, I can now configure the Azure side of things. So what we're going to do is we're going to wrap it up in the next video, put a little bow on it and stand up that site to site tunnel on the Azure side of things. I hope this has been informative for you and I'd like to thank you for viewing.

0:00Okay, so in Azure, I've got a virtual network, I've got a virtual machine and a virtual network gateway, but I need the customer gateway equivalent in Azure. In Azure, they call it the local network gateway. Again, that key terminology there, remember local equals on-prem. So in this case, Azure is saying, I don't know where you want me to go to, so you need to create the local network gateway to stand that up. Now, where the virtual network gateways take like an hour to deploy, local network gateways take like five seconds, because all they really are is just logical configurations.

0:38They're not actually provisioning any resources here. So I'll put this in my app to have resource group, we'll call this AWS GW for AWS gateway, and where am I going? Right here is my tunnel one endpoint. What are the address spaces or subnets on the other end? What does AWS currently have? Well, if I look back in my VPC, we'll go back in here to my VPC, I've got this VPC and I see my CIDR notation right here, 10, 10, 0, 0, 16.

1:12So here, I'll put my address spaces 10, 10, 0, 0, /16 without the superfluous period right there. And that's really it. There's an advanced tab where you can configure BGP settings. It's the same time. So if you wanted to configure BGP, we would have set things like 65,000 to be our ASN, and what is the remote BGP peer IP address? In this case, AWS actually uses an epipit address, a 169.254 address to configure that.

1:47So make sure if you are using BGP, you look that up and figure out which one of those epipit addresses it has configured. We'll review and create this customer local network gateway right here, customer gateway at AWS side of things. And you'll see in Azure, it's just going to deploy super duper quick. So go to the resource, everything looks great here. Now it's time to stand up the connection much like I did on the AWS side of things. To do this, we go back into our virtual network gateway and we come down here into connections.

2:21Now I know I said you downloaded configuration from AWS and it'll show you like how to do things in Cisco. I'm going to show you that in just a second because that's how we actually get the pre-share key, no matter what. So just bear with me, one second, you're going to see it. We're going to add a connection on the AWS side of things. It's not VNet to VNet, that's really Azure to Azure. In this case, we're doing a true site to site tunnel. I'll call this AZ to AWS. And the region is South Central US.

2:52That's where my resources currently are. We'll go into the actual tunnel configuration by going into the settings tab. We choose our virtual network gateway. That's the Azure side of things. We choose the local network gateway, that's AWS. And now it wants the pre-share key. So where do I go to get the pre-share key? I'll go back here into AWS. We'll jump down here to the site to site connections. We'll click on the site to site connection. And right here, you see download configuration. Give it a click.

3:22And this, pretty cool, right? This is where you get to choose your manufacturer. So you got a lot of options here. Sonic wall, P F sense, Palo Alto, Micretik, Yadi Ade Ade Juniper, Cisco, Iraqi checkpoint, all the usual suspects, if you will, are there. We'll download Open Swan because it's really easy to see and understand. We're gonna leave this on IKEV one. We'll click download and it downloads a text file, which comes up way unlike the third screen that's farthest away from me.

3:58Hang on. So let's drag it onto this screen. So, oh, I can't because I'm full screen right now. Hang on. Okay, now it'll let me bring it onto this full screen. Let me go big, let me zoom, weigh in so you can see. Okay, look, see, IPsec tunnel number one. It tells you step-for-step what you should do if you were configuring this for Open Swan. The same thing would be true if this were like a Cisco appliance. It would show you all of the CLI commands to create. What I want you to do is look right here on step five.

4:30This is the pre-shared key for tunnel number one. So it's important to keep in mind that this pre-share key is directly associated with this public IP address in AWS, okay? Tunnel one is for this public IP in AWS and gets this pre-share key. Tunnel two is for a different public IP in AWS and gets a different pre-share key. So keep those straight. Tunnel one and tunnel two are different and they're for different public IP addresses.

5:04So back in Azure, I will paste in the pre-share key. Looks good. This was for IKEV one. And we can really leave everything else the same. So in this case, I'll do a review and create and I'll do create. Now we're not done. This might bring the tunnel up, but we still have a big problem. The AWS VPC is still not routing traffic through the tunnel. What we need to do really quickly is adjust this route table that's associated with my VPC.

5:38So I'll go to my VPCs, I'll go into this VPC right here and I see it's main route table right here, this RTB063 blah, blah, blah. So what I'll do is I'll bring up this route table real quick and I'll edit the routes. First thing I'll do is I'll add a route to 10100/16, which is my Azure subnet and that's gonna go towards a virtual private gateway. The virtual private gateway is the one that I've labeled AWS to Azure.

6:11I'm also gonna add a default route in here. That's gonna go towards my internet gateway, which is attached to that VPC and we'll save the changes. For good measure, I also recommend taking a careful look at how traffic is actually gonna flow throughout your environment too. Look, most of my traffic actually is pointed towards this project route table instead of the main route table here. So you probably wanna adjust the project route table as well, depending on what your VPC configuration is.

6:41You can jump right into it and as you can see, I went ahead and added the virtual gateway route towards the Azure subnet at the same time. So with my route table adjustments in place and my connection being deployed in Azure, what does my virtual network or my virtual private gateway think of it now? When I jump over to virtual private gateways into, wait, wait, wait, I was sorry. When I jump into my site to site VPN connections into my VPN ID, ah, green means go, right?

7:13Tunnel one is up, which is great. And it makes sense because I didn't configure tunnel two, did I? What does the Azure side of things think about it? Is it already up to snuff? Let's jump back here into the virtual network gateway, down into connections. It might say, yeah, now it shows connected too. So my tunnel, my main tunnel is for sure up. Let's bring up the backup tunnel too. I'll add a second connection into the mix. Site to site, we'll call this AZ to AWS two.

7:44This was from my South Central US location in Azure. Jump into the settings, choose site to site. I just went ahead and created the local network gateway representing my backup public IP with its backup pre-share key. Well, this backup public IP. So let's now grab that backup pre-share key. So we'll jump here, scroll down to tunnel two, grab this pre-share key, paste it back into Azure and accept the defaults for everything, review and create and create.

8:22So it'll take just a moment to deploy this new connection when it finds its sea legs. So to speak, it'll take a few minutes to refresh and find its footing. We should see two connections in place. Okay, that deployment succeeds, but like I say, it can take several minutes for these connections to actually refresh. You can't even see it, there's a second connection. See now it just popped up right now and it's currently in the unknown status. It will take a little bit for both sides to see these tunnels come up. Okay, I've let it sit for a little bit. Let's jump back here.

8:52I'm gonna refresh the AWS console. Hey, two greens, the tunnels are alive. Back in Azure, it's still trying to find its sea legs on that second tunnel. But like I say, it can really take several minutes for this to really come up and show connected on both sides. For sure, AWS sees them both as up, which is a great sign. Sometimes the cache on, hey, there goes, you just switched to connected right now. You just saw it with your own eyes. So now both sides of my tunnel see the tunnel as up.

9:24So we've done it, we've configured an end-to-end site-to-site VPN tunnel between Azure and AWS. Like I said, I can't stress this enough that your results are definitely going to vary depending on your on-premises implementation or whatever appliances you're using for what's considered the local side of the tunnels. For now, I hope this has been informative for you and I'd like to thank you for viewing.

0:00So my challenge to you was can you recall your Haggle really really important for troubleshooting VPNs H is for hashing data integrity making sure it hasn't been transformed when it arrives at its destination Authentication do we trust the appliance that we're actually connecting to a lot of hackers can spoof a source IP address But if they don't know the pre-share key or have the right certificate They're not getting in the Diffie-Hellman group. This is really a algorithm of cipher if you will that's designed to Generate seed keys in order to be exchanged back and forth used as part of the actual encryption itself Encryption uses keys to encrypt or decrypt data. Where do those keys come from the Diffie-Hellman group?

0:57The lifetime how long is this tunnel good for before we have to re-authenticate and repropose? new Haggle new proposal suites. This is usually measured in seconds and it's usually 28,800 and lastly the encryption algorithm itself What is actually being used to encrypt or decrypt the data so that we correctly encrypt it or decrypt it So that we can forward it on to the next destination. This has been my challenge to you I think this is the most important part in working with all IPsec tunnels is understanding phase one and phase two Proposals and negotiations. I hope this has been informative for you and I'd like to thank you for viewing