My own love affair with Meraki started way earlier than Cisco’s acquisition of the cloud networking biggie. Though we use Meraki in targeted locations at my “day job”, I’ve followed their evolution in my long-running role as a gonzo freelance IT journalist since the days when they only offered Wi-Fi, then through the addition of the MX series of security appliances and Ethernet switches. I’ve had the rare frustration with Meraki’s features, but I do mean rare compared to the pain caused by other vendors consistent shitcode. For my own small consulting company, there’s one Meraki feature I’m incredibly fond of as an administrator- and that’s Client VPN. It’s easy to setup (but you still have to understand a few things), and incredibly empowering to the remote administrator.
Down on the Farm
My favorite customer is a prestigious large dairy farm that needed a network overhaul. When I took on the account, there was a mishmash of consumer-grade routers and switches in use, multiple 4G ISP connections, and lots of odd little islands of individual networks. I was able to tame the beast, making it a single decent network with point-to-point wireless bridges connecting far away buildings (using 5 GHz where possible, 900 MHz through trees), UPS, managed switches, and Meraki APs. Along with keeping the network healthy, I find myself doing a bit of desktop and device support. My philosophy is to never visit the site unless something new is physically being added. I’d much rather do everything remotely, which brings me back to Meraki’s client VPN.
Setting it up: the farm network is 192.168.1.0/24 on the inside (part of what I inherited), with a single public ISP address on the outside of the Meraki MX. Here’s where you set up client VPN in the MX:
Then, you need to configure the VPN client on a PC, and here’s Meraki’s how-to. The guidance is straight forward, but I was first tripped up by a Windows 7 machine that absolutely wouldn’t work despite proper VPN settings (I’ve done a lot of VPN administration through the years, have never seen anything like this one odd Win 7 laptop). Once you get the PC set up and connected to the MX with client VPN, you have to be mindful of what you’re doing between networks.
NOTE: My home network also happens to be 192.168.1.0/24- just like the farm. This creates a routing problem going from my home network to the farm network over VPN, as I need to “come in” to the farm network from a differently numbered network (you’ll see why in a minute). I could solve this multiple ways- like by re-addressing my home network, adding a second VLAN/IP space to use for administering far-away 192.168.1.0 networks, or tethering to my 4G phone that uses a different IP space on the “inside” when I’m at home). Just know that 192.168.1.0/24 can’t client-VPN off to another site and then be used to administer the same 192.168.1.0/24 IP space on the far end (not easily, at least).
The last step in the process that allows me to reach into the private farm network with client VPN is to configure a static route that points my traffic to the farm’s 192.168.1.0 network via my connected VPN interface (in this case 192.168.19.148). The following shots show me 1.) connecting to the farm from a public network with VPN address 192.168.19.148, 2.) adding the static route in Windows and 3.) then both ping and trace route to farm network router at 192.168.1.1.
If this seems complicated, it’s not. It takes minutes. From here, anywhere in the world, I can administer and monitor the devices on the farm as if I were standing there in the front office. Of course, PC configurations like Remote Desktop still need to be correct if that service is needed, but I’ve used the method described here to change printer settings, check on bridge links from the bridges themselves, and to find devices on the network that had been moved- all remotely and without travelling to customer sites. I know that this isn’t exactly cutting edge or exclusive to Meraki, but I haven’t seen a client VPN setup as easy as with the MX, myself. Well done, Meraki.
wirednot 
Pingback: Newsletter: October 3, 2015 | Notes from MWhite
OMG that looks like a pain in the ass. I guess for a small environment this would work, but management is oddly years behind Cisco’s ASA platform and anyconnect. On that platform you add the route in your split tunneling routes and you’re done.
Hi Jim- to each his own. I do some ASAs as well, and find them overall to be a laborious pain in the ass. The client VPN thing is just one part of Meraki’s overall thing, not the end-all in itself. But, different solutions strike each of us in different ways, and that’s okey-doke.
Thanks for reading and for your thoughts,
Lee
I actually found the issue with my attempts. The Internet connection i was using was being NATted viat the same MX firewall that I was trying to VPN into. So in essence I was being NATted behind the same IP that the VPN connection was being initiated on. Once I switched to a different Internet connection it worked fine.
The joy of private addresses!
I’m having an issue with Windows 10, i’ve made all the correct configurations & It just won’t work. I’ve contacted support, i’ll update if i get a resolution.
Quick question – is the dairy’s public IP address static or dynamic?
I am looking into implementing VPN connectivity with a Meraki MX and currently we do not have a public IP address.
I have both, though mostly static. Where dynamic, the dashboard always tells you what it is in case you need to change VPN config.
Worth noting that the MXs feature a dynamic hostname at dynamic-m.com that you can use for connections if you have no static IP.
Great ideas!
How would you do this (from your blog):
‘adding a second VLAN/IP space to use for administering far-away 192.168.1.0 networks’.
What would that look like? And would this circumvent having connectivity issues when on a private network (like at home or somewhere else using. 192.168.1.0/xx) on the outside of the network you’re trying to remotely manage?