Not for me 😊, plz try again or with a diff phone or account

Not really, routing thru Firewall in this case was done to allow traffic via hub vnet, there are many cases where you have direct vnet peering between spokes vnet and traffic do not go via hub or firewall, To answer ur question: if you want communication between two spoke via hub firewall, u wud need route table. if you don't want to connect to spoke vnet and make it isolated or only connected to hub then u don't create routes to that vnet

@@techonlogic so you mean even if i have gateway connected with hub vnet and there are 3 spokes then still i will need route table attached with firewall subnet and route table routes will have the configuration which spoke will talk to which spoke. Is that understanding correct?

If Spoke vnet are peered with hub vnet and not with other spoke vnet Then for communication between spoke vnet U wud need route device, here it's azure firewall So in order to route the next hope, we need route table to be attached to the subnet of the source spoke vnet Feel free to drop ur mobile no. To my email id : [email protected] I will call n explain

Access to private endpoint happens once the traffic is allowed at Firewall and NSG. Also DNS come into picture when you are trying to access from On-prem or from laptop connected to VPN. In this case where you deny any public access and only allow Private access, you would need to allow traffic from developer IP in NSG and Firewall , to be able to reach the storage account destination. Let me know who it goes, else you can email me and we can connect if needed

@@techonlogic 1) we have found one solution that in storage account firewal we add vnet(subnet) ip range in which out vpn is confogured,so that it will allow access to our developer . 2) Through private emdpoint our application will communicate with storage account

@@sopankumbhare222 hi You can reach out to me at my email id: [email protected]

Yes, you are right Application landing zone will have a subscription with separate vnet and will have only application workload, it can be PaaS Or IaaS Similarly for platform landing zone we will have identity, connectivity and management subscription Which can be one Or different for large enterprises and is also recommended by MS

Yes we can, As per our architecture we can place them in hub vnet or spoke vnet as per our requirement

It can be used for both, public and private traffic.

For any specific vm issue It is always the agent which is at fault Try reinstalling the agent or check the version

Firewall is also there in Hub vnet I did not show it and only showed NSG Also firewall is extra cost for every rule and execution NSG are free and can work at individual subnet That means the traffic did not even left spoke vnet to reach hub firewall n is blocked at subnet or at nic level itself

​@@techonlogic You have used several NSGs, which is hassled to manage. On the other hand, you have to use unique public IPs in every VM for RDP instead you have used Firewall DNAT rules to translate the single Firewall Public IPs to all VMs.

@@godharan3510 Public ip to Vm’s are never advised. For any paas service we usually have waf For public facing vm it usually has to be either behind app gateway or a front door which will have its own firewall and will not use Azure Firewall. In cases were we are keeping vm behind firewalls and using firewall Nat as you said , that is also an option which we can design and implement. But again that is the decision taken by the architect with the he app owner for specific requirements