Disable source NAT on incoming sessions on Azure Firewall
As far as I can tell, source NAT is applied to all incoming sessions crossing a destination nat-rule on the Azure Firewall.
It would be great if there was an option for this implicit source NAT to be disabled. Doing so would allow internal Azure VMs to see the real public IP address of the system making the incoming connection.
The Azure Firewall deployment docs state that a default route should be set on the host's subnets pointing to the Azure Firewall - so source NAT should not be necessary for (public) Internet IP addresses to be routed successfully within the network.
valid suggestion subject to upvote
Ivan Dichev commented
No documentation whatsoever that this is a default behavior on Azure Firewall for inbound traffic!
Tested it today and seems there is no change.
Thomas - are you suggesting that you think this is now implemented? If so, would like to know how to configure it! :)
Thomas McConnell commented
you really need to work on updating the tags on these properly as there's this very feature in the firewall policy but I couldn't tell you if it's new
Any update on this ?
Boudewijn Plomp commented
Please don't disable it entirely; but allow it to be configured per NAT rule.
I opened a ticket asking questions about this and support couldnt even answer questions about Source NAT, they sent it to the Field Engineers and wanted to charge me even to verify that it is in fact happening. This should at least be documented somewhere!!
There appears to be no logging detail of this action. As it stands today there is no way to correlate the private IP from the AZFW that shows in server logs to the external IP that was NAT'd.
SNAT on incoming connections is done do ensure symmetric routing across the underlying firewall nodes for returning packets. This is needed as the Standard Load Balancer has TCP state checking rules today that will drop the session if the returning packet comes from a different firewall physical node. This will be fixed in the future, but no ETA yet.