So basically, right now we have a fully public facing Web server inside the local network and is a member of the domain. We're going to be migrating this to azure. I have recommended that the server be in it's own azure VNET, not connected to the domain.

My intentions here we're that no link would exists between us and the Azure IIS Server, other than our ability to upload files to the Azure File storage and RDP into the server.

However, I am having issues with uploading files to the Azure File storage (as our ISP blocks port 445 outgoing.)

Everyone around here keeps talking about a VPN to our azure VNet would resolve the issue. To me this basically means that our Azure VNet would then be a member of the network and we're in the same boat we are now. Is my assumption correct?

  • Even if you have a VPN, you could still implement a firewall between your network and the Azure network. But it would be a firewall under your control, so you could permit port 445 to pass through it. Dec 21, 2016 at 20:42

2 Answers 2


VPN does not mean that the Azure VNet is on your network. It means you have a Virtual Private connection to the Azure VNet.

Whatever you can apply whatever Router policies you would normally be able to apply to a subnet as you can on a site-to-site VPN.

User @Xander makes a good point that you could simply create a Point to Point Protocol VPN and that would be simple. However, for anything bigger than the smallest of DevOps teams, this would not scale very well. You would need to be giving infrastructure to the developers.

Administration would be a nightmare, how would you control access to the Azure VNet, especially when a developer leaves the company?

My advice would be to connect the Azure VNet to your Gateway Router using a Site-to-Site VPN solution, such as IPSEC/IKE. Then I would put up firewall policies to only allow TCP Establish/Related to go from the Azure VNet to your internal network.

This setup effectively makes the Azure VNet your DMZ.


Azure supports different kinds of VPN connectivity. You can set up not only a site-to-site VPN, which is what I suspect is what you're currently thinking that will create a network-level link between your corporate network and Azure, allowing you to securely route traffic to Azure without having to worry about your ISPs policies, but you can also set up a point-to-point VPN connection, which sounds like it may be all you need given your stated requirements. In this configuration, the machine or machines(s) that are going to be pushing new files to Azure would have the VPN client and could set up and tear down tunnels directly, and only as they need them to push updates or manage the Azure environment. This way you don't need to have a persistent network level route to the Azure infrastructure that could be used for traffic outside of what you intend and believe you need.

There are other ways that you could set up your network to limit the capability to access the Azure resources, but a point-to-point VPN is likely the simplest and easiest to manage.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .