💼 Join our free class to discover our exclusive three-step framework designed to help you achieve certification and secure high-paying jobs in Azure and DevOps: bit.ly/4a2Xa5W
Thankyou soo much for the detailed explanation. This session has really cleared my doubts and helped me achieving the deployments. Once again thanks a lot sir.
I remember in my previous organization, not all subnets have route table associated. And the traffic still goes to the firewall. How can that be achieved?
In order for traffic to go through the firewall, even if not all subnets have associated route tables, you can configure the default route on the firewall to forward all traffic to the appropriate destination. By setting up the default route, any traffic that does not have a specific route defined will be sent to the firewall for further processing and inspection. This ensures that all network traffic passes through the firewall, regardless of the subnet's individual route table configuration. Hope this helps. Regards Team K21Academy
Yes, Azure Firewall supports IKEv2 VPN for on-premises to Azure VPN connections. However, it is important to note that the Azure Firewall VPN Gateway is still required to create the connection.
Good explanation. Could you also show how to use firewall to intercept traffic for malicious content in a scenario where there is a traffic manager and app services as its backend pools?
To give you a short overview In a scenario where there is a Traffic Manager and App Services as its backend pools, Azure Firewall can be used to intercept traffic for malicious content by deploying it in the same virtual network as the App Services. This will allow Azure Firewall to inspect all traffic going to and from the App Services, and block any traffic that is found to be malicious. We cover this practical implementation during our sessions. To know more? Join our FREE Class: bit.ly/4a9v9cq
Hello. I have a very similar architecture like this built but the work VMs in a spoke can't access work VMs in other spokes. What's the solution other than peering the spokes together?
To enable communication between work VMs in different spokes without directly peering the spokes together, you can implement transitive routing via the hub. Here's the solution: 1. Use the Hub as a Transit Network: - In the hub-and-spoke model, the hub VNet (which typically has the firewall or a network virtual appliance) can act as the transit point between the spokes. 2. Configure User-Defined Routes (UDRs): - In each spoke, create a route table with UDRs that direct traffic meant for other spokes through the hub. - For example, traffic from Spoke1's subnet destined for Spoke2's subnet should be routed through the hub VNet. 3. Ensure the Azure Firewall or NVA Allows Inter-Spoke Traffic: - If you're using Azure Firewall or another network virtual appliance (NVA) in the hub, ensure it's configured to allow and inspect traffic between the spokes. - You may need to create appropriate rules to permit traffic between the spokes' IP ranges. 4. Use BGP if Applicable: - If you're using Azure Virtual WAN, BGP (Border Gateway Protocol) can automatically handle transitive routing between spoke VNets via the hub. 5. Network Security Group (NSG) Rules: - Ensure the NSGs in each spoke allow inbound and outbound traffic to the other spoke’s subnet ranges. By following these steps, you can achieve transitive routing through the hub without direct peering between spokes, keeping your architecture more scalable and secure.
No, you do not need to configure Network Security Group (NSG) rules to allow internet access. When VM-work does not have a public IP and the traffic is passing through Azure Firewall, it means that the access to VM-work is restricted to internal network traffic only. In this setup, VM-work is not directly accessible from the internet, and its inbound traffic is controlled by the Azure Firewall. So if you setup NSG rules then also it will not show any response to it. Hope this helps! Regards Team K21Academy
hmm don't understand why you would route traffic from a different geo-region to another geo-region fw? you would said the traffic over the vNET peering to the speak to the other regions surely?
He was Deployed the HUB ( Firewall ) Subnet on a different region and all other two Spoke subnets was deployed on other two different regions. Inorder to communicate the Spoke Subnets to Firewall subnets we have to enable the Regional VNET Peering , then only Spoke Subnets on Different regions can communicate with Firewall Subnets. In Azure , Azure Firewall Deployment Under each VNETS is not a logical solution as it is bit Costly. That is the reason why he was created a Single firewall under firewall Subnet on Different region and routed all the Spoke Subnet Traffic towards to Firewall Subnet and attached the Spoke subnets on Routing tables. Which means any traffic that is originating from the Spokes subnet to any destinations will be routed to Azure Firewall and based on the Firewall rules ( Network/Application rules) the services will be allow/deny by firewall.
@@praveenkumarp1357 Azure VPN gateway is the major Trap, when you start creating your network and depending to it you need the VPN gateway as the core, and you realize later on the cost it incur that your whole mesh network is dependent to it you cannot just turn it off. that is why others are switching to SDNetworking, trashing the azure vpn gateway out of the scene. I maybe wrong about this, I would be happy someone could shed some light into this.
I see, you created two VM's with public IP's for each vnet. I think one VM with public IP is enough.. You can take any one work(spoke) machine using RDP from public IP machine. from that work(spoke) machine the second work machine can be taken for RDP.. just cost saving for public IP.. Another options is to enable bastion- can be in production environment (mid to big size).. Please comment on your views..
We are using the hub as a firewall. This Firewall is common for 2 machines that are acting as 2 work machines in different machines. So if we are connecting one with public IP to other with private, then only one will be working at a time either. then there is no use of creating 2 separate work machines.
💼 Join our free class to discover our exclusive three-step framework designed to help you achieve certification and secure high-paying jobs in Azure and DevOps: bit.ly/4a2Xa5W
Very clear explanation, though i have no prior networking knowledge I was able to understand the entire explanation. Thanks alot!
Thank you. yours words inspire us to do more and serve you with the best.
one of the best video on firewall
Thank you so much for your kind words! We really appreciate your support
Very nicely explained the concept of Hub and Spoke
Glad you liked it! 😊
Please do let us know what videos you'll like to see next?
Thankyou soo much for the detailed explanation. This session has really cleared my doubts and helped me achieving the deployments. Once again thanks a lot sir.
You are most welcome
Nice explanation. I do agree that it's explained very clearly. Could you please add traffic going from spoke1 to spoke2 via Firewall?
Thank you.. If you want to check the connectivity from spoke 1 to spoke 2 you can ping spoke 1 to spoke 2 or vice versa.
very beautiful explanation ,seeing the architecture might terrifying for begineers or fresher after your brief anyone can accomplish!
Glad you liked it!
man you're awesome! Thank you for uploading this.
Hey thanks! Do let us know what would you love to watch next?
thanks for sharing real scenario ,,very much clear explanation
Glad it was helpful!
I remember in my previous organization, not all subnets have route table associated. And the traffic still goes to the firewall. How can that be achieved?
In order for traffic to go through the firewall, even if not all subnets have associated route tables, you can configure the default route on the firewall to forward all traffic to the appropriate destination. By setting up the default route, any traffic that does not have a specific route defined will be sent to the firewall for further processing and inspection. This ensures that all network traffic passes through the firewall, regardless of the subnet's individual route table configuration.
Hope this helps.
Regards
Team K21Academy
Great content, we're about to migrate to this architecture so many thanks for explaining hub-spoke arch. !
Thanks, keep watching!
Very nicely explained the concept of Hub and Spoke, thank you!
Thanks, keep watching!
This explanation was perfect. Thank you.
Thanks, keep watching!
dose azure firewall support ikev2 VPN (on premise to Azure ) or need VPN gateway
Yes, Azure Firewall supports IKEv2 VPN for on-premises to Azure VPN connections. However, it is important to note that the Azure Firewall VPN Gateway is still required to create the connection.
@@K21Academy
Thank you
Great Explanation👍🏻
Thank you, keep watching!
Indeed!
@@surbhisharma7853 Nice to see u..
Good explanation. Could you also show how to use firewall to intercept traffic for malicious content in a scenario where there is a traffic manager and app services as its backend pools?
To give you a short overview In a scenario where there is a Traffic Manager and App Services as its backend pools, Azure Firewall can be used to intercept traffic for malicious content by deploying it in the same virtual network as the App Services. This will allow Azure Firewall to inspect all traffic going to and from the App Services, and block any traffic that is found to be malicious. We cover this practical implementation during our sessions.
To know more? Join our FREE Class: bit.ly/4a9v9cq
Thanks @@K21Academy Does this mean, in this specific scenario a VNET is mandatory for App service setup?
Great walkthrough!!
Thanks, keep watching!
Very crisp and informative.
Thanks, keep watching!
Thanks, keep watching!
Hello. I have a very similar architecture like this built but the work VMs in a spoke can't access work VMs in other spokes. What's the solution other than peering the spokes together?
To enable communication between work VMs in different spokes without directly peering the spokes together, you can implement transitive routing via the hub.
Here's the solution:
1. Use the Hub as a Transit Network: - In the hub-and-spoke model, the hub VNet (which typically has the firewall or a network virtual appliance) can act as the transit point between the spokes.
2. Configure User-Defined Routes (UDRs): - In each spoke, create a route table with UDRs that direct traffic meant for other spokes through the hub. - For example, traffic from Spoke1's subnet destined for Spoke2's subnet should be routed through the hub VNet.
3. Ensure the Azure Firewall or NVA Allows Inter-Spoke Traffic: - If you're using Azure Firewall or another network virtual appliance (NVA) in the hub, ensure it's configured to allow and inspect traffic between the spokes. - You may need to create appropriate rules to permit traffic between the spokes' IP ranges.
4. Use BGP if Applicable: - If you're using Azure Virtual WAN, BGP (Border Gateway Protocol) can automatically handle transitive routing between spoke VNets via the hub.
5. Network Security Group (NSG) Rules: - Ensure the NSGs in each spoke allow inbound and outbound traffic to the other spoke’s subnet ranges. By following these steps, you can achieve transitive routing through the hub without direct peering between spokes, keeping your architecture more scalable and secure.
@@K21Academy Thanks. I actually figured this out a few days ago using the same methods you just described.
Hi sir i have small doubt instead of creating rdp servers can we use server which is created in firewall network. Because peering is already enabled
yes you can do it but the process would be very lengthy
May i know how internet was working prior to attaching it with firewall vnet ?
I think we need nat gateway in vnet for the same
internet is allowed by default on Azure Vms while creating
Awesome..Explanation.Really liked it.Thank you so much for these kind of stuff.
Thanks, keep watching!
Do we require NSG rule allowed for internet to achieve this
No, you do not need to configure Network Security Group (NSG) rules to allow internet access.
When VM-work does not have a public IP and the traffic is passing through Azure Firewall, it means that the access to VM-work is restricted to internal network traffic only. In this setup, VM-work is not directly accessible from the internet, and its inbound traffic is controlled by the Azure Firewall. So if you setup NSG rules then also it will not show any response to it.
Hope this helps!
Regards
Team K21Academy
Very nice content
Hey! Thanks for the feedback. Do let us know what videos you'd like to see next?
Amazing material thanks so much for sharing
Thank you for your kind words, we appreciate your support!
Hi, could you please point me to previous topics ?
Hi there you can watch these videos : ua-cam.com/video/gwFeyu_etmg/v-deo.html
ua-cam.com/video/m3QV11sDDg4/v-deo.html
hmm don't understand why you would route traffic from a different geo-region to another geo-region fw? you would said the traffic over the vNET peering to the speak to the other regions surely?
He was Deployed the HUB ( Firewall ) Subnet on a different region and all other two Spoke subnets was deployed on other two different regions. Inorder to communicate the Spoke Subnets to Firewall subnets we have to enable the Regional VNET Peering , then only Spoke Subnets on Different regions can communicate with Firewall Subnets. In Azure , Azure Firewall Deployment Under each VNETS is not a logical solution as it is bit Costly. That is the reason why he was created a Single firewall under firewall Subnet on Different region and routed all the Spoke Subnet Traffic towards to Firewall Subnet and attached the Spoke subnets on Routing tables. Which means any traffic that is originating from the Spokes subnet to any destinations will be routed to Azure Firewall and based on the Firewall rules ( Network/Application rules) the services will be allow/deny by firewall.
@@praveenkumarp1357 Azure VPN gateway is the major Trap, when you start creating your network and depending to it you need the VPN gateway as the core, and you realize later on the cost it incur that your whole mesh network is dependent to it you cannot just turn it off. that is why others are switching to SDNetworking, trashing the azure vpn gateway out of the scene. I maybe wrong about this, I would be happy someone could shed some light into this.
Thanks for your knowledge
Thanks, keep watching!
Thanks, keep watching!
I see, you created two VM's with public IP's for each vnet. I think one VM with public IP is enough.. You can take any one work(spoke) machine using RDP from public IP machine. from that work(spoke) machine the second work machine can be taken for RDP.. just cost saving for public IP..
Another options is to enable bastion- can be in production environment (mid to big size)..
Please comment on your views..
We are using the hub as a firewall. This Firewall is common for 2 machines that are acting as 2 work machines in different machines. So if we are connecting one with public IP to other with private, then only one will be working at a time either. then there is no use of creating 2 separate work machines.
Valuable content 👏👏
Thank you, keep watching!
very well explained
Thanks, keep watching!
Great 👍
Thank you! Cheers!
Best content 👍
Thanks for the support! We are glad you enjoyed the content.
Great thank you ❤
Hey, thanks to you too! Do let us know what videos you'd like to watch next?
@@K21Academy im looking for azure application gateway with multiple listners and backend pool
Thanks for the suggestion. Stay tuned!
Awesome
Thanks, keep watching.
👏🤗