Why does Azure Firewall DNAT rules does not allow creating a rule without port translation?

Question

I am working on an application architecture which requires 150 Public IPs in Azure firewall to support 150 enterprise customers. Each customer will be assigned with Its own Public IP on Azure firewall to access the application. Traffic will be allowed on multiple port (around 15 ports) for all the 150 Public IPs.

When setting up DNAT rules, it appears that a separate rule is required for each port, making port translation mandatory. My goal is to perform only IP translation—NATing a large range of ports without modifying them. The "Destination Ports" and "Translated Port" fields cannot be set to a wildcard, a matching range, or left blank. This makes it necessary to create thousands of rules to support 150 customers, which is not possible with a single firewall as Azure firewall only supports 250 DNAT rules + Public IPs at max.

How can I solve this problem without creating multiple firewalls?

Answer 1

Hello Rahul Bhatia,

Thanks for posting your question in the Microsoft Q&A forum.

When designing an application architecture in Microsoft Azure that requires 150 public IPs and supports traffic on multiple ports for each IP, you may encounter limitations with Azure Firewall's DNAT (Destination Network Address Translation) rules. Azure Firewall supports a maximum of 250 DNAT rules, which makes it challenging to accommodate 150 customers, each requiring a unique public IP and multiple ports.

Azure Firewall is a robust, cloud-native network security service that provides stateful firewall capabilities, including DNAT rules for inbound traffic. However, DNAT rules in Azure Firewall require explicit port mappings, meaning you cannot use wildcards or ranges for ports. This limitation necessitates creating a separate DNAT rule for each port, leading to thousands of rules for 150 customers and 15 ports each. Since Azure Firewall supports only 250 DNAT rules, this approach is not feasible.

To overcome this limitation, we must explore alternative solutions that allow IP translation without requiring port modification while staying within Azure's service constraints. There are few other ways to achieve this:

Solution 1: Leveraging Azure Load Balancer for IP Translation - Azure Load Balancer operates at Layer 4 (Transport Layer) and can distribute incoming traffic across backend resources. Unlike Azure Firewall, Load Balancer does not require explicit port mappings for NAT. You can assign a unique public IP to each customer and configure the Load Balancer to forward traffic to your application without modifying the destination ports. Useful link to refer - https://learn.microsoft.com/en-us/azure/load-balancer/tutorial-load-balancer-port-forwarding-portal

Solution 2: Using Azure Application Gateway for HTTP/HTTPS Traffic - If your application is HTTP/HTTPS-based, Azure Application Gateway can be a powerful alternative. Application Gateway operates at Layer 7 (Application Layer) and supports advanced routing based on host headers, URL paths, and other HTTP attributes. It can also handle multiple public IPs, making it ideal for scenarios where each customer requires a unique public IP. Useful link to refer - https://learn.microsoft.com/en-us/azure/application-gateway/multiple-site-overview

Solution 3: Deploying Multiple Azure Firewalls - If Azure Firewall is a strict requirement, you can deploy multiple Azure Firewallsto distribute the load of DNAT rules. Each firewall can handle a subset of customers and their associated public IPs. For example, you could deploy three firewalls, each managing 50 customers and their respective ports. Useful link to refer - https://learn.microsoft.com/en-us/azure/route-server/overview

Please, let me know the response helps answer your question? If the above answer helped, please do not forget to "Accept Answer" as this may help other community members to refer the info if facing a similar issue. 🙂