cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6469
Views
30
Helpful
11
Replies

Pros/Cons: Migrating from Cisco to Meraki cloud

Jim Mueller
Level 1
Level 1

We have around 150 remote offices, each with at least two broadband connections; the original goal 10+ years ago was to use separate connections (one for staff and 1+ for customers) to minimize cross-traffic affecting performance and stability. Our organization is moving more services to the cloud where it makes sense for us, including the primary web application that all those remote offices use and Exchange Online later this year. We were looking at enabling split tunneling (see thread below for redacted configs for our environment). My concerns for this thread are how the security and firewall solutions compare... what would we be sacrificing by moving away from the end-to-end Cisco solution to the Meraki cloud solution?

https://supportforums.cisco.com/discussion/13197551/enabling-split-tunneling

Our management team has been discussing methods to reduce costs and ease administration with our VAR. The thought process was to consolidate the multiple broadband connections at each remote office into a single connection (and increase capacity if necessary), consolidate our multiple WAN devices (this includes one Cisco 1711, 1811, 891 or 891F per office) devices into a single WAN device, and limit the bandwidth to the customer connections using QoS. The remote office staff connect to the rest of our environment using IPsec over GRE to our core datasite location. At our core location, we use a pair of 4431's (recently purchased to replace older units) to terminate all those tunnels; each 4431has a dedicated circuit to a different vendor. All the internet traffic has a single egress point from the datasite (see attached diagram).

The way we understand, we would eventually need to deploy a single Meraki MX65W at the remote office, and a pair of MX400s at the datasite. It's not clear to me how we would keep both environments functional during a potential migration process.

If we simply add split tunneling to our existing remote office environment, we lose the ASA firewall features of the single egress point. If we put in a hardware solution such as the Meraki which includes it's own firewall solution (hardware- or cloud-based) then at least we have another firewall at the remote location but I'm concerned that remote Meraki firewall would not be as robust as the ASA.

We've had instances in the past where our customers violated the DCA act and the ISP did a soft shutdown on the service until we updated the firewall rules for that connection (not a Cisco device). So I don't want customer activity to impact the staff's ability to work. What would be your security concerns about moving from our existing remote office environment to one based upon the Meraki cloud? Any other suggestions are welcome.

Jim

1 Accepted Solution

Accepted Solutions

The "Advanced Security" licence enables AMP (to stop malware) and content filtering.

Meraki have their own API, and lots of other providers offer integrations.

The local status page provides only very basic information.

I only use Cisco products.

View solution in original post

11 Replies 11

Philip D'Ath
VIP Alumni
VIP Alumni

I have done a tonne of Meraki installations.  Most of them have been migrations from iWAN/DMVPN.  The vast majority of them were for branch connectivity.  A lot of them were related to companies moving things to the cloud, or wanting to use local Internet break out.

Sound familiar?

I typically use MX65's and separate MR42 access points.  The access point built into the MX65W is retarded compared to a standalone access point.  It's like loosing 90% of the access point capability.  If you just want simple corporate access it is fine.  If you want to provide guest WiFi and things like that - stick with a standalone access point.

All my installs use "Advanced Security" licences.  This means they all have Cisco AMP - like Firepower uses, but with most of the configuration options removed.  It is really good.

A Meraki MX is most comparable to an ASA running Firepower.  If you are not using Firepower, then the Meraki MX with advanced security is considerably superior to the ASA.

I still tend to use ASA's for the main corporate Internet connection, and for user to site VPNs - because ASA's are much better than Meraki MXs at this.  Cisco Meraki MX's make doing branch to branch VPNs trivial - but they are horrible for other site to site VPNs.  So I tend to do site to site VPNs off the main corporate ASA, and keep the Meraki MX's just for branch connectivity and branch Internet access.

For the migration configure your MX's to work just like your current environment.  Migrate the branches across as fast as you can.  Use simply static routing at your main office to route stores cut across to Meraki via your head office MX units.  Don't bother with dynamic routing for less than 200 branches.

I strongly recommend you use Organisation Templates.  This makes sure every branch is identically configured (except for IP address) - without exception.  Then if you want to block something (say Social Media) you simply add this firewall rule to the template, click save, and about 60s later every branch will be running the new firewall policy.  It also makes it easy enabling external access to things like Office 365 consistently across every branch.

Once you have all the branches running Meraki MX then start making environment changes, such as allowing direct access to Office 365, direct Internet access, etc.

Unless you are planning an explosion in the number of branches a pair of MX100's would be more appropriate size wise.  The MX400's cost a lot more, and it doesn't sound like you need the additional capacity.

I might have told a lie.  The MX100 has a limit of 250 VPN peers.

If you plan to use a single Internet connection per office, then you would have 150 VPN peers.  If you have dual ISP connections, and configure Meraki to make them active/active rather than active/standby then that would cause 300 VPNs to be built at the head end.

So if you are wanting an active/standby VPN configuration at each branch, then MX100 will be fine.  If you want to use dual VPN connections (such as for load balancing) then you'll need the MX400.

