0

I have an Azure subscription with 2 different resource groups, Test and Prod. Each resource group has a VNET with a bunch of VMs in it.

There is a VM in Prod that acts as a license server, and services in both Test and Prod need to be able to access it. Let's call it LICENSE-VM.

+------------------------------+            +-------------------------------------+
|     Test Resource Group      |            |          Prod Resource Group        |
|                              |            |                                     |
|   +----------------------+   |            |   +-----------------------------+   |
|   |       Test VNET      |   |            |   |          Prod VNET          |   |
|   |                      |   |            |   |                             |   |
|   |   +----+    +----+   |   |            |   |   +----------+    +----+    |   |
|   |   |VM-1|    |VM-2|   +----------------------> |LICENSE-VM| <--+VM-3|    |   |
|   |   +----+    +----+   |   |            |   |   +----------+    +----+    |   |
|   |                      |   |            |   |                             |   |
|   +----------------------+   |            |   +-----------------------------+   |
|                              |            |                                     |
+------------------------------+            +-------------------------------------+

Of course, this isn't an issue within the Prod VNET, but I'm struggling to find a secure way of allowing communication with LICENSE-VM from Test.

  1. I thought of adding a public IP to LICENSE-VM, and using an NSG (Network Security Group) attached to the NIC to lock it down - but if I use a source IP rule that specifies the CIDR range of the TEST VNET, it doesn't work (can't connect)
  2. I then thought of adding a public load balancer, but this seems to have the same problem as (1), in that I can't lock it down to a VNET in a diferent resource group
  3. We could setup VNET peering, but it seems overkill when we only want access to a single port on a single VM. I'm also unsure if we could lock that down using Network Security Groups?

Any idea how I can lock down a public IP such that a VNET in a different resource group can access it? Alternatively, is there some other way I can approach this?

I feel like this must be a relatively common scenario, and I'm missing something obvious!

0

I have read the issue a couple of time still not 100% sure of what you are trying to do. My understanding is you are trying to connect 2 Vnet but Secure Licences-VM.

For security, when ever you talk about communication between 2 VNet peering or VPN are the only options. And i think that should solve you problem.

If you want more security you can override the default rules on the NIC NSG that allows all VNet communication and create rule to open open up ports you need for the license communication.

Hope this helps.

|improve this answer|||||
  • Basically, I want to enable communication to a single VM (which happens to be a license server) in a different VNET. Each NIC already has an NSG with various rules on it. I want to ensure that the only traffic allowed between the VNETs is to the license server VM. – Cocowalla Nov 9 '18 at 8:31
  • Ok, then you will not need peering. The way i would set it you would be; - License-VM should have a Public IP for other VMs in different VNet to have access - Disable all communication over Vnet on Nic NSG for License-VM - Only open ports needed for License-VM on NSG https://i.imgur.com/v75jmyf.png !https://i.imgur.com/v75jmyf.png This should restrict the VM communication – Hannel Nov 9 '18 at 23:51
  • That was point #1 in my original question - the problem with a public IP is that I can't find any way to lock it down to allow access from another VNET (I don't want it exposed to the internet). I did try adding an NSG rule specifying the CIDR range of the other VNET, but that didn't work (I didn't think it would, but I came across another answer elsewhere on SO that said it should) – Cocowalla Nov 10 '18 at 8:56
0

You can lock down the traffic using NSGs, but the source address of the traffic won't be the private IP addresses of your VMS in "Test VNET", it would be the public IP addresses of the VMs in "Test VNET" instead.

Make sure you convert your VM's public IP addresses to static so you don't have any surprises down the line.

Alternatively you can do VNet peering and then yes, lock down the traffic using the private IP addresses.

|improve this answer|||||

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.