VMX installation on AWS

Overview:

Using Meraki auto VPN technology, we can interconnect multiple branch MX and can use each location as a different LAN subnet. but what if we have part of our infrastructure on the public cloud like AWS and we want to make it a part of the lan, in that case, we have two options, either we can connect using the non-Meraki VPN tunnel or we can use AWS proprietary DX connection.

Both of these options are relatively difficult to set up and hard to manage, to overcome this issue, Meraki has introduced VMX (Virtual MX) which can be deployed as an instance on the AWS, Azure, Google Cloud Platform, Alibaba Cloud, and Cisco NFVIS

This document is a detailed walkthrough for setting up the Meraki VMX on the AWS cloud, after successful installation, VMX can be used as a VPN termination point and all the resources on the AWS behind the VMX can be used privately.

Topology:

We are going to follow the below topology for the installation

Everythingaboutcloud.com

Using Auto VPN we are going to establish connectivity between the Adelaide server which is hosted behind the VMX on Australia VPC and the AP which is connected behind the MX in the Sydney network.

Type of  VMX:

There are three types of VMX, all the different VMX have different throughput and can be used for the different type of setups.

Everythingaboutcloud.com
ref:https://documentation.meraki.com/MX/MX_Installation_Guides/vMX_Comparison_Datasheet
Meraki Dashboard Configuration:

For the VMX installation, most of the setup is needed from the AWS console but follow the below steps for the configuration from Meraki’s end

Everythingaboutcloud.com

  1. Add a valid VMX license to the Meraki dashboard. (Contact Meraki sales for the pricing inquiries)
  2. Create a new network and add VMX to it
  3. After you add the new vMX to your network, navigate to Security & SD-WAN > Appliance status and select “Generate authentication token” to generate the token for the AWS user-data field. This authentication token is unique per VMX and if we don’t add it within 60 minutes in that case we have to regenerate the token. Also, make sure that the network is running on the latest stable firmware.
  4. We can either add the VMX with the serial number at the beginning of creating a network or can be added after creating a network by clicking on add VMX button.

Before we complete the configuration on the AWS console, VMX will always show offline (Never connected to Meraki cloud) state on the Meraki dashboard.

VMX configuration on AWS:
  1. To start with, the first log in to your AWS management console and search for Meraki VMX > Click to subscribe
    Everythingaboutcloud.com
  2. Cisco Meraki recommends using the C5 large instance for the optimum performance but you can always select a different type of instance under the pricing option.
    Everythingaboutcloud.com
  3. After clicking on subscribe on the next screen click on accept terms, we can also download the end-user license agreement under the same page
    Everythingaboutcloud.com
  4. After a few minutes on the next screen, continue to configuration option will be available with the effective date, click on it
    Everythingaboutcloud.com
  5. Now we should be able to verify the firmware version and we can also select the region where we want to deploy the VMX, in our case we are installing it in the Asia Pacific (Sydney)
    Everythingaboutcloud.com
  6. Click on launch
  7. On the next screen click on “Launch with EC2” and it will lead you to the main AWS management console
    Everythingaboutcloud.com
  8. On the next screen, C5 large (selected initially) will be pre-selected and now click on configure instance details
    Everythingaboutcloud.com
  9. On the next screen select the VPC and Subnet carefully to establish the end-to-end connectivity, also now we need to add the authentication token generated from the Meraki dashboard to the user data. This authentication token will work as an authorized bridge between the Meraki dashboard and the AWS console.
  10. Click on Add storage, different types of storage can be selected from here but for the simplicity purpose, we are just keeping the option default
    Everythingaboutcloud.com
  11. Click on review and launch as we are not setting up and security group for this VMX in this setup but it can always be done as per the requirements.
    Everythingaboutcloud.com
  12. Once the instance is successfully launched, click Actions > Networking > Change Source/Destination check > Stop, also verify that VMX has public and private IP and is in the correct VPC and subnet. (Initialization process can take a few minutes to complete). VMX is a nat instance on the AWS platform and it will by default drop any traffic which is not destined for it due to the same reason we have to disable the change source/destination check. Every single AMI running on the Nat instance has the same requirements on AWS.
    Everythingaboutcloud.com
  13. Once the VMX is in the running state, on the Meraki dashboard, we should be able to see instances online
    Everythingaboutcloud.com
  14. Once the Instance is online on the Meraki dashboard, make sure it got the correct IP and we are able to ping the device under the tools
    Everythingaboutcloud.com

 

Auto VPN Configuration:

