1

The organisation I work for is trying to move away from hosting our own VMs and move them all into the cloud, namely into Azure. Its all new to us, and so the first item I'm trying to tackle is setting up a VM which hosts the license server for an automation application we use.

Creating a Windows VM in the Azure resource manager was easy. And with the license server installed on that VM, I find that it can serve licenses to the automation application instances on the other Azure VMs I've created.

The problem though:

We can only have one license server current, so this license server in the cloud, still needs to service the automation applications we run on our local machines.

The license server just needs the TCP/UDP port 7266 open, so I've made sure that port is open on the Windows instance, as well as gone into the Azure NSG to ensure that an inbound and outbound rules have been added to allow that port.

My understanding is that for the new Azure VMs in the resource manager (i.e. not classic) don't need endpoints. I've added the public IP in Azure with a DNS name, and that resolves from our network to match the public IP of the targeted Azure VM.

But regardless of whether I use the DNS or the specific IP address, our machines consistently get:

ERROR: No connection could be made because the target machine actively refused it [::ffff:40.115.76.87]:7266

I'm hoping someone is familiar enough to assist me in how to configure an Azure VM to make a service publicly accessible from outside Azure.

The Azure forums haven't offered any new options for me to try other that the inbound rules. I'm guessing i'm missing something simple?

Jason K
  • 13
  • 3
  • Is the license server running? See http://serverfault.com/q/725262/126632 – Michael Hampton Nov 23 '16 at 07:59
  • Additionally, is the license service configured to answer public requests? most of these services come preconfigured for private communications only. Also, would be a best practice to connect both data centers through VPN instead of making requests using the internet. – Bruno Faria Nov 23 '16 at 13:42
  • @MichaelHampton, I've made sure the license server is running and it is accessible by other Azure VMs that we have in that resource group. – Jason K Nov 24 '16 at 06:16
  • @BrunoFaria, yes the license server should respond to port pings. Based on your suggestion and Steven Lee's, I'll look into a VPN connection. – Jason K Nov 24 '16 at 06:16

1 Answers1

0

To verify if a port is reachable from client side, we can use a tool called PortQuery. It's a GUI based tool which is easy to use. If you are using Linux, please use the nmap to check if the port is reachable from the client.

If the port is unreachable, then please check the following details:

  1. Is the outbound traffic blocked by on-premises firewall?

  2. Does the NSG has been configured properly? Note: NSG can be associated with both of NIC and Subnet. Please check if both of them has been configured properly.

  3. Is the local firewall of the VM has been configured properly to allow the access from internet?

If the port is reachable, it means that the configuration of network is correct. And we should troubleshoot this issue on application-level.

BTW, I totally agree with @BrunoFaria that the licensing server should not be exposed to internet if it is not designed for that. You need to establish a site-to-site VPN between the Azure and your on-premises network, so that your local clients can reach the licensing server by its' private IP.

Steven Lee - MSFT
  • 713
  • 4
  • 8
  • Thank you for the feedback. We did discover that our corporate firewall was blocking that port, so that was adjusted, unfortunately the problem persisted. So I'm still looking through the configuration to try to trace causes. The firewalls on the Azure VM and the NSG have all been checked to make sure that a rule is present for the required port. It sounds like the VPN though is probably the better solution in the long term. I'll try to look into that. – Jason K Nov 24 '16 at 05:24
  • @JasonK Is the port reachable after allowing the port in your corporate firewall? If yes, then as I have mentioned above, this is not a network issue. If no and you have double checked the details above, then performing a network capture on the Azure VM will help to narrow down this issue. – Steven Lee - MSFT Nov 24 '16 at 05:56
  • @JasonK S2S VPN is recommended. The VMs on the Azure and local clients in the corpnet can communicate with each other without port forwarding or any network address translation technology. Also, the communication is encrypted which makes the communication more secure. – Steven Lee - MSFT Nov 24 '16 at 06:01
  • After much bouncing off walls it turned out to require the port to be opened in "the other corporate firewall". So the configuration to connect with an Azure VM is as easy as it seems, it was just complicated by the fact that the IT group who maintains the specific subnet I was on, is not the group I expected (don't ask). That's all irrelevant anyways, basically it was just corporate firewall blocking that port. That's now resolved an I'm all good. I'll still look up the VPN for security though. – Jason K Nov 24 '16 at 06:19