Secured Virtual Hub and Azure Virtual WAN Custom Route Tables - demo and technical deep dive
Vložit
- čas přidán 24. 07. 2024
- docs.microsoft.com/en-us/azur...
azure.microsoft.com/en-us/ser...
docs.microsoft.com/en-us/azur...
00:00 Introduction and customer scenario
03:21 Traffic flow requirements [VNet, Branch, Internet, On-Premises]
05:02 Topology diagram and testing components
07:11 Custom route table configuration, association and propagation
12:12 VM NIC Effective routes analysis
15:09 Test 1 - Spoke-to-spoke via Virtual Hub Router
17:04 Test 2 - Spoke-to-spoke via Azure Firewall
19:08 Test 3 - On-Premises via Azure Firewall
20:43 Test 4 - Internet via Azure Firewall
22:10 Conclusion including alternative solutions and multi-region considerations
This is pure gold!
I have looked everywhere to get an explanation of how route tables work in Azure and this is the first material where it's properly explained.
This is the best explanation you will see on vWAN hub routing. Hours of reading got me nowhere then Adam makes it so clear and simple. Great range of vids covering complex real world scenarios. Cheers.
This is just exceptionable good - and one of the most simple diagrams to communicate advanced network designs
Great video Adam !!! You have explained the use case and solution with lot of details, which helps !!!
Awesome work Adam. Keep this great content coming !!!!
Excellent job, Adam. I am a big fan of your videos 👍.
Great content, Adam. Oh, how I wish this were out there when I laid my network out last March! :)
Very informative, good job Adam.
This was a great explanation! Thanks!
what a great video, kudos Adam!
Excellent Video. Thank you
Excellent video!
very nice video ...
Thanks Adam, any idea how to look at the effective routes of the Azure FW? I have VPN Sites with no BGP coming to the secured vHub and wondering how the Azure FW knows how to route back the traffic to the VPN GW. (The effective routes of the vHub default route table only shows the static route pointing to the Azure FW)
Great video Adam, thank you. Although I wish I had found it two weeks ago before we tackled this problem. Do you have any further information regarding the global routing restriction you mention @ 23:00 ? In the last few days we have been able to configure exactly this scenario without routing intent. I am aware of the page and known limitation you reference so concerned we have missed something.
Thanks for the explanation, your videos are excellent. I have a question which I'm not able to solve. What if you want to route all traffic through the Azure firewall. Thus V2V and B2V and V2B when the branches are connected through a S2S?
Great content, this isn't explained well in many cases
Thank you ! This was awesome! How well does this work with forced tunneling? We have a security requirement for quad 0 back to on-prem but would like to still allow egress out for the PaaS services to phone home via the FW. Currently we are using UDR's on the subnets to accomplish this but we have no ability to put a UDR in the FW subnet when using VWAN.
Hi Joseph. There can only be one default route bouncing around in the VWAN Hub, either back to onprem, or out via Azure Firewall, not both. If you want to 0/0 to onprem, but have PaaS services go out locally, you need to use service endpoints and/or private endpoints on the spoke vnets to circumnavigate the default route.
@@AdamStuart1 thank you very much for taking the time to explain that. The more specific routes by using SE's and PEP's helps but we are stuck with items like RDPShortPath for AVD and Bastion that just won't work well or at all with 0/0 to on-prem. I wish there was a list out there of all the Azure services that need 0/0 internet to function properly so we can make our case with Security and EA to advertise more specific routes via BGP or in the very least avoid these services. I am going to engage our MSFT Account Team about it. Thanks again!
great video. would be very helpful if you can make a video on how the same scenario will work if there is a NVA inside the VWAN acting as a sdwan appliance for establishing overlay network with onprem. Id imagine the SDWAN appliance will be in its own vnet and have a default RT associated and propagated and all the remaining vnets will have custom RT like your scenario. We dont want any overlay vnet routes inside the underlay route table.
did you find any solution for this ?
Apologize if this was asked before: I’m wondering under which conditions one can decide to use vWAN instead of hub VNET?
Hope this helps, thanks. docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/define-an-azure-network-topology
@@AdamStuart1 Thank you
What terminal program are you using there ? - really usefull video by the way :-)
Windows terminal 👌🏻
Is there a way to create a Standard_NC virtual machine, please help
Sorry I have no idea what this refers to, or how it is relevant in the context how the video.
How does this setup look on the secured vWAN / firewall manager portal?
You cannot configure custom route tables in that view, so this topology effectively means you do not use AZFW-Manager. In fact you get a message in AZFW-Manager if you use custom-route tables, stating that configuration must be done within the Virtual WAN Routing section itself. Hope this helps, thanks for watching.
@@AdamStuart1 Thanks - and thanks for the video, really informative and well presented! We have been dealing with secured vWAN hub routing scenarios a fair bit and this was a tremendously valuable resource.
Is this prior to internet and private routing intent on the secured vhub?
Yes custom rt are not currently compatible with routing intent feature.
@@AdamStuart1 If I have a need to phased approach migration from the third party firewall NVA which connects multiple spokes through static route then custom routing seems like better solution than route intent. When I was simulating third party NVA with AZ basic firewall hosted in core and on prem traffic with BGP vnet connected subscription to vWAN. I lost connection from onprem to udr as soon as I enabled private route intennt. When I enabled internet intent, I lost RDP access from public IP on the on prem VM which means I will probably lose access to any web services using public IP NATon prem, as it starts to route onprem traffic to Az firewall in secured hub. To avoid all that issue it might be better to migrate one spoke at time with custom route without using Firewall security config route intent and enable intent when all spokes are migrated and when all Az firewall rules are tested for all subscriptions.