As many of you know, I have a side line of distraction running a computer shop. From February 2012 through July 2013, it was walking distance from home but still had a 20mbit ADSL line from Sonic.net.
In July I had to move out of the shop for the construction of new luxury apartments on the property. And in the year and a half I had that location, Sonic went through some adjustments and the costs involved with setting up service at the new location more than doubled. So I’m holding off until I have time to spend more than a couple hours at a time in the shop. For now I’m connected with a Verizon Wireless 4G LTE USB modem on a Cradlepoint MBR1000 router/access point.
In the last week I’ve found a pretty good way to access systems in the shop from home without too much hardware wrangling. My home network has two Meraki access points, a MR12 (courtesy of the Meraki webinar series) and a MR16 (courtesy of a fellow Tech Field Day delegate who wasn’t using his). I have an MR14 on the floor of my office, waiting for me to track down its previous owner and try to get it removed from his account so I can add it to my account, but I expect that may not happen soon.
High Level Wrangling Overview – Picking Out The Pieces
I was looking at the Meraki Teleworker Z1 router, which supports VPN connectivity back to a VPN concentrator. It was tempting, still is in fact, but in the process of researching that solution, I discovered three interesting things.
1) Meraki provides a virtual concentrator for low-volume use, as a free download if you have the enterprise dashboard (i.e. have a MR device under cloud management) already. You don’t need a physical concentrator/MX device. And you don’t need ESXi to use it; I have it in VMware Player on my desktop for now.
2) That VPN connectivity works between MR access points as well, so you can set up, say, an MR12 in one location, specify a SSID as a VPN tunnel, and access the other network that way.
3) The MR12 access point has a second wired Ethernet connection that can be used to bridge wired clients into the VPN. I knew about this from the day I unpacked the MR12, but I only learned today how to make it work.
Low Level Wrangling Implementation – The Secret Of Association
Prerequisites:
- Access to your Meraki dashboard
- Two MR devices installed and working, one at either site. (MR12/MR58 required if you want to bridge a LAN through the VPN, as seen in Fourth step below)
- Internet connectivity for both MR devices
- A way to run a VMware virtual machine (Player, Fusion, ESXi, Workstation should all do) at your HQ site
In these steps we may refer to “HQ” as the main location, where your VPN concentrator and most of the servers your remote clients need to access would be.
First step – Create a virtual VPN concentrator “network” at “HQ”
We’re going to set up the virtual machine that hosts the VPN concentrator. This should run at your HQ site.
You’ll go to the Network pulldown at the top and choose “Create a network.” Give it a name and choose a network type of “VM concentrator.” Click Create.
Then you go to Concentrator-> VM status and see that this concentrator has never connected to the cloud. This might be because you’ve not started it up yet. Let’s do that now. 
Click “Download” next to “Vmware image” and receive the zipfile (about 15MByte, 24MByte when you uncompress it). Create a new directory and extract it to that directory. Then open it with your choice of virtualization products. For VMware Player you’d use “Open a virtual machine.”
Note that the requirements are pretty small, and take that into account when considering your VPN load as well. By default the VM comes up with 1 vCPU, 512MB RAM, and 128.5MB disk allocated.
Now start up the VM and wait for it to make contact with the Meraki Cloud. When it connects, you’ll see Internet Port, Public IP, and no more “never connected” message on the Meraki dashboard.
Second step – Create a VPN SSID
Meraki’s documentation says that VPN tunnels are configured on a per SSID basis. This means that you either need to make an existing SSID serve VPN traffic (not recommended by me, as it may get confusing at the site that hosts the VPN concentrator), or create a new one explicitly for VPN traffic.
You can create a new SSID on the Configure->SSIDs page. I named mine Home VPN since the VPN concentrator is at home. Name it, and leave it disabled. Save changes.
Now we’re going to set up access control for the new SSID before enabling it. Go to Configure->Access Control, choose your new SSID name, and change these settings.
- Association requirements – Set to whatever you like; most home or casual users will use Pre-shared key with WPA2
- Addressing and traffic – Here’s the magic bit, choose VPN: tunnel data to a concentrator. This will open the “Concentrator” menu item, and you choose “Tunnel traffic to <your concentrator name>.” Test connectivity but don’t panic if it fails.
- VPN tunnel type – If you want all traffic from the other end of the VPN to go through your “main” site, leave it at Full tunnel: tunnel all traffic. If you only want to tunnel traffic intended for your “HQ” site (where the concentrator lives), choose “Split tunnel: tunnel only selected traffic” and check the “VPN split tunnel rules.” By default they’re probably good enough, but if you have other networks at your “HQ” that don’t show up, add them as separate split tunnel rules.
Other options can be set, but don’t necessarily pertain to the VPN, so I’ll leave them as an exercise for the reader.
Now go back to Configure-SSIDs and you may enable your newly secured VPN SSID.
Third step – lock down the VPN SSID to your remote sites
Connecting to the VPN SSID from your headquarters may have unexpected results, and if you take devices between sites, you may get suboptimal performance when you’re at HQ. So I’d recommend limiting the SSID availability for this SSID.
The way I do this is to use a “tag” in the access point configuration. For each AP that’s remote and will get VPN access, go to Monitor->Access Points and choose your remote AP. “Edit Configuration” and add a tag like “RemoteVPN” (note that tags are individual words, not comma-separated, so “remote vpn” is two tags). Save your changes.
Now go back to Configure->SSID Availability, choose your VPN SSID, and change Per-AP availability to “This SSID is enabled on some APs.” Choose your tag and save your changes.
Now the VPN SSID will only show up on the APs you’ve tagged as RemoteVPN, and not on your HQ APs.
Fourth step – enable wired connectivity to the VPN
The MR12 and MR58 access points have a second 10/100 Ethernet port on the back. This port can be used as failover in case the first Ethernet port loses Internet connectivity, but for this project I want to use it to connect wired systems (i.e. my shop lab, wired cameras, etc) to the VPN.
The port is disabled by default. I didn’t realize this at first, and gave up on it for quite a while, but during this project I found that you can bridge the wired port on the MR12 to any of your SSIDs.
Oddly, this shows up in “Network-wide settings” under Configure. You can go down to the Device configuration section and change “Clients wired directly to Meraki APs” to “Behave like they are connected to ‘Home VPN'” (or whatever you call your VPN SSID).
When you do this, and save your changes, anything connected to that wired port will behave, for network purposes, like it was a wireless client on the SSID.
One caveat from Meraki, though:
If you disable an SSID on an AP, and the SSID is also specified for wired clients, the wired clients feature will still be enabled on the AP.
This means you can use a MR12 purely as a wired bridge to your VPN if you want to. I believe it also means that the wired client functionality is independent of the settings we made in the third step above. And if you have an MR12 at your HQ site, connecting anything to the second ethernet on that AP will VPN it through your concentrator.
It may have other security and availability implications. In the small networks we’re talking about, it probably isn’t too significant. You probably have switch ports available elsewhere at your HQ location anyway.
So where do we go from here?
At this point, I have transparent connectivity between my home office and the shop. Anything connected in the shop on my VPN SSID, and anything on the wired port on the MR12, gets its DHCP lease, DNS settings, and so forth from the Cradlepoint MBR1200 router in my home office, as if it were under my desk at home.
My next steps will be to wire up a switch on the shop end of the connection and hang a VMware server off of it. I’m still stocking parts for the other machines, but one server will be good enough to validate the VPN connectivity and start working on upgrades.
I will have to go with a real wired connection someday, most likely Sonic with bonded ADSL2+, and then it’s conceivable that I might outgrow the virtual VPN concentrator. At that point I’ll either look at getting a deal on a MX60, or revamping the VPN altogether (possibly with the Cradlepoint MBR1200 and MBR1400).
If you’ve played with this method of VPN connection and have any further suggestions, or observations on the performance limits of the virtual concentrator, I’d love to hear about them in the comments below.
![628x471[1]](https://rsts11.com/wp-content/uploads/2013/07/628x4711.jpg?w=300&h=200)
![NTH_Symposium_2013_Logo-transparent[1]](https://rsts11.com/wp-content/uploads/2013/07/nth_symposium_2013_logo-transparent1.png){kind=logo}
![ins_specialoffers_disneyland[1]](https://rsts11.com/wp-content/uploads/2013/07/ins_specialoffers_disneyland1.jpg?w=300&h=199)
rsts11 - Robert Novak on system administration 