Excellent information, thanks Philip!

For the remote offices, we are discussing the use of a single broadband connection with a pair of site-to-site tunnels terminating at two separate MX's at our datasite for the office staff. The same MX may (depending upon the office) also handle a wired connection to a 'business center' for customer use, and/or may also have up to two SSID's, one for secure corporate use and another for customer use. If a single broadband connection causes a design issue then we'll continue using the multiples we have now.

The current remote routers have a v.92 line which we use for out of band management, so we'd like to keep that ability by adding the 4G failover on the remote office for OOBM and/or failover for the staff. However, I've just now been told that cell service inside the remote offices is notoriously weak. The remote office equipment is all stored in a dedicated indoor closet without any windows.

This is the first time we'll have deployed 4G as a failover, any other concerns we should be aware of? Any way to add a 3G/4G antenna to the outside of the building and connect it to the Meraki for better signal strength? If we cannot make the 3G/4G reliable, we may need to punt on the remote failover & OOBM ability.

How do the integrated -W units compare with the dedicated units regarding the ability to mesh additional AP's together to expand coverage?

We do technically have FirePower with our active/standby ASA's, except it was taken out of production due to a policy problem that was never resolved.

I've read that the internet access is dependent upon having an active license/subscription for the device. Does that mean if we allow the license/subscription to expire then the remote office would be hard down until the license/subscription was renewed?

Where do we physically place the MX concentrators in our current network design diagram? Meraki said to place them "behind our 4431's" but that is a little vague to me.

With Meraki Guest Wifi you can simply tell it to limit the Guest WiFi bandwidth to x Mb/s.  So sharing a single pipe is not an issue.

You mention about the MX being inside of a closest and having poor 3G coverage.  For reasons of providing a highly configurable guest WiFi network, and to provide reasonable signal I would definitely use a standalone access point.  Then you can put the access point in the middle of the users - instead of where the telco circuits come into the building inside of a closest.

I don't believe the built in APs support meshing at all.  Only the external stand alone APs have this function.

I have used 3G/4G backup a lot. You just plug a supported "stick" into the USB port on the MX. You can use a USB extension cord to move the 4G stick further away, but you probably wont be able to get it outside of the building.

Correct, if the licence expires the device will stop forwarding packets.  I typically sell customers a 5 year licence up front.  First you get a massive discount for a 5 year licence.  Then I tell the customers to replace the units after 5 years.  There will be much better technology then.  This way you just consider the licence part of the purchase price.

I can't really comment on placement in your current design without knowing a lot more.

What did you mean earlier when you said, "This means they all have Cisco AMP - like Firepower uses, but with most of the configuration options removed. " I'm confused that they have AMP-like features but are missing options?

When you stated, "I still tend to use ASA's for the main corporate Internet connection, and for user to site VPNs - because ASA's are much better than Meraki MXs at this.  Cisco Meraki MX's make doing branch to branch VPNs trivial - but they are horrible for other site to site VPNs.  So I tend to do site to site VPNs off the main corporate ASA, and keep the Meraki MX's just for branch connectivity and branch Internet access." What we have now are hub and spoke site-to-site VPNs between the remote office router and the 4431's at our core site. The remote offices can connect to one another, but not directly. If the goal is to keep this design, I'm inferring from your comments that the MX's are horrible for site-to-site VPNs and are not a good fit for us?

With AMP on ASA's, you can configure a million parameters.

On MX you can enable it/disable it, set it to IDS or IPS, and choose between three rules sets "connectivity, balanced and security".  You can also whitelist things, in case something gets blocked that should not.

You also have content filtering.

The Meraki's are fine for what you describe.  You are doing simple branch to branch connectivity.

I forgot to mention that certain remote offices use Cisco LWAPP's connected to a core Cisco wireless controller. Would those AP's continue to function or would they need to be replaced also? What do you think of the MR32 vs MR42?

Yes, the WLC and its APs would continue to function.

If you can afford it, buy the MR42.  If you can't, buy the MR33.  Note the MR32 has been replaced by the MR33.  You shouldn't use MR32's anymore for new installations.

The features included with the Advanced license... are we allowed to integrate with other 3rd-party vendors for those features for those filtering mechanisms? Or are we restricted to using the services provided by Meraki Cloud?

If the internet is down at the remote office, I see that a status page is available to local LAN or AP clients. How robust is that status interface compared to the cloud console?

Do you have any experience with FortiCloud, Palo Alta or Cyberoam as they compare to Cisco & Meraki for our desired environment?

The "Advanced Security" licence enables AMP (to stop malware) and content filtering.

Meraki have their own API, and lots of other providers offer integrations.

The local status page provides only very basic information.

I only use Cisco products.

For 3G/4G asa  fail back we ran into the issue that it takes roughly 30 seconds. This was to long for us. We eneded up going with a vendor that provides a 3G/4G module that has etherenet connection capablites. This with an antenna amplifier made our backup connection reliable and available as soon as the primary connection goes down. 

 

https://www.inseego.com/product/sa-2100/

 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: