具有VNet网关和P2S VPN的Azure内部负载平衡网络

Question

So as the title suggests, I need to make a load-balanced internal gateway with a VPN. I'm a developer, so networking is not my forte.

I have two identical VMs (VM1 in Availability Zone 1 and VM2 in Availability Zone 2) and I need to share VPN traffic between them. My client has provided a range of 5 addresses that will be configured on their firewall, so I will pick one for them to use and they then need to be oblivious to the internal routing.

My ultimate goal is to allow the client to connect through a VPN to one IP address (in the range they have allocated) and let Azure direct the traffic to VM1 primarily, but failover to VM2 if Availability Zone 1 goes down. The client must be oblivious to which VM they ultimately connect to.

My problem is that I cannot create a configuration where the Load Balancer's static IP is in the address range of the Gateway's VPN P2S address pool. Azure requires the P2S address pool to be outside of the VNet's address space and the Load Balancer needs to use the VNet's Subnet (which obviously is INSIDE the VNet's address space, so I'm stuck.

I can create the GW -> Vnet -> subnet -> VM1/VM2 set up no problem using the client's specified IP range for the P2S VPN, but without a Load Balancer, how do I then direct the traffic between the VMs?

eg (IPs are hypothetical)

• The Vnet address range is 172.10.0.0/16
• The Gateway subnet is 172.10.10.0/24
• The Gateway's P2S address pool is 172.5.5.5/29
• VM1's IP is 172.10.10.4
• VM2's IP is 172.10.10.5

I can create a Load Balancer to use the Vnet (and the VMs in a Backend Pool), but then it's static IP has to fall in the VNet's subnet and thus outside the P2S address pool. So how do I achieve this?

I thought of creating a second VNet and corresponding Gateway and linking the Gateways, but I seemed to end up in the same boat

UPDATE : here is an image of my VNet diagram. I have only added one of the VMs (NSPHiAvail1) for now, but VM2 will be in the same LB backend pool

NSP_Address_Range is the range is a subnet of the VNet and is the range dictated by the client. The load balancer has a frontend IP in this range

Answer 1

Firstly, the Azure load balancer does round-robin load balancing for new incoming TCP connections, you could not use it for failover.

My problem is that I cannot create a configuration where the Load Balancer's static IP is in the address range of the Gateway's VPN P2S address pool.

You do not need to add the Load balancer frontend IP in the P2S address pool, the address pool is used for clients connecting to your Azure VNet.

Generally, you could configure P2S VPN gateway, create Gateway subnet and vmsubnet and create an internal standard SKU load balancer in the vmsubnet , then you could add the VMs in the vmsubnet into the backend pool as the backend target of the load balancer and configure the healthpro and load balancer rule for load balancing traffic. If so, you could access the backend VMs from clients via the load balancer frontend private IP.

Moreover, you could know some limitations about internal load balancer.

Answer 2

My problem was the Load Balancer Rules - or lack thereof. Once I had added a rule for port 1433 (SQL Server), I was able to query the DB from my local instance of SSMS

There is another solution that is a LOT simpler than the solution I was trying to implement, BUT it does not work allow for an internal load balancer

Azure Virtual Machine Scale Sets implement as many VMs as I specify and will automatically switch to another zone if one goes down. I have no need for the scalability aspect, so I disabled this and I'm only using the Load balancing aspect.

NB This setup only exposes a PUBLIC IP and you cannot assign an internal load balancer in conjunction with the default public load balancer

Here's some info:

Quickstart: Create a virtual machine scale set in the Azure portal

Create a virtual machine scale set that uses Availability Zones

Networking for Azure virtual machine scale sets

Virtual Machine Scale Sets

The cost is exactly what you'd pay for individual VMs, but the loadbalancing is included. So it's cheaper than the solution I described in my question. Bonus!