 Hi, I'm Amy Collier, Senior Cloud Advocate at Microsoft, and today I'm joined with Jason Medina, Senior Cloud Advocate for ABS. Today, we're going to discuss Secure end-to-end connectivity without ExpressRoc Global Reach. Thanks for joining us, Jason. Hi. Thank you for having me. All right. Let's get down to it. All right. Today, what we're going to be discussing is Secure end-to-end connectivity without ExpressRoc Global Reach, and reasons on why you'd want to do that. Yeah. That's definitely a big question for a lot of our customers, and we're going to help answer all these questions during the session, so let's get to it. Sounds good. For our agenda today, we're going to be discussing why you need two vNets in order to do this deployment. We're going to be discussing traffic flow and what that's going to look like. We're also going to be discussing the two vNets that you would need to deploy, including your Hub Virtual Network and your ABS Transit Virtual Network. We'll be discussing your spoke vNets and how that would be peered back to your Hub. Okay. And we'll be discussing also your ABS Internet connectivity and any last-minute changes that you need to make in the Azure portal. Sounds good. Now, before we get to that, we just want to discuss here with our Azure VMWare Landing Zone Accelerator. The Accelerator is a collection of code, docs, assets to speed up the deployment. Please visit our reference architecture and representation guides for that. All right. So, yeah, why two vNets? I'm curious. So, first and foremost, what we're trying to accomplish here is we want to have all traffic from ABS get monitored from or inspected via a third-party variable NVA. In this case, this would be your inside your Hub Virtual Network. So this would be this NVA here. And in order to accomplish that and to meet those requirements to have all that traffic get monitored via a third-party NVA, this could be any third-party NVA of your choosing as long as it supports BGP. You can go ahead and have it deployed and monitor all types of traffic in this case for any traffic to on-premise, internet bound, inbound. And this is pretty much how we have our deployment laid out for. So we'll get more into the details as to why we're doing this and what it looks like. So traffic flow. Let's discuss traffic flow first here. In traditional ABS deployments and actually in the majority of our deployments, you will notice that for ExpressRoute, we will always have a global reach connection going back to on-premise. That does not exist with this deployment. And this deployment, if you notice here, we will have our ExpressRoute connection that will terminate to a gateway subnet inside of the ABS Transit Virtual Network. Is this because maybe you're in a region without global reach? Correct. This could be in a region where you don't have global reach or it could be a situation where you just would like to have all the traffic, such as this legend above. That discusses how you would like to monitor and inspect your traffic. So the green line, all these lines indicate the types of traffic that are coming out of ABS. So the green line indicates ABS to and from on-premise. The purple line indicates the Azure VMR solution to internet. And blue line indicates internet inbound to Azure VMR solution, L4, TCP, or UDP. And the red line also indicates the internet inbound to Azure VMR solution, L7, and HTTPS. Now, if you follow all that traffic, I'm going to follow these arrows here, all this traffic is being funneled back down and going back through our firewall NVA. This is our third-party NVA. From here, it'll be inspected and then set back out to its destination. In this case, if we're inspecting traffic to on-premise, traffic will get inspected here and get sent on to on-premise. Vice versa, traffic coming back from on-premise will eventually take the gateway express route as its next hop and then eventually get monitored over to the NVA side. So there is no asymmetric traffic here. Traffic is all symmetric. So we're going to break this down into each vNet, and we're going to discuss what's needed to meet the requirements. The hub virtual network. Oh, yeah. So for our express route gateway for the hub virtual network, what we're going to have is this a primary reason for this is going to be to connect back to your on-premise. And what you'll need here is you're going to need a gateway subnet with a slash 27 or larger. It's going to be case sensitive, and it's going to have to be named gateway subnet. You will need to attach a route table with UDR entries that will force traffic back to your NVA. So the route table is exclusively for inbound traffic coming from on-premise. So what does this mean? So now if traffic is coming down over to the express route, this route table right here is essentially forcing all the traffic to go back to your firewall NVA. That is the purpose of this route table. If you notice, all the next hops are going to be your firewall internal VIPs. OK. And can that firewall NVA be redundant? Yes, it can be redundant. You can have a load balancer, an internal load balancer, in front of it. So instead of having a UDR entry with a next hop of your firewall, you would have the UDR entry with a next hop of your internal load balancer VIP. Gotcha. That makes sense. And now we talk about our Azure Route server. The Azure Route server, the purpose of the Azure Route server is it gives you the availability to inject routes from a third-party NVA into the Azure network. So in this case, one of those examples would be a default route. You're going to be injecting a default route from your third-party NVA into the Azure Route server. And what this is going to do is it will go ahead and advertise these routes back over to our BGP NVA, which is what we're going to show next. One of the most important pieces that you'll need here is you'll need to create a slash 27 or larger subnet named exactly Route Server subnet. You will need to deploy the Azure Route server with branch to branch enabled. And Azure Route server automatically forms a BGP neighbor with the express route gateway in the VNet. So this IBGP neighbor that you see here is automatic. That's great. And now we talk about our third-party firewall. And with our third-party firewall, most of the times you will need to create a external internal and management subnet for your firewall. You will need to form a BGP neighbor from this third-party firewall to the Azure Route server. And also, you will be advertising a default route from your firewall to the Azure Route server. So over to the next slide, we're going to discuss here our AVS Transit Virtual Network. So now that we've already built out the Hub VNet, we have to build out this new AVS Transit Virtual Network, this new VNet. One of the first things you're going to do is when you build this VNet out, you have to peer it with back to your Hub VNet. So make sure to create a VNet peering between your AVS Transit VNet and your Hub VNet. And again here, we have our Express Route Gateway. Our Express Route Gateway here is main purpose is going to be to have connectivity back to AVS. And the requirements are the same. Requirements are going to be that you're going to need to have a slash 27 or larger subnet. That is going to be exactly named Gateway Subnet here. You will also need here in Azure Route Server. Azure Route Server is going to be peering with what we call our BGP-NVA, which is what we're going to get to next. But the requirements for the Azure Route Server are going to be exactly the same from prior. So again, slash 27 or larger, make sure that it's Azure Route Server Subnet and having branch to branch enabled. OK, that makes sense. You will need to, under Azure Route Server, to form a BGP neighbor to your BGP-NVA. And it automatically forms this neighbor right here, which is between your Azure Route Server and your Gateway Subnet. So we talk about this third party BGP-NVA. What is it? So this third party BGP-NVA can be any router that supports BGP, any NVA that supports BGP. Does it have to necessarily be a firewall? In this case, you will need to create tunics. And we're at SVM, we'll need tunics. And we're needing inside and outside. Your inside will appear via EBGP to your Azure Route Server. And the outside will appear via EBGP to your Azure Route Server in the hub. And also, another note here is, we must aggregate the ABS slash 22 address block in BGP announcements. What does this mean? When deploying ABS, you will have a slash 22 block that you've done a deployment with. Right. And essentially, that slash 22 block gets cut up into different prefixes. It's a different route, right? So what we want to do is, from this BGP-NVA, we want to be able to summarize this slash 22 and advertise it over to the Azure Route Server. Gotcha. So the entire block. Correct. Correct. We want to advertise that. And if you notice here, on the outside, we have another route table that's attached to this outside subnet. This outside subnet is essentially going to have a UDR entry where we're going to have, in this route table, we're going to have a disabled route propagation. And we're going to force our default route UDR and any destination hub vNet with the next hop of the firewall internal IP. So this is the next hop on the firewall side. Right. So we're forcing the traffic back over to take the back, following back to the third party NVA for our firewall. Make sure all traffic gets inspected. Correct. Yeah. Correct. OK. And now we talk about our spoke vNets here. With our spoke vNets, we want to have a normally, what we would recommend is to have a route table attached to all your subnets. And inside the subnet, you want to have a static default UDR entry, which is a default route, back up to your NVA. But you also want to disable route propagation. Very important to disable route propagation on the spoke vNets. If you do not do that, you will learn more specific routes and essentially bypass your firewall NVA. So to avoid that, what we essentially end up doing is we disable route propagation, and we just have the one default route UDR entry back up to your NVA. OK. Yeah, just forcing all your traffic through the NVA. Correct. Correct. Now as far as internet connectivity, once you have everything deployed and it's all set, you want to make sure under the Azure portal for AVS Private Cloud, under Workload Networking, for internet connectivity, you want to make sure that you choose to do not connect or connect using default route from Azure. This is going to give your AVS Private Cloud the capability to learn on the default route, which is the default route that you're advertising from your third party NVA. So you have to make sure that this is already an option that you've already chosen under the portal. That makes sense, yeah. Go through my firewall. Now, we do understand that there's a lot of steps to this, and there is a lot to do in terms of configuration. So we do have some step-by-step guides. Our first step-by-step guide here uses an example with Cisco 8K NVAs. And so we have tested this before with prior customers, and it's worked great. And we do have another step-by-step guide that uses an example with Linux VM running Quagga. If you choose not to use any vendor and you would like to use something that's a little more open source, this would be your option. Good to know. And just like how we had in our first networking scenario, we still have all these landing zones where you can get multi-region guidance on your AVS designs. And all the latest additions are on this GitHub repo. So we always like to point that out in each video in case you missed the first one. But that's a good reference area is the GitHub repo at these links. All right. All right. So essentially, wrapping this up is key notes to take away really is your internet connectivity with your NVA. Keeping in mind that you will need a third-party NVA with your firewall. And Azure Firewall right now is currently not supported because we do not currently, as of this date of this video, do not support BGP with Azure Firewall. OK. That's awesome. And we want to make sure that we're summarizing our Layer 3 NVA. We're summarizing those routes. That's slash 22. Or any connected segments. We want to make sure that we're summarizing those routes. Now, for our next piece is disabling route propagation in the spokes to steer traffic back to the NVA. That is a very important piece right there because you want to make sure traffic is always going to be symmetric. So you want to be able to make sure that your whole traffic always to get to your spokes, from AVS to your spokes. It is going to traverse the firewall. We want to make sure that traffic coming back from the spokes going to AVS traverse your firewall as well. So making sure to disable route propagation to have that default UDR in there is very important. Keep note of your traffic flows. Definitely recommended understanding your traffic flows for AVS and inspecting everything is going to be a very big keynote because if you don't understand this, you're going to have a little bit of a difficult time doing some troubleshooting. As long as you understand the flow of your traffic, which in this case is pretty much straightforward because you're always going to be going through the firewall. Just having that understanding that where you'll be troubleshooting your first go-to for troubleshooting is going to be very important. So just always keeping in note as to what you're going to be inspecting. It's probably the firewall blocking. Yeah. And accelerate deployment with the landing zone accelerator to please visit our acceleration guides. And that's pretty much it. Right. I mean, those are a great place to start because it has all the best practices and give an arm template and start deploying. So thanks so much, Jason. This was great coverage, having another scenario with two VNets and then the NVA to NVA traffic versus what we talked about the VWAN hub with Sabine earlier. So this was another great session. Thank you. Also, well, thank you so much for having me. I appreciate it.