SecureClient Client VPN to vMX in version 19

[JonathanClark]

Hi All,

I have a question around using the anyconnect VPN client directly to a vMX hosted in Azure.

Are there any deployment guidelines to set this up? 

Additionally can this be done with either concentrator or NAT modes? Please do elaborate if one is preferred over the other.

Apologies if this is publically available and I've just missed it.

I'm hoping to set up direct access via the vMX with certificate based auth using Secure Client.
Currently this doens't seem to be working using a single-arm Concentrator despite trying various options. 

I'm considering rolling to NAT mode and reconfiguring everything to see if this would suffice, but perhaps some of you could save me the trouble if I'm going down the wrong path.

Thanking you in advance. 

[Mloraditch]

Does your vMX have a standard public IP? It does by default now but some older deployments will have basic still.  If so do you have an NSG attached to the network it's using and does that NSG allow 443 inbound?

[JonathanClark]

Hi Mloraditch,

I saw in some of your previous threads you recommended moving to NAT mode as a part of the Standard IP SKU process. And then just allow traffic through the NSG. Do you think this would work then if we were to go down this route? I've seen mixed opinions on traffic reaching the vMX this way but perhaps you know what is valid today? 

In terms of the standard Public IP, yes and its currently in a concentrator mode.

[Mloraditch]

I hadn't actually set this up, but I just did for testing on a vMX that I have in NAT mode and split and full tunneling both work.

[PhilipDAth]

Are you saying with a VMX in routed mode, you were able to initate traffic from a VM in Azure to devices over AutoVPN?

[Mloraditch]

Yes, this works fine. I started doing all new deployments in NAT mode.

[PhilipDAth]

There are complications with doing this in Azure.  Simple in AWS ...

If you use NAT mode, you can use SD-WAN and AnyConnect to access resources inside of Azure.  However, due to NAT mode, resources in Azure are unable to access resources over SD-WAN.

Previously, you had to use the "basic IP sku" to make AnyConnect work - because this was the only Azure option to allow Internet traffic to initiate a connection to the VMX, which is needed for AnyConnect.

However, Microsoft is now deprecating this option, meaning you have to use the "standard IP sku" - this sku does not allow traffic to be initiated into the VMX.  I don't see how it can be made to work now.

The other option is to use SecureConnect instead, which can terminate AnyConnect connections in Cisco's cloud and can build an SD-WAN connection to a VMX in Azure.  However, if you do this, you might as well build a tunnel connecting SecureConnect directly to Azure, and not bother deploying a VMX at all.

https://docs.umbrella.com/umbrella-user-guide/docs/manual-azure-ipsec-deployment-guide

[JonathanClark]

Hi Philip, thank you so much for your response.

A few questions from my side:

If you use NAT mode, you can use SD-WAN and AnyConnect to access resources inside of Azure.  However, due to NAT mode, resources in Azure are unable to access resources over SD-WAN.

Is there any reason Auto-VPN isn't sharing the routes then? Or what if we used something more manual like BGP. I'd love to understand this and perhaps combined with a combonation of NAT exemption we could make this work?

I do love the idea of Secure Connect though and I'll be sure to give this some consideration.

[Mloraditch]

@PhilipDAth I don't understand this either? What limitation are you referring to? The only difference I'm aware of is a standard sku blocks traffic by default so you have to use your own vnet and attach an NSG to the subnet in question.

You can also reach all of your other resources the same as before, the config is just different as now you put static routes in the MX pointing back to your other Azure Subnets (if you have more than one).

If you only have one LAN subnet the mx can either be the gateway for devices on those subnets or you can continue to use a route table and point just SDWAN traffic to the MX.

The only limit I'm aware of is the MX can't be the gateway for anything not in its own subnet (at least easily)

[PhilipDAth]

>If you use NAT mode, you can use SD-WAN and AnyConnect to access resources inside of Azure. 

Correct.

>However, due to NAT mode, resources in Azure are unable to access resources over SD-WAN.

It is not because of route sharing, it is because of the NAT.  When you access the Internet at home, your machine gets NATed.  This prevents the Internet from being able to access your machine directly.  Same deal here.

>The only difference I'm aware of is a standard sku blocks traffic by default so you have to use your own vnet and attach an NSG to the subnet in question.

When I last tried it, you could not attach an NSG.  The VMX could initiate traffic out, but there was no way with a standard IP SKU to initiate traffic inbound from the Internet.

Are you saying you can attach an NSG when using a standard IP SKU on a VMX to allow AnyConnect traffic inbound?

[Mloraditch · Accepted solution]

Yes I've attached an NSG to the subnet that I have the MX wan interface on (not directly to the nic)

[JonathanClark]

Deployed and moved over to Standard IP SKU. This is a must know, thanks.