💼 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/3XchMEA
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
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
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.
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.
Hi there you can watch these videos : ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-gwFeyu_etmg.html ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-m3QV11sDDg4.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.
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
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.
