Need to configure a second VMX100 in another Azure region for Client VPN redundancy

[Dave80]

Hi all

We have a need for a second VMX100 to be configured in another Azure region.

Primarily this is just for client vpn redundancy.

Windows 10 clients currently configured to the public IP address of the VMX. Will change this to use a dynamic IP.

Has anyone managed to do this successfully or what else have you configured for redundancy in Azure?

Thanks

[PhilipDAth · Accepted solution]

I'm more of an Amazon AWS fan and haven't used Azure to do something this complex before.

I see Azure offer something called Traffic Manager which uses DNS for doing failover.  So I'd look to set that up, create a DNS entry like vpn.company.com, and get the clients to use that.

https://docs.microsoft.com/en-us/azure/networking/disaster-recovery-dns-traffic-manager 

If this was AWS I can tell you how to do full active/active VMX with failover, but Azure makes doing these things much trickier.  It grates me that Azure doesn't even offer the basic function to shut down a virtual VMX and then starting it up again.  Like seriously.

https://www.ifm.net.nz/cookbooks/meraki-ha-vmx-amazon-aws.html 

[Dave80]

Thanks PhilipDAth for a solution.

I have started to set up your suggestion now.

The original VMX is configured in Hub mode connecting to a spoke physical device on premise.

Is there a way of configuring the secondary (new) VMX only for Client VPN without touching the Site-to-site VPN?

But it seems to get this working and seeing local networks I need to configure an option under site-to-site vpn.

Will it impact the production network if I do configure the secondary VMX as another Hub? I don't want it used unless the primary fails for some reason and to control this by using the Azure Traffic Manager priority load balancing.

The concentrator priority also seems to give this functionality that the spoke will use only the hub network at the top.

I don't want to introduce routing errors in to the environment or cause downtime at this critical time.

[PhilipDAth]

>Is there a way of configuring the secondary (new) VMX only for Client VPN without touching the Site-to-site VPN?

I don't think so as that is the only way to tell the vMX of local routes.

>Will it impact the production network if I do configure the secondary VMX as another Hub?

No.  It won't be used unless spokes are specifically configured to use it.

[Dave80]

Thanks again.

Getting closer...

I have configured the new vmx (in uk west) as a hub and added the local networks/subnets for the azure uk west region. I've configured a certificate on the local dc to authenticate the ldap connection which works fine as i can authenticate using ldap now. Can see the vpn connection on new vmx. 

The issue now is I cant browse to servers/services in the other azure uk south region.

I have created user defined routes from that region (uk south)  to the new appliance on all subnets. UDRs are also created locally (uk west) for vpn traffic to go to the new appliance.

What else needs to be done to get this working?

When connected to the vpn my client routes look fine as i can see both regions.

Should  i add the uk south region subnets  into local networks on the new vmx as well?

I tried this but didn't seem to make a difference but wondering if they should be in there or not?

The dns servers seem to be ignored completely that are in the client vpn settings.

Any ideas greatly received...

[PhilipDAth]

For each VMX processing client VPN connections you have to define a unique client VPN pool.

In each Azure region you need to add a route for both pools via the local VMX.

[Dave80]

I think I have done that. Let me specify the config so you can check.

Each Azure region has it's own vmx and a unique client pool subnet. Each Azure region has a route from the client pool subnet only to each local vmx not to each other. 

In Azure the original region, (UK south) has routes from all subnets with servers in to the new (Uk West) vmx client subnet with next hop set to the vmx address. (It also has these routes to the vmx in that region)

The only UK south subnet I haven't added this route to is the client vpn subnet.

Wasn't sure if it was required from one vmx subnet to the other vmx subnet but tried it to see but no difference.

Is this required or not? As this is to be a highly available Vmx setup I want them to be able to route independently from each other in case one fails.

My problem is that when connected to the new client VPN after successful ldap authentication it can't ping servers that is possible on the original client vpn.

Any ideas what is missing or not right?

[PhilipDAth]

Each azure region will need a route for both client VPN subnets pointing to the local VMX.