Azure virtual networking drops packets from a VM based firewall that does not do source NAT on public IP's

Question

I have a specific authentication/authorization requirement, which requires the public IP of the client to not be source NAT'd on a VM based firewall, the real client IP must be unchanged until it hits the reverse proxy VM behind it. See picture. This setup works on-prem (because we have layer2 ). However in the cloud I have an issue. Example:

1. Traffic arrives on the left firewall
2. The firewall DNAT's the destination IP to the IP of the left reverse proxy. It does not source NAT
3. tcpdump on the FW shows that traffic is send out on the right interface with the correct source IP (the original client IP) and destination IP (the DNAT'ed one). However tcpdump on the RPX shows NO traffic arriving

Observations and notes:

• Azure virtual networking is dropping the packets, perhaps to prevent IP spoofing, as the FW is sending out packets with a different IP than it is configured with (confirmed with tcpdump on both sides of the communication)

The left RPX is configured with the left FW as a default gateway, vice versa for the right side

Packets do arrive if I turn on SNAT, but as said before we need the original source IP. X-Forwarded-For headers are not an options, as the FW is not terminating the mTLS and thus cannot add layer 7 info.

• I have the interfaces set to IP-forwarding (tried without on the RPX, didn't change the behavior).
• I tried using very specific UDR's, but it did not change the behavior .

Answer 1

Hello Sebastiaan Mangoentinojo,

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

I appreciate you explaining the complex scenario very well with including details such as the diagram, this helped!

If I understood your networking setup in Azure, the issue you are facing is related to Azure's handling of source IP addresses and its anti-spoofing mechanisms. Azure enforces strict anti-spoofing rules to prevent IP spoofing. If a VM sends traffic with a source IP that doesn't match its own IP (or a range explicitly allowed), Azure drops the packets. Your firewall is performing DNAT (changing the destination IP to the reverse proxy's IP) but not SNAT (preserving the original client IP). This causes Azure to drop the packets because the source IP doesn't match the firewall's IP. Even with IP forwarding enabled on the VMs, Azure's underlying network fabric will still enforce anti-spoofing rules.

You may try few ways to resolve the issue, please also explore documentation to understand best suitable option:

1. Use Azure Load Balancer with Direct Server Return (DSR), Azure Load Balancer can be configured to preserve the client's source IP by using DSR mode (also known as Floating IP). However, this works for TCP/UDP traffic but may not support all advanced firewall features.Useful link to refer - https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-floating-ip
2. Use Azure Application Gateway is a layer 7 load balancer that can preserve the client's original IP address using the X-Forwarded-For header. However, this requires the reverse proxies to support and trust the X-Forwarded-For header. Useful link - https://learn.microsoft.com/en-us/azure/application-gateway/application-gateway-faq#how-do-i-preserve-the-client-ip-address
3. Use Azure Route Server with BGP If you're using NVAs, you can leverage Azure Route Server to advertise routes and bypass Azure's default anti-spoofing rules. However, this may require advanced networking knowledge and BGP configuration. Useful link - https://learn.microsoft.com/en-us/azure/route-server/quickstart-create-route-server-portal

Given your requirements, the Azure Load Balancer with DSR (Floating IP) or Azure Application Gateway are the most straightforward solutions. If these don't meet your needs, consider using an NVA with source IP preservation or Azure Route Server with BGP. Also, before deploying any solution in production, thoroughly test it in a non-production environment to avoid any disruption.

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.