I'm currently working with an Azure Data Lake Storage Gen2 account that has SFTP enabled. We've configured public networking to allow only specific whitelisted IPs. We have a private endpoint set up for our virtual machines and other resources within our own private network. The vendor gave us an IP address that we whitelisted, but their SFTP connection attempts are failing. The logs indicate that the incoming connection is from a private RFC1918 IP, which doesn't belong to us and isn't within our address space. The actual IP they connect from is within Azure, tied to their own subscription's network. Can anyone explain how this is happening?
4 Answers
Make sure you're looking into the service endpoint settings as well. They could be playing a role in this scenario.
Have you checked the route tables? They might be using a private NIC from a VM that's affecting the connection.
You could try a traceroute to that IP address. It might help you identify the path the connection is taking. Checking the route tables along the way could also reveal some insights.
It sounds like they might be connecting from a virtual network (vNet) in the same Azure region as your storage account, and they have their service endpoint for storage enabled. Azure can handle networking in some confusing ways, so it's definitely a possibility!
This explanation makes a lot of sense! I've faced similar issues only within our own subscription. Are there additional things we should keep an eye on when dealing with SFTP connections in Azure?
Exactly! I encountered this same issue before. I had to redeploy the storage account to a different region because I couldn't modify the vendor's setup. It's important to note that it can't be the paired region either.