Asymmetric Routing Issue in SDN with Shared Public IP Between Load Balancer and Firewall NAT

Dimitrov, Todor 0 Reputation points
2026-06-09T09:33:14.6933333+00:00

Hi Everyone,

The public IP is currently assigned to the front-end load balancer. Incoming traffic from the internet first reaches the load balancer and is then forwarded through the firewall, where a DNAT rule translates it to the internal server at 172.24.x.x. This setup is working correctly for inbound traffic.

Now I’m trying to use the same public IP for outbound traffic from the internal server. On the firewall, I configure SNAT so that outgoing connections from 172.24.x.x are translated to that public IP.

However, I am not seeing return traffic from the destination side. I only observe outgoing packets (requests leaving the internal server), but no responses coming back.

I suspect the issue might be related to routing or NAT ownership of the public IP. Since the public IP is owned by the load balancer, return traffic from the internet could be going back to the load balancer instead of passing through the firewall where the NAT state exists. This could lead to asymmetric routing or dropped sessions because the return path does not match the original connection tracking state.

Azure Load Balancer
Azure Load Balancer

An Azure service that delivers high availability and network performance to applications.

2 answers

Sort by: Oldest
Most helpful Newest Oldest

  1. AI answer

    2026-06-09T09:33:47.0733333+00:00

    The behavior matches an asymmetric routing problem: the public IP is owned by the load balancer, but SNAT state for outbound connections is on the firewall. Return traffic is hitting the load balancer instead of the firewall, so the firewall never sees the response packets and the sessions fail.

    In Azure, this is a known issue when a public load balancer and Azure Firewall share the same public IP or when the default route sends traffic back through the firewall’s private IP while inbound traffic arrives via a different path.

    To fix it, the public IP used for inbound and outbound must have a consistent path so that both directions traverse the same stateful device:

    1. Ensure the firewall is the true owner of the public IP for the flows where it performs SNAT.
      • In the documented pattern, internet traffic first lands on the firewall’s public IP, then the firewall DNATs to the load balancer’s frontend IP. The firewall also performs SNAT for outbound flows, so both directions go through the firewall.
    2. If using a public load balancer in front of the firewall, avoid routing return traffic through the firewall’s private IP when the initial packet did not traverse that same path.
      • As described, asymmetric routing occurs when a subnet has a default route to the firewall’s private IP, but inbound traffic arrives via a public load balancer frontend. The firewall is stateful and drops returning packets that don’t match an existing session.
    3. Use the documented workaround for public load balancer + firewall:
      • Add a specific route so that traffic destined to the firewall’s public IP goes directly to the internet, bypassing the default route to the firewall’s private IP. This prevents asymmetric routing when integrating Azure Firewall with a public load balancer.
    4. If a NAT Gateway is involved, ensure routes and NSGs are aligned with the NAT Gateway’s public IP, not the firewall’s public IP, because the NAT Gateway’s public IP takes precedence over the firewall’s public IP.
      • In that case, configure a route so the return path uses the NAT Gateway public IP as next hop “Internet” and allow that IP in NSGs.

    In summary, the same public IP cannot safely be “owned” by both the load balancer and the firewall for the same flows. Either:

    • Terminate inbound on the firewall’s public IP and then forward to the load balancer, letting the firewall handle both DNAT and SNAT, or
    • Keep the load balancer as the public entry point and avoid using that same IP for firewall SNAT, ensuring that outbound and inbound paths are symmetric through whichever device holds the NAT state.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

  2. Thanmayi Godithi 11,825 Reputation points Microsoft External Staff Moderator
    2026-06-10T16:17:45.56+00:00

    Hey Dimitrov, Todor! From what you’ve described, this looks very consistent with an asymmetric routing / stateful-NAT ownership problem.

    Azure Load Balancer maintains connection state and ensures return traffic flows back through the load balancer for flows involving the load balancer. But when you try to reuse the same public IP for firewall SNAT outbound, the return path can end up not matching the original flow path/state (especially if routing to the “public IP” is still tied to the load balancer as the effective next hop).

    So your suspicion is on the right track: return traffic could be going back to the load balancer instead of passing through the firewall where the SNAT state exists, causing the firewall to drop/don’t have the expected session context.

    What to try / recommendations (from the provided docs)

    1. Make sure traffic symmetry is preserved (especially for stateful firewall behavior). Avoid designs where:
      • inbound uses one path (LB → firewall → DNAT), but
      • return uses another path that bypasses the firewall/NAT state.
    2. Don’t rely on “shared public IP ownership” between LB and firewall for outbound unless the routing is explicitly aligned for return.
      • The docs for integrating Azure Firewall with a public load balancer call out asymmetric routing scenarios where return goes via a different hop and a stateful firewall drops the packet.
    3. Use a routing workaround by adding a specific route for the firewall public IP (if you’re in the “firewall with public IP + public load balancer” style of pattern).
      • The firewall/LB integration guidance explains that asymmetric routing can occur due to default routes sending return through the firewall’s private IP; the fix is to add a specific route for the firewall’s public IP so return goes the correct way.
    4. If you’re using a NAT Gateway on the firewall subnet, ensure routing precedence and NSG allowance:
      • The “Integrate Azure Firewall with Azure Standard Load Balancer” doc notes that when NAT Gateway is associated, it can take precedence over firewall public IP behavior, and you may need an appropriate route for the return path using the NAT Gateway public IP, plus allow it in NSG rules.
    5. Validate return path behavior with packet capture / effective routes
      • For NVA-style troubleshooting, Microsoft guidance recommends packet capture comparisons on the “trusted” side vs “untrusted” side and checking effective routes on the return path systems.

    Kindly let us know if the above helps or you need further assistance on this issue.

    If the answer is helpful, kindly upvote it. If you have extra questions about this answer, please click "Comment".

    Was this answer helpful?

    1 person found this answer helpful.

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.