Secure Internet Egress via DMZ VNet | Azure Virtual WAN

hi everyone my name is heather z and i am a specialist in the azure networking global black belt team in this video we will show how we can use a dmz v-net in a virtual wan to secure all internet egress traffic we will not walk through the basics of building a virtual lan in components such as the vpn gateway as these steps are well documented instead we will focus on configuring a default route pointing to the most commonly used active active virtual firewall deployment and show how this default route is redistributed across virtual ram so let's get started the scenario here is an organization which has requirement for all internet destin traffic to be inspected by a pair of active active network virtual appliance firewalls deployed in a dmz v-net the architecture is a multi-region v-hub design west and east where we have branch connected by site-to-site vpn spoke vnads are connected to the hubs and of course the dmz v-net also has a virtual network connection to the hub the expectation is flow 1 or local v-net originated traffic will hit the dmz firewall before egressing to internet similarly flow 2 which is originated from on-prem will also need to hit the active active mvas in the dmz before egressing to the internet finally flow 3 represents a remote v-net originated traffic which is not a common design pattern since most customers will want to egress via a local region nonetheless we will show this as a possible requirement for an organization so before we go to the portal let's highlight some of the specifics in the demo the organization is using rse 1918-172 16 slash 12 block for azure on-premises is using the 10-8 block as well as the 192 168-16 block the branch is connected with ipsec vpn terminating on a cisco csr 1000v and bgp is used for dynamic route exchange between vua on premises the active active mvas are fortigate firewalls sandwiched between public load balancer and internal load balancer traffic egressing the internet will use the public ip address of 52 149 153.228 please make a mental note of this address as it will be important in a demo also make a mental note of the ilb address which is 172 16 136.68 now let's go to the portal we start with the v1 insights to confirm the topology that we are building off of which is a v1 with two hubs east and west in west we have a single spoke v-net connected to the hub and in east we have the dmz v-net a spoke v-net with the vm we showed previously as well as the on-premises site to site vpn with this we have any to any connectivity so let's validate it let's go to let's go to um start with this vm 172 1704 which is the east vm and show that we're able to reach west which is 10 172 about 24.0.4 very good and it looks like my on-premises connection has timed out but nonetheless we will ensure we have reachability to it very good so we already tested connectivity between west and east but let's now test it in the opposite direction ellipse wrong one very good and let's test to on-prem very good we have any to any connectivity okay so now with these two vms let's see what the internet connectivity looks like we'll issue curl if config command which shows me that the address presented to the internet via curl is 2121 20.178 which is the ip address associated with this vm the public ip associated with the vm so it is going directly out to the internet not through the firewalls as we would expect because we have not yet configured it similarly on the west vm we see it is presenting itself to the internet as 23 101 203 207 which is this west vm's public ip now let's double check that against effective routes of each of these nics just to make sure that it makes sense so let's go to 172 17 interface and check the effective routes and what we see here are the routes which are learned through virtual wan um gateways it's learning the on-premises 10-8 um prefix while there's slash 24 but the 10 range in the 192.168 range but the important line to see here is right now it's has the default configuration of zero zero default going directly out to the internet and that is consistent with what we saw here with the 2121 address let's check this against the west spoke vm we see the same thing and again zero slash zero um we're going directly out to the internet not going through the dmz as we would expect and that is consistent with what we saw via the curl command earlier so now let's go ahead and finally configure a virtual round for default route so that all internet destined traffic from the flows that we previously described will go through the dmz to do this we go to the virtual wan blade and we select the hub that is connected to the dmz first so we go to the east hub then we go to the routing blade and in the routing blade we are going to configure a static route for 0 0 in this default route table pointing to the internal load balancer we need to give the route a name so we'll say east to internet we're in the east hub right now the destination prefix representing the um internet is 0 0 so 0 0 is bound for the internet and we're going to force the traffic across the dmz connection that v-net connection and the next top as we mentioned is the internal load balancer address which is 172 16 136.68 we need to specify um the next top ip on top of the connection the connection directs you to the v-net and now we need to specify the next hop which is the load balancer in this particular case so we confirm and then we create this so while this is while this is um updating the route table let's just go back to the diagram and make sure we understand what we have done so far what we've what we did so far is we created within the east virtual hub a static route pointing to zero pointing to the internal load balancer because this is a load balancer traffic now destined for the ilb will be selected by the load balancing algorithm it will select one of the two firewalls on the way out and because these firewalls are backend to the public load balancer and we have used this we have associated this address of 52 149 153.228 with the public load balancer and the back end of the public load balancer are the addresses of the active active fortigate firewalls when traffic goes out it will use this address of 52 149 153.228 and that is how traffic will be seen on the internet from azure azure will now use the address of 52 149 153.228 for egress traffic because nat is required we cannot um we cannot go out to the internet as we know using the blocks of 172 16 172 17 or 10.0 so with that let us go back to our um our um vms and see what it looks like if we issue the curl command again we see that in fact it has changed to 52 149 253 228 for this east vm so now traffic is going out using um the public load balancer ip meaning traffic is egressing the firewall which is exactly what we wanted so if we go back to the vm the effective routes should also match so let's refresh this give it a second to refresh and we'll see that the route table also looks different and indeed whereas before we saw zero slash zero with next hop of internet now next hop is pointing to a gateway address um which represents the virtual hub so traffic is now going through the um virtual hub okay so now we have validated flow number one is using the address of 52 149 153 228 in fact let's do one final one other check with that remember we said we have that test vm which you can still see in the background of the screen i'm going to ssh into it and show you how it looks so i'm going from 170 to 1704 through the hub through the internal load balancer to one of the two active active instance firewalls and hitting this vm here 52 183 63.77 so i can check by netstat the tcp sessions and i see indeed um this local host which has this ssh session this is the one established it is coming from 52 149 253 228 or the public load balancer so with that we've we've proven again that traffic is hitting the firewall now that we've validated flow 1 let's take a look at flow 2 or traffic from on-prem now traffic from on-prem um we'll learn about the zero slash zero default route that is advertised if we choose to propagate the route one thing to know is zero slash zero is um a somewhat dangerous route to propagate so within virtual round we give you selective controls so you can actually block the traffic from propagating across each connection individually so let's first validate that the zero zero that we defined is allowed to propagate across the site-to-site connection and we do that by going into the site to cite blade and checking that default route is propagation is enabled so very good so with that let us go into the on-premises cisco router timed out so let's make sure that even though we've allowed zero zero to be propagated across that side-to-side connection that it actually is being learned and we see here indeed um zero slash zero is learned by bgp and it is coming from 170-223 which is um a gateway in the virtual hub so indeed 0 0 is being propagated so if we do the same test that we did earlier um an ssh test to that test vm the vm is an address that i've just typed in again let's check this netstat command to prove that the sh ssh session is coming from the from the uh public load balancer address which is front ending the two firewalls and indeed it is excellent so we have validated flow 1 and flow 2. with that let us go to flow 3. i can find if i can find a via okay um one thing to understand is zero slash zero by default is not propagated across the hub what that means is even though when you define a typical static route that is not slash zero that static rail can propagate across hubs but by but because zero slash zero is such a special case it does not automatically um propagate which is a um which is a good thing so you'll see that the vm on the west is still accessing the internet directly and we've proven that by this curl curl command however if we want flow three to go across the firewall what we can do is do the exact same thing we did earlier for um for the east static route definition so now we go to the west virtual hub we go to the routing blade we make the definition in the default routing table we'll call this west to internet again the destination prefix is zero slash zero next top we are going to choose the same dmz v-net connection because that is where the firewalls are and we will add the same next top which is the ilb so again what we've done is defined a static route this time in the hub west pointing to a connection that is in a um remote hub that's connected to remote hub and with that spoke one will be able to reach the internet via this dmz v-net complex rather than go out directly um as it had been shown to do so if we go to this vm if we issue the curl command we see that this also has changed to 52 149 253 to 28 when it egresses the internet so now traffic originating from the west vm to the internet will also pass through the firewall we'll do the same test we did earlier which is ssh into the test vm and we see that um the single ssh session on this host um has originated from the um from the mva or has has passed through the mva because of the public ip address so with that we have addressed flows one two and three and have configured them to all go through the dmz v-net so there are two critical points that we need to mention about the mva and that's that um the fortigates and in fact most mva firewalls do have multiple nics in this case there's a trusted side and an untrusted side for this static route configuration we actually need to be sure that the untrusted interface of the firewall is not learning the zero zero route that is being redistributed across the virtual hub because if the untrusted interface learns about zero zero with the iob as the next hop you will have a loop traffic going out to the internet will hit the ilb it will um be processed by the firewall and the firewall will dump it out on the untrusted interface which sends it to azure um but azure sees that the next top is 172 16 136.68 is the ilb which will result in a loop so this problem can be addressed um in one of two ways the simpler way which is what we have done for this demo is simply to disable propagating default route if this is disabled 0-0 will not be learned across this connection and that is not needed by the dmz v-net because there are no other vms in the v-net and you have a static route pointing to it another way of addressing this problem a potential loop problem is to override any hub learned route by udr pointing on to zero zero pointing to the direct hop of internet but the simpler way in my opinion is simply to disable route propagation and by the way if i were to show you um the same edit v-net connection it is obviously enabled on the east spoke otherwise the vm in this east v-net would not have learned the zero-zero route and we would not be going directly we would not be going to the internet by the firewall but this emphasizes the ability to selectively turn off um propagation of default routes across connections whether it's a v-net or whether it is a site-to-site connection as shown previously another important point that we need to emphasize is the nva os has no concept of has no concept of the azure sdn or routes in virtual wan so it needs a little help to know which interface to send on which traffic so in the in the fortinet we will need to define some routes for the on-premises pointing to the trusted interface and the 17216 block to the trusted interface because if these destination prefixes are not in the fortigate routing table when traffic hits the mva it will be dropped because after processing it will not know how to handle it because remember the mva os is independent of the routing in azure sdn so to summarize the steps of what we what we've done we can configure secure internet access via dmz firewalls with these simple steps first you deploy the active active mvas in the dmz v-net by using the standard third-party partner templates nothing needs to change with virtual map now with this dmz v-net you want to build connections to virtual ram and you're going to build connections to to other v-nets and branches you want to make sure the dmz v-net's connection is disabled for propagate default route or alternatively override the untrusted interface with zero zero pointing to the internet you need to be sure that firewalls whose os have no awareness of azure routing have entries so that when a packet comes in passes through inspection it will know how to forward the packet in the default route table in order to get the static route you will create a zero zero rule pointing to the ilb of the nva as the next hop but pointing to the dmz v-net connection and of course if you have a virtual wan with many v-nets you may have some v-nets where you want to break out locally to the internet and you do not want traffic to go through the dmc complex in those particular v-nets you would want to disable propagate default route so this 0-0 is not propagated to those v-nets and of course it's very important to test and validate that zero zero is propagated across the hub appropriately and finally optional step as we did for flow three repeat step five that is defining the static route for zero zero for remote hubs as necessary so hopefully you found this video useful with the step shown you should be able to take a standard third-party firewall in va template deploy in a dmz in a v-net and support supporting your north-south internet traffic originating from workload v-nets or on-premises thank you very much you

Channel: Azure Virtual WAN (vWAN)

Views: 97

Keywords: Secure DMZ, DMZ, NVA, Fortinet, Default Routing, Microsoft, Azure, vwan, virtualWAN, VirtualWAN, VNet

Id: HiSqshZXJ1w

Length: 30min 28sec (1828 seconds)

Published: Thu Dec 09 2021