Click 日本語 for Japanese
This document is a walkthrough for setting up a virtual MX appliance in the Google Cloud Marketplace. After completing the steps outlined in this document, you will have a virtual MX appliance running in Google Cloud that serves as an AutoVPN termination point for your physical MX devices.
Supported Instance Type and Regions
The vMX is currently only supported on the c2-standard-4 compute optimized instance type for optimal performance. The C2 instance types are not available in all GCP regions. Please refer to this document for the regions that support the C2 instances.
Meraki Dashboard Configuration
Begin by creating a new Security Appliance network in your organization. If needed, please refer to the guide on creating a new network in the Meraki dashboard.
1. Add license(s) to the Meraki dashboard
To complete the vMX Meraki dashboard configuration, a vMX license must be available for use in your organization.
If you do not have access to a vMX license or require additional vMX licenses, please reach out to your Meraki reseller or sales representative.
2. Create a "Security appliance" network type:
3. Assign vMX type to network
Once you have created the "Security appliance" network and added the appropriate license you will be able to deploy a new vMX to your network by clicking on the 'Add vMX' button.
4. Generate the authentication token
Before generating the token, please verify the firmware is configured for MX 16.8+. If the vMX network firmware is set to anything below that, the upgrade will not occur.
After you add the new vMX to your network, navigate to Security Appliance > Appliance status and select “Generate authentication token” to generate the token for the GCP vMX Authentication Token field.
5. Copy the newly generated token and save it.
The newly generated token will be used in the "New Cisco Meraki vMX deployment" configuration section when creating a new instance.
The authentication token must be entered into the Google Cloud instance within 1 hour of generating it. If it has been more than 1 hour, then a new token must be generated.
Google Cloud Setup
Before You Begin
You must have the following before you begin:
- Google Cloud VPC network. To find more information about this, please click here.
Deploying the vMX
Deploying the vMX can be done by following the steps below:
- Access the Cisco Meraki vMX offer by clicking here or search for "Meraki" in the GCP marketplace to find the vMX solution
- Click Launch on the vMX offer landing page
- Enter a Deployment Name for the instance
- Choose the desired Zone
- Select the c2-standard-4 vMX instance size. This is the only instance size currently offered for vMX on GCP
- Paste the vMX Authentication token you copied from the Meraki dashboard in the steps earlier to the vMX Authentication Token field
- The Boot Disk options can remain as-is
- Under the Network section select the desired Network, Subnetwork and External IP for this instance. The External IP field can be left as Ephemeral (if you would like to let GCP assign a public IP to the vMX itself) or set to None (if you would like to have a private IP on the vMX and have it egress through an upstream device like a firewall or Google Cloud NAT instance). You do not need to add more network interfaces to the VM as it is a single interface appliance
- Click Deploy
If deploying a vMX behind a GCP Cloud NAT instance, you will need to enable "endpoint-independent mapping" under the advanced configuration settings of the Cloud NAT
The deployment of the instance on GCP can take a couple minutes to complete and the vMX itself can take up to ~3 minutes to boot and check in to the Meraki dashboard. Please allow for 5-10 minutes for the vMX to be fully deployed and online in your Meraki dashboard.
If deployment via the GCP Marketplace is not possible, the vMX can also be deployed directly using the production vMX image hosted on the cisco-public project. Currently, this is not possible via the console and requires running the following gcloud CLI command
gcloud compute instances create VMX_INSTANCE_NAME \ --zone=ZONE \ --image=meraki-vmx-16-10 \ --image-project=cisco-public \ --network-interface=nic-type=GVNIC,network=NETWORK,subnet=SUBNET \ --machine-type=c2-standard-4 \ --tags=http-server \ --can-ip-forward \ --enable-display-device \ --metadata=token=VM_AUTH_TOKEN
Replace the following values:
- VMX_INSTANCE_NAME: the name for the vMX instance
- ZONE: desired Zone for the deployment
- NETWORK: network for the vMX instance
- SUBNET: subnet for the vMX instance
- VM_AUTH_TOKEN: the vMX Authentication token got from the Meraki dashboard
The remaining values should NOT be changed and if changed can cause the deployments to fail. Also, please note that the network-interface nic-type has to be set to GVNIC. If not set to GVNIC, it will lead to degraded performance for the vMX.
Additional VPC Configuration
The virtual MX appliance will allow for site-to-site VPN connectivity using Auto VPN between GCP and other remote MXs. In order to have proper bidirectional communication between remote subnets that are terminating into GCP via the vMX and hosts within GCP, the VPC routing table must be updated for the remote Auto VPN-connected subnets.
- Navigate to VPC Networks > Routes from the GCP console and select Create Route.
- Specify a Name and Description for the route.
- Select the Network that your vMX is deployed in.
- In the Destination IP range, add the routes available via Auto VPN.
- Select the Specify an instance option for the next hop and select the vMX instance as the Next hop instance.
We can also leverage the BGP capabilities on the vMX to exchange routes dynamically between the vMX and GCP. Please, refer to the vMX integration guide with Google's Network Connectivity Center for more details.
The instance screenshot is a handy tool for troubleshooting some scenarios when a vMX is not checking in to the Meraki dashboard. Currently it is not possible to retrieve an instance screenshot from a vMX running on GCP utilizing the screenshot feature inside of GCP. We are working on adding this capability but in the meantime please refer to the below section on troubleshooting should your vMX have issues contacting the Meraki dashboard.
vMX won't check in to the Meraki Dashboard
The most common problem people face when deploying a vMX is getting it provisioned and online in their Meraki dashboard in the first place. In most cases, a vMX should successfully connect to the Meraki dashboard without issue. If your GCP vMX is not checking in to dashboard after being deployed please check the following items
In order for the vMX to function on GCP it must be running 16.8+ firmware. Please ensure the vMX network in dashboard is set to at least 16.8 firmware. If it was set to an earlier version, you will need to delete and re-deploy your vMX after setting the network to 16.8+.
The first step is to confirm if the token was generated in dashboard within the last 1 hour? If not, you will need to generate a new one and delete/re-deploy your vMX. You can also update the token on a vMX that has been deployed but has not yet checked in to the Meraki dashboard by performing the following:
- Navigate to Compute Engine > VM Instances, click on the vMX in question and click on Stop to turn it off
- Click Edit
- Scroll down to the Custom Metadata section and update the value in the token field
- Click Save and then click Start to power the vMX back up
Confirming Cloud Reachability
If the token is valid and within one hour of being generated, the next step is to confirm the vMX is able to reach the Meraki dashboard. There are several reasons this might not be working including firewall rules or routes in the VPC.
By default, HTTP traffic inbound to the vMX is disabled for security purposes. You can enable inbound HTTP traffic to the vMX (for accessing the local status page) by performing the following:
- Navigate to Compute Engine > VM Instances, click on the vMX in question and click Edit (you do not need to turn off the instance for this change)
- Scroll down to the Firewalls section and select the box next to Allow HTTP traffic
- Click Save
- On the VM instance details page copy the External IP that was assigned to the instance and navigate to http://<external-ip> to load the local status page of the vMX
- On the local status page you can find the health status of the vMX and whether it is successfully able to connect to the Meraki cloud or not
No "Add vMX" Button
When navigating to Security & SD-WAN > Appliance Status, if there is no "Add vMX" button, please ensure the following two conditions are met:
- You have available vMX licenses in your license pool.
- You have created a "Security appliance" network type.
Please note that Meraki support does not troubleshoot GCP cloud-specific firewall rules and deployments.
Before deploying a virtual MX, it is important to understand several key concepts:
All MXs can be configured in either NAT or VPN concentrator mode. There are important considerations for both modes. For more detailed information on concentrator modes, click here.
In this mode, the MX is configured with a single Ethernet connection to the upstream network. All traffic will be sent and received on this interface. This is the only supported configuration for MX appliances serving as VPN termination points into Google Cloud.
NAT Mode Concentrator
In this mode the MX is configured with a single Ethernet connection to the upstream network and one Ethernet connection to the downstream network. VPN traffic is received and sent on the WAN interfaces connecting the MX to the upstream network and the decrypted, unencapsulated traffic is sent and received on the LAN interface that connects the MX to the downstream network.
A limited NAT mode capability can be enabled on the vMX in which traffic from the spokes will be NATed to the vMX's IP as it egresses the vMX. Other capabilities of the NAT mode including DHCP, HA or multiple ports (LAN and WAN) are not supported. In each mode the vMX is still a one-armed appliance with one network interface.
There are several options available for the structure of the VPN deployment.
In this configuration, branches will only send traffic across the VPN if it is destined for a specific subnet that is being advertised by another MX in the same Dashboard organization. The remaining traffic will be checked against other available routes, such as static LAN routes and third-party VPN routes, and if not matched will be NATed and sent out the branch MX unencrypted.
In full tunnel mode all traffic that the branch or remote office does not have another route to is sent to a VPN hub.
The highest MTU (Maximum Transmission Unit) value between on-site locations and Google Cloud is 1460 as noted here.
Google Cloud Terminology
During the setup of your vMX instance, or over the course of working within GCP, you may encounter additional terminology which is not defined in this document. To find out more about these terms, and for additional details, please see the GCP Documentation .