Forum Discussion
IP-based redirection
Hello! I am running a Linux VM on Azure (IaaS) which is providing an SFTP service to the Internet. Sadly, many customers are connecting to this service via public IP address (as opposed to FQDN)....
Azure Firewall with DNAT (Destination Network Address Translation)
Azure Firewall can provide the NAT functionality you're looking for. You can configure Destination NAT (DNAT) to redirect incoming traffic from 1.1.1.1 to the on-premises firewall (2.2.2.2). Additionally, you can configure SNAT (Source Network Address Translation) to ensure that the traffic appears to come from either 1.1.1.1 or another public IP (e.g., 3.3.3.3).
Steps to Set Up with Azure Firewall:
- Set Up the Azure Firewall:
- Create an Azure Firewall instance if you don't have one already. Ensure the firewall is deployed in a Virtual Network (VNet) with a public IP address.
- Configure DNAT:
- Set up a DNAT rule in the Azure Firewall to forward incoming SFTP traffic (on port 22, for example) from 1.1.1.1 to 2.2.2.2 (your on-premises firewall).
- This rule will look like:
- Inbound Source IP: Any (or specific client IPs if you want to limit traffic)
- Destination IP: 1.1.1.1 (the public IP on Azure VM)
- Translation IP: 2.2.2.2 (your on-premises firewall)
- Configure SNAT (optional for source IP redirection):
- If you need the response to go back from 1.1.1.1 or another public IP (e.g., 3.3.3.3), you can configure an SNAT rule in Azure Firewall to translate the source IP of the outgoing traffic.
- Azure Firewall can automatically handle SNAT for internal traffic; however, you can also manually define a specific public IP for SNAT if needed.
- Route Traffic via Azure Firewall:
- Ensure that the traffic from the Linux VM is routed through the Azure Firewall. You can achieve this by adjusting your User Defined Routes (UDR) on the VNet.
- Add a UDR that forces traffic from the Azure VM's subnet to be routed through the Azure Firewall for NAT.
- Test the Setup:
- Verify that when customers connect to 1.1.1.1, the traffic gets properly redirected to 2.2.2.2 (your on-premises firewall). You can test this by performing an SFTP connection from an external client.
Azure Load Balancer with NAT Rules
Another approach could be using Azure Load Balancer, but it’s typically more common for distributing traffic across multiple backend VMs rather than redirecting to external resources. However, if you just need the IP translation functionality, you could configure a Standard Load Balancer to redirect traffic from the public IP (1.1.1.1) to your firewall (2.2.2.2).
Steps with Load Balancer:
- Create an Azure Standard Load Balancer.
- Set up Inbound NAT rules to forward traffic from the public IP (1.1.1.1) to the on-premises firewall (2.2.2.2).
- Use a Frontend IP configuration with the public IP address (1.1.1.1).
- Configure Backend pool to point to your on-premises firewall IP (2.2.2.2).
- Optionally, configure Health probes if required.
This method is less flexible in terms of SNAT control but can work if you just need simple forwarding.
Conclusion:
For more advanced and flexible redirection (especially with SNAT functionality), Azure Firewall is your best bet. It can handle both DNAT (for destination IP translation) and SNAT (for source IP translation), allowing you to set up the IP-based redirection and control over how the traffic is managed.
By using Azure Firewall, you can ensure that traffic from the public IP (1.1.1.1) is redirected to the on-premises firewall (2.2.2.2) while maintaining control over the source IP, either using 1.1.1.1 or another public IP (3.3.3.3) as required.
