MicrosoftHoping I'm not too late to the party!
Just after some clarification on SNAT behaviour as I've read conflicting information on the web.
We have an SFTP server with IP restrictions on folders, restricting folder access to the Public IP addresses of the 3rd parties that connect to them (an additional restriction to username/password etc).
The flow currently goes as follows - Public DNS sftp.company.co.uk port 22 his a traffic manager > Sends to public IP address of a Virtual Cisco Firepower hosted in Azure > DNAT translates public IP of Virtual Cisco Firepower to Private IP of a server in Azure that hosts our SFTP Gateway Service > If public IP matches folder and username & password correct it then gets through to the actual SFTP server.
We're looking to replace the Virtual Cisco Firepower with Azure Firewall, so the flow would be as follows;
Public DNS sftp.company.co.uk port 22 his a traffic manager > Sends to public IP address of Azure Firewall > DNAT rule translates public IP of Azure Firewall to Private IP of a server in Azure that hosts our SFTP Gateway Service > If public IP matches folder and username & password correct it then gets through to the actual SFTP server.
The DNAT rule on the Azure firewall works correctly as traffic's hitting our SFTP Gateway, however i can see in logs it's failing because SNAT is applying and changing the source to one of the private IP's in our AzureFirewallSubnet, not the original 3rd party public IP so folder access on the SFTP Server is being denied
The original destination is a public IP, however after DNAT it's in the private range, but SNAT is still applying, which is contradictory to what the documentation says, is this expected behaviour, if so any recommendations on how i can preserve the original Public IP address all the way through to the SFTP Gateway? It feels like SNAT is applying before DNAT because the original dest is a public IP.
Would be very appreciative of any thoughts
Sam
