Configure AnyConnect on a VMX in Azure

[PhilipDAth]

I'm trying to configure AnyConnect on a VMX in Azure.  I am very familiar with the process of configuring AnyConnect, and have done so many times on VMX in AWS.

The problem I am having in Azure is how to tell Azure to allow tcp/443 into the VMX.  A packet capture tells me no traffic I generate makes it to the VMX.  The resource group that gets created when you deploy the VMX is locked by Meraki (so I can not change anything).  It doesn't have a network security group, and it does not allow me to add a network security group (to which you would normally add an inbox rule to allow tcp/443).

Support tells me that this is a supported configuration.

Has anyone managed to create this configuration?

[JSLanders]

Did you ever find a solution? I am experiencing a similar issue.

[ccietbd]

For anyone coming across this in the future, the issue is that the vMX managed app bundles everything in and doesn't let you change anything, including not allowing you to change the vNIC to use a subnet + NSG you specify.  You have to create the subnet/vnet/nsg before you deploy the app, then during deployment instead of using the wizard to create those elements, you tie the app to the subnet and vNet you already created and associated to an NSG allowing TCP+UDP 443 inbound (remember AnyConnect prefers and will work better with UDP:443 for DTLS, TLS:443 for TLS is a higher-overhead fallback).

I outlined the process in detail here

https://ccietbd.com/2022/04/20/basic-anyconnect-on-azure-hosted-meraki-vmx/

[tomas209ca]

ccietdb,

i have tried this on my vmx and it works for for any connect. The only thing is when i associate the NSG to the sub-net it kill everything and then i am not able to get to my server in azure. Take this NSG off and im good to go again. I also have NSG on my server also. The MX has a Standard static Wan ip and is in Zone, but Zone failover isnt used. vMX has the vNet and subnet created first before making the resource for the vMX. Thank you.

[ccietbd]

You will need to add rules to the NSG to allow the east/west traffic you need, when the NSG flow logs to see where its getting blocked. 

[ScholzEDV]

I have exactly the same problem. I have two vMX for failover and both have no NSG after deploy. Is it not possible to configure it afterwards?

[ccietbd]

You cannot add after deploying if you use all the automatically generated vNets and Subnets etc through the wizard, it locks it all down. Check my blog post where I outline it, basically create your elements all first then choose them during the wizard instead of creating new during the wizard. 

https://ccietbd.com/2022/04/20/basic-anyconnect-on-azure-hosted-meraki-vmx/

then add whatever rules you need to allow east/west traffic and anything else needed. 

[PhilipDAth]

Specifically, this happens when you choose to use availability zones during deployment.  You have to choose a zone of "none" to be able to use a NSG.

[MartinLL]

The zone has no effect on whether you can use an NSG or not.

If you choose the vMX wizard to create the vnet and subnet for you that resource is pooled together with the rest of the managed applications for the vMX service. This means that you have no access to do any for of changes to it. As @ccietbd states  create your vnet/subnet structure before deploying the vMX. Now you can apply NSG's and even UDRs for traffic steering.

If you choose a zone during the wizard what actually occurs is that you get the standard public IP SKU instead of basic public IP SKU.

The basic SKU allows all inbound traffic by default. Standard SKU is the opposite. Therefore, if you select a zone in the vMX you must be able to add an NSG to your vMX subnet to allow 443 inbound to the vMX for anyconnect.

And this is smart to do now. Basic public ip SKU is going away 30. September 2025. If you have not upgraded by then you are in for a world of fun 🙂