Access Meraki dashboard from FQDN

[WarrenG]

So with all the power and Internet outages we've had recently due to weather, we have identified our own office Internet connection as a potential single point of failure. We have all our client's Meraki dashboard portals locked down to only be available from our own static IP address. Other portals we use are also locked down by IP address only. So we need to add some redundancy so that if our Internet connection goes down, we can still support our clients by accessing our tools from another IP address.

I have looked into setting up a vMX in Azure, but it appears that you cannot assign a static IP address to it as that's a limitation on Azure side. Not sure if that's accurate or not, just what I have read.

If there was a way to allow access to our client's dashboards based on FQDN then I could create a DNS record to point to my home Internet IP address, but it seems Meraki doesn't allow that??

What are some other simple options that we could implement to add this redundancy? Would prefer to stay in the Microsoft and/or Meraki family rather than add another third party solution. Any ideas?

[mlefebvre]

Is this just for you, or is this for more than one person? And is it a temporary or long-term solution that you need?

[WarrenG]

This will be for multiple techs on our team, and it is intended to be a long term solution. Thanks!

[mlefebvre]

vMX is probably the simplest way, and I suspect there is a way to give it a static IP even if not to the resource directly...you could also co-locate a physical MX in a datacenter, use it as VPN hub for emergencies. Third option off the top of my head would be to provision a Windows Server VM in Azure with a public IP, give it a Terminal Services license for more than 2 concurrent users, and have people RDP into that in an emergency to access the dashboard. For extra security, you could use Azure's Bastion Host feature to have people access the VM through Azure authentication in a web browser instead of RDP.

[edit]

The last, and least recommended option would be, if you don't have API access ACL'd, you could use an API script to remove the dashboard IP restrictions temporarily in an emergency.

[WarrenG]

Okay thanks, I will look into these options a little further. Appreciate the input on this!

[tcanty]

Another option, if your home routers have dyndns capabilities, you could right a script to run frequently making use of the API to get the ip's of the home technicians connections and update the dashboard restrictions to include there ip's. A solution we implemented a while ago, and works well, and cheaper then running a vm in azure or vmx.

[PhilipDAth]

I'm going to suggest a completely different method - zero-trust based.

Use a SAML provider such as Cisco Duo or AzureAD/Entra.

https://documentation.meraki.com/General_Administration/Managing_Dashboard_Access/Configuring_SAML_S... 

From here you can provide lots of restrictions.  For example, you can say that only FIDO2 authentication is acceptable (such as Yubikey).  This is the gold standard at the moment because FIDO2 is phishing-resistant.  You can also choose to use medium-strength MFA with push notifications.
Please don't use low strength TXT based authentication.  🙂

If you use Intune with AzureAD and have an Azure AD P1 licence or better, you can create a conditional access policy to say access is only allowed from AzureAD joined computers.

If you don't have these licences then Cisco Duo is cheaper.  You can stay only allow access from "trusted endpoints".

https://duo.com/docs/trusted-endpoints 

If money is no object, I would hands down go with Cisco Duo.  It is usually cheaper as well.  It is very flexible and much easier to drive and manage.

Then you have full ZTNA.  You can access from anywhere, but completely tied down.