Azure Firewall - DNAT Rules

Question

Azure Firewall - DNAT Rules

Jeffrey Lucal 1

Azure Firewall "Basic" Tier with a DNAT "443" rule from Public IP to Private Network IP on IaaS machine (All in Azure). Is there anyway to expose the "Source" IP Addresses connecting to the IaaS machine? All traffic flows fine and no problems accessing the server, but all incoming traffic is NAT/SNAT from the Firewall Subnet and not showing the external IP connections. We can parse logs from the firewall but wanted to know if there was a way to allow the source IP information for direct connectivity issues with a web server.

2 answers

Your answer

Answer 1

Antonio Valenzuela 20

Hello, I'm asking about the same thing.

I use a DNAT SMTP TCP 25 and the mail server sees the source IP of the private segment of the firewall VNet.

Client 139.99.134.X --> FW 20.197.194.X & 10.2.1.X --> Mail Server 172.16.0.X

Source IP 10.2.1.X (SPF Failed)

I know perfectly well that I can associate a public IP in the VM network, but I would like to know if the origin can be maintained through the firewall.

Antonio Valenzuela 20 Reputation points

2023-12-12T12:36:37.1266667+00:00

@ChaitanyaNaykodi-MSFT ?

Answer 2

ChaitanyaNaykodi-MSFT 27,661 Microsoft Employee Moderator

@Jeffrey Lucal

Thank you for reaching out on the Microsoft Q&A forum.

If I understand correctly, on Azure Firewall due to SNAT the incoming traffic does not contain the original source IP address of the request and you want to know if there is a way to send source IP information to the backend web server.

I think this can be done by deploying an Azure Application Gateway before the Firewall. This design is appropriate for applications that need to know incoming client source IP addresses, for example to serve geolocation-specific content or for logging. Application Gateway in front of Azure Firewall captures the incoming packet's source IP address in the X-forwarded-for header, so the web server can see the original IP address in this header. This is currently documented here.

Hope this helps! Please let me know if you have any additional questions. Thank you!

Please "Accept the answer" if the information helped you. This will help us and others in the community as well.

Jeffrey Lucal 1 Reputation point

2023-03-29T00:51:34.15+00:00

Deploying an Application Gateway on top of an Azure Firewall isn't optimal as it increases the cost 2X without adding any real benefits for this configuration. The big question is whether source IP can be exposed to an IaaS VM behind an Azure Firewall through a single DNAT rule?

It's basically a web server and needs to be able to identify incoming connections. The Firewall logs and the web server logs don't make it easy to troubleshoot or identify a single connection as the web server only sees the FW vnet IP addresses.
ChaitanyaNaykodi-MSFT 27,661 Reputation points Microsoft Employee Moderator

2023-03-29T15:55:39.7466667+00:00

@Jeffrey Lucal

Thank you for the response above. I understand the cost concern here.

The big question is whether source IP can be exposed to an IaaS VM behind an Azure Firewall through a single DNAT rule?

This is currently not supported by Azure Firewall. As per the documentation here forwarding the request via XFF header is being investigated. Currently this is mentioned under known issues for Firewall Standard let me just confirm with the team if this will be implemented for Firewall Basic SKU.

Just in case if it helps, by deploying an Application Gateway with WAF on top of an Azure Firewall the inbound web traffic goes through both Azure Firewall and WAF. The WAF provides protection at the web application layer.
Jeffrey Lucal 1 Reputation point

2023-03-29T20:31:35.2333333+00:00

App Gateway had problems initially with this environment which is why we ended up with Azure Firewall. Need to perform some additional research on a method to move forward.
Pedro Parra Ortega 0 Reputation points

2023-05-04T10:09:07.31+00:00

Did you find any possible solution? we are trying deploy and internal AKS cluster within a hub/spoke topology where we have a central hub vnet where the fw and central nat gateway live and we are facing the same issue. TLS termination should be done inside kubernetes so if we use a public loadbalancer we face asymetric traffic as the default route is towards the central fw/ngw, if we use the fw directly then we have the snat issue and if we add an application gateway we need to handle all the certificates in the appgw which is not an option as we handle +200 certs.

Share via

Azure Firewall - DNAT Rules

2 answers

Your answer