Create isolated subnets on a Virtual Network with VPN

VPN
1

In all my time in Azure I’ve not had to create any complex networking solutions.

I now need to create something like the below.

  1. I need to create a network with several subnets
  2. Some subnets will contain customer VMs. These subnets should not see each other.
    1. Customers 1,2 and 3
    2. Each customer subnet must connect to each customer’s network via site-to-site VPN.
  3. There will be a ‘management’ subnet. This subnet needs to see all the other subnets
  4. Our company network needs to connect to see all subnets

I’ve started playing around with how this might work. A route table seems like half the answer, but I’m missing something.

Am I approaching this correctly, or should I be thinking along different lines… separate networks instead of subnets, for example… and use peering where appropriate?

I’d appreciate some pointers.

​

​

1723×1351 43.8 KB

EDIT:

Thanks, everyone. I’ve rearchitected it per the below. I’ve put it into practice successfully in my Azure play area.

802×770 24.2 KB

2

Use separate virtual networks. not separate subnets in one virtual network. You’ll simplify a lot of this

3

Assign NSGs to each customer subnet to block inbound and outbound traffic to other customer subnets.

4

In my opinion you should use seperate VNets per client. Cam have the managment Vnet peered to all the customer ones. Each clients subnet would have its own VPN gateway. Costs more but is better seperation between the clients. We do some thing simular and each customer Vnet and other resources is also in a seperate Subscription so we can easily identify thier costs for billing.

5

I’d also recommend VNets for everything which should not communicate with each other by default.

It is possible to achieve this via subnets and nsgs but it’s not recommended. You won’t lose any ip of you size subnet=vnet, because those five ips used for azure management are taken from the subnet.

If you architecture your saas app without any customer access to the underlying infrastructure it should be possible to host all vms in the same VNet.

6

Reading some of your other comments, it sounds like this is a saas solutions of yours with customers who connect.

IMO - each customer should be separated from a management perspective into at least separate resource groups.

Each resource group houses all of the infrastructure required for that client. Each client gets it’s own VM, it’s own vnet, etc. Peer vnets to your management network. This gives you better control and visibility from a logging standpoint, and also satisfies many security requirements your clients will likely have regarding workload separation. You can also track cost much easier this way.

How is ingress handled to the VMs? Are your clients ingressing via some firewall appliance? As it looks on the diagram they are ingressing directly to the VM but that isn’t possible unless the VM has a public IP.

7

Separate vnets for each. By default, vnets do not communicate with each other. The alternative of blocking inter-subnet traffic via NSGs is way too much overhead.

8

If you need connect virtual networks On Premise ↔ Azure, then use VPN Gateway. If you need to connect virtual networks Azure ↔ Azure then use Virtual Network Peering, very simple procedure to connect multiple Azure Virtual Networks.

9

This sounds a bit like you’re going for a hub/spoke model. Which would suit having separate vnets. It is possible to do it via one vnet and utilise NSGs, but better to state your intention properly and separate them

10

Hosting multiple customers in a single azure tenant might be a red flag for the azure TOS and service provider model they designed - would be best to review their TOS just to ensure this is Ok - I remember reading this someplace, so worth checking out

11

How is ingress handled to the VMs? Are your clients ingressing via some firewall appliance?

IP SEC, Site to Site. I’ll set up a VPN Gateway. I would separate customers by rg, but now, based on everyone’s feedback, I also create separate VNETS.

12

Thank you, I’ll head down this road.

13

I should clarify. They are not resources owned by the customers. They are VMs hosting a specific SaaS system we’ve written which needs to be connected to the customer network.

14

:index_pointing_up:t6: This is the way. VPNs are used to connect VNETs, not subnets. Why even bother with the cost and complexity of VPNs when peering is easier and free? Control traffic with FWs, NSGs, and UDRs.