I have an Azure Function that needs to access an external SMB file share that is hosted on port 445. The Azure Web App sandbox that Functions run inside of explicitly blocks port 445. Assuming I have no control over the external SMB file server, what can I do to allow the Azure Function to access the SMB file share?

enter image description here

Some ideas... which ones are feasible?

  1. Setup an outgoing port-forward from a non-blocked port (say, port 555) to external port 445. Then have my Function app target the non-blocked port.
  2. Expose the file server via a "Virtual Network". According to the docs, the 445 port block rule is ignored if the target network interface belongs to the app. Can I add a 3rd party host as an interface on my app's virtual network? How?
  3. Is there a proxy service I can install and run in my Azure environment that can expose the file share on a different port?

How should I approach this problem?

  • 1
    Can you explain the end goal a bit more? Do you need to read from the external file share or write to it? There may be a different way to attack the problem. – Ken W MSFT Mar 6 at 14:14
  • @KenWMSFT I need to both read and write files on the external file share. – Kemmis Mar 6 at 15:29

There's a reason they're blocking SMB access: It's not a safe and secure protocol to expose to the Internet. Really. You might recommend the third-party to stop exposing their server to risk in that way too, if you're on good terms with them.

Suggested solutions:
1. Create a VPN to the site where the SMB server exists and access the machine through an encrypted and secure tunnel.
2. Present relevant data from the server using a different protocol.

  • To be fair to said 3rd party, I believe they already have the SMB server behind a firewall, and my office network uses that VPN. I'm not aware of how our Azure environment is currently setup, but in theory we will need to connect to that VPN from azure to expose the SMB server. If this is the case, then does that mean the SMB server will be considered a network interface that belongs to the app, and thus will not have port 445 blocked? – Kemmis Mar 5 at 18:23
  • If your using consumption-based functions then you will not be able to connect your function to your VPN, so you will not be able to access this share. – Sam Cogan Mar 5 at 22:35
  • Unfortunately I have no experience with serverless functions in Azure, so I cannot answer your question specifically. Sam Cogan's comment is a good start, though: You're probably better off having the third-party push data to your service than attempting to fetch data from them. This naturally involves writing a client for them to run on their side. – Mikael H Mar 6 at 8:58

The Azure Relay service enables you to securely expose services that run in your corporate network to the public cloud. You can do so without opening a port on your firewall, or making intrusive changes to your corporate network infrastructure.

The relay service supports the following scenarios between on-premises services and applications running in the cloud or in another on-premises environment.

  • Traditional one-way, request/response, and peer-to-peer communication
  • Event distribution at internet-scope to enable publish/subscribe scenarios
  • Bi-directional and unbuffered socket communication across network boundaries.

Azure Relay differs from network-level integration technologies such as VPN. An Azure relay can be scoped to a single application endpoint on a single machine. The VPN technology is far more intrusive, as it relies on altering the network environment.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.