Now, once the VMX is online, we can establish connectivity between the Lan client in the Sydney network (Meraki MR52 in our case) and the Adelaide server which is behind the VMX using Auto VPN. We are using Amazon Linux-2 free tier instance for the Adelaide server.

  1. On the Meraki dashboard go to Site VPN > select Hub or spoke > Advertise 192.168.1.0/24 subnet under add local subnet and save the settings. once we add the Adelaide subnet under the local networks, we should be able to see this subnet reachable via VMX under every single network’s route table. This is the only configuration we have to do on the Meraki dashboard. Now, the rest of the configuration needs to be done on the AWS console.
    Everythingaboutcloud.com
  2. On the AWS Console, go to VPC > Route table > edit route table
    Everythingaboutcloud.com
  3. Add the route to the destination as Sydney network and next-hop as VMX (We are informing VPC that whenever the traffic is destined to 192.168.128.0/24 network, use VMX as the next route) VMX can be found by copying the instance id from the instance page.
    Everythingaboutcloud.com
  4. Verify the route is successfully added under the routing table and the state is active.
    Everythingaboutcloud.comAfter this configuration, we should be able to reach the Adelaide server from the VMX.
    Everythingaboutcloud.com
    Also, AP under the Sydney network should also be able to reach the Adelaide server using Auto VPN via VMX.
    Everythingaboutcloud.com
    Trafic over Auto VPN can be restricted using the site-to-site VPN firewall rules and recommended to apply at the source end.
    (i.e. we are restricting Telnet traffic from the Meraki to Adelaide server)
    Everythingaboutcloud.com

    Delete/Remove VMX:

    It is equally important to remove the VMX properly to save unexpected processing costs from AWS. Follow the steps to remove the VMX from Meraki and AWS console.
    1. Remove the VMX first from the Meraki network under Security & SD wan > Appliance status > Remove Appliance from the network
    Everythingaboutcloud.com
    2. Now on the AWS console under instances, Terminate the instance (Stopping the instance will still cost you processing fees)
    Everythingaboutcloud.com

    3. Now under volumes, detach the VMX volume otherwise it will cost you for the attached storage volume.
    Everythingaboutcloud.com
    4. Go to AWS market place > Managed Subsciption > Select VMX > Manage > Cancel Subsciption
    Everythingaboutcloud.com

    Everythingaboutcloud.com
    Everythingaboutcloud.com

    5. Once the VMX has been removed, the route status will change to blackhole. remove the route for better management purposes.
    Everythingaboutcloud.com
    6. After successful removal, we will also see VMX offline on the Meraki dashboard if it’s not removed from the first step.
    Everythingaboutcloud.com

Common Issues/Troubleshooting:
  1. VMX is not showing online on the Meraki dashboard
    – Check the instance status on the AWS console and make sure it’s in running state
    – Make sure the VMX is deployed in the correct subnet and that subnet has an active internet gateway attached and under subnet settings auto-assign public ipv4 address settings enabled.
    Everythingaboutcloud.com
    – Check the Security group and make sure it is not denying IP and port range defined under help > Firewall info on the Meraki dashboard (or keep the security group settings as default during the deployment)
    – Contact AWS support ( Meraki support has less visibility here as most of the configuration needs to be done on AWS)
  2. Unable to connect to the instances behind the VMX
    – Make sure that the tunnel is in the active state under Meraki dashboard > Security & SD Wan > Monitor > VPN Status
    – Make sure the destination subnet is advertised under the auto VPN settings
    everythingaboutcloud.com/wp-admin
    – Make sure the source VLAN has VPN mode enabled under addressing and VLAN settings in the Meraki dashboard.
    Everythingaboutcloud.com
    – Source or destination subnet is not part of the site to site VPN firewall rules under Security& Sd wan > Site to site VPN >
    Everythingaboutcloud.com
    – Make sure the Security group on the AWS is allowing the source and destination subnet
    – Check the network firewall rules on the attached VPC
    – Contact Meraki & AWS support for further investigation
  3. Unable to fetch configuration issue on Meraki dashboard
    Everythingaboutcloud.com
    – Restart the VMX instance from the AWS console
    – Contact Meraki support
    – Re-deploy the VMX
  4. vMX100 deployed using an m4.large instance type does not handle user data correctly and the vMX fails to connect to the dashboard. A “no token provided” message is shown:
    – Based on the desired firmware version, one of the following resolutions can be applied:- 15.37+ firmware: If the desired firmware version is 15.37+, deploy the vMX100 with a c5.large instance type instead of m4.large; c5.large, also provides better performance than the m4.large instance type at the same cost
    – 14. x firmware: If vMX100 is to be deployed on 14. x firmware, do the initial deployment using a c5.large instance type, and once the vMX has successfully checked into the dashboard switch to m4.large instance type. Steps to change the instance type are listed below.
    – Stop the vMX instance from the AWS console and select “Change instance type” under instance settings
    – Update the instance type to m4.large and restart the instance

 

Latest posts by Mayur Gadhavi (see all)

1 thought on “VMX installation on AWS”

Leave a Comment

Your email address will not be published. Required fields are marked *