Having issue connecting to SFTP server from Public IP Address

Question

I have a windows server 2022 which is running SFTP on port 22. I can connect to that server using its own IP address internally using VPN.

But when I use the Public IP address I can not. Below is how that is configured.

MS Azure--->NSG----->Firewall(Public IP)----Rule (Policy External to Internal)--->SNAT Rule (Allow to route traffic)----> Server network.

When I do the tracert to my local Firewall IP which has one physical interface and that is configured to use 2 Public IP address which is assocaitaed to 2 Loacal network.

When I do the tracert to that local netwrok to the Firewall.

Result

Working one FTP on below trace

tracert 15.2.2.10

Tracing route to 15.2.2.10 over a maximum of 30 hops

1 <1 ms * 1 ms 15.2.0.5

2 1 ms 1 ms 1 ms 15.2.2.10

2nd trace (Not working)

tracert 15.2.2.11

Tracing route to 15.2.2.11 over a maximum of 30 hops

1 1 ms 1 ms 1 ms 15.2.2.11

Any suggestion. All traffic is working as it should be and the Port etc are open on the server / MS Azure Firewall

Answer 1

I have some recommend steps for you to check it:

*Check on SNAT/DNAT Mapping for 15.2.2.11

• Is 15.2.2.11 properly mapped (NATed) to your Windows Server?
  • Check if your Firewall Policy (DNAT) maps 15.2.2.11:22 → Internal IP:22.
  • Compare it exactly with the working one (15.2.2.10).
• Is there a corresponding return SNAT rule to allow traffic back to the client?

*Next you need to do a tcpdump or Wireshark on the Windows Server:

• Do you see SYN packets coming from the public IP?
  • If no: NAT might be misconfigured.
  • If yes, and there's no response: something's blocking replies (like Windows Firewall).

*Next you should also check on Azure NSG & Firewall Policy too

• Confirm that both public IPs are allowed through:
  • NSG rule allowing port 22 inbound for both IPs.
  • Azure Firewall rule forwarding 15.2.2.11:22 to the same internal server (or another).
• Use Azure Network Watcher > IP Flow Verify to simulate connectivity and confirm allow/deny for 15.2.2.11.

*Also Windows Server Firewall is important to check too

Even if Azure allows the traffic, the Windows Server itself might block traffic if:

It's bound only to a specific NIC/IP.

Or has a scoped firewall rule allowing only certain source IP ranges.

You can have a quick test bellow:

• Disable Windows Defender Firewall temporarily and test again.
• Or use:

Get-NetFirewallRule | Where-Object {$_.Direction -eq 'Inbound' -and $_.Enabled -eq 'True'} | Format-Table Name, DisplayName, Action

*You also can try to bind to a Specific IP or Interface

Ensure the SFTP (OpenSSH or other server) is not bound only to a specific IP or adapter.

Use:

netstat -an | findstr :22

Ensure it says 0.0.0.0:22 (listening on all interfaces), not just the private/internal IP.

*Sometimes the root cause is from Asymmetrical Routing

• If you see:
  • Traffic reaches the Windows server (based on sniffing),
  • But response never gets back, it may be due to:
    • Azure returning traffic via a different route.
    • No SNAT on return traffic → Windows replies directly to public IP → Azure drops it.

So you can fix it by :

• Use SNAT so return traffic always goes back via Azure Firewall.

If all of those step above can't help. This is some backup plants to try next

Check NAT rules: Compare both 15.2.2.10 and 15.2.2.11 rules in firewall. Are they identical?

Packet capture on the server: Look for incoming SYN packets to port 22.

Check Windows Firewall: Is port 22 allowed from all networks?

Check SFTP is listening on all IPs: netstat -an → 0.0.0.0:22

Try connect with Telnet or Nmap:

telnet 15.2.2.11 22
nmap -p 22 15.2.2.11