Please add the ability to protect against inbound traffic from the public internet in addition to its present ability to protect outbound traffic. If this is going to be offered as a true SaaS 'Firewall' solution, I believe this should have that true firewall protection for incoming traffic (protection against common attacks, layer 7 packet inspection, etc.)
Jim Keane (Admin) commented
I'm failing to see the cost benefit of this solution. The lack of source ip forwarding from the public side to private side, the connectivity issues outbound to azure services (specifically sql) and the cost is ludicrous. $900/mo for a firewall that lacks basic features is not acceptable.
Oh, and getting support on Azure Firewall is abysmal. I'm going day four of a Sev B with very little engagement from Microsoft.
Can we setup the OMS work space to capture the DNAT logs of Azure Firewall
Dillon Brown commented
Is this item complete now? There is a tutorial about "filtering" inbound traffic but it talks about DNAT and both the network and application rules seem to only be offered in the outbound direction.
Gus Parker commented
I am in the process of moving our ADFS/WAP servers from on-premises and into Azure, and I have setup a basic proof of concept using an external load balancer behind which the WAP servers sit on a dedicated subnet. NSGs filter traffic between the external load balancer/WAP and in turn ADFS farm (which sits on another dedicated subnet). All works ok, but our security team are insisting on me placing a firewall (with log reporting into QRadar) between the perimeter and the WAP servers. I have set up another POC replacing the WAP external load balancer with an ILB, and Azure firewall and DNAT to the private address of the ILB. Not managed to integrate logs with Qradar as yet, but have noticed that the logs I can see in Azure are only showing the allowed traffic (whereas previously with the NSG only setup I could see all traffic). Similar to the previous post, is this likely to be resolved, or am I missing something more fundamental?
Yair Tor commented
We will be adding inbound support for GA. The only missing part for enabling this is DNAT configuration. Once a destination is translated from a public ip and port to a private ip and port, the rest of the processing will proceed as done today.
Regarding Azure Firewall and NSG - https://docs.microsoft.com/en-us/azure/firewall/firewall-faq
FQDN filtering for additional protocols is on our roadmap for post GA.
Co-existence with ER Gateway - this bug should now be resolved. Please let us know if you still experience this issue.
I'm really struggling to find enough differentiation between the Azure NSGs and Azure Firewall. Fully agree with the OP that these features need to be added to make this the product we need. I'd much prefer a native PaaS/SaaS solution than needing to go with an appliance or other VM-style approach as it simply takes away from the benefits of the overall model.
Rich Davies commented
Application rules appear to be limited to http and https in terms of outbound protocols. What plans are there to allow additional protocols (e.g. SFTP, RDP, SSH)
Azure Firewall currently breaks ability to add new VNET peers to your Hub network if you also have an ExpressRoute Gateway provisioned. They add, but BGP no longer picks up and propagates any new VNET peer ranges whilst Azure Firewall is provisioned...