Meraki - not impressed

[Gordon]

So this is my story regarding Meraki.   Our Cisco rep suggested we look Meraki firewalls as a replacement two years ago.  It took us two months to be able to configure them and use them.  This was working with both Cisco and Meraki technicians.  We have what we thought was a fairly simple architecture.  Two Ciscos 3850 switches (not stacked) and two Meraki mMX84 firewalls.   We wanted to ensure complete redundancy in case of hardware failure.  That took two months to get a configuration to work.  The documentation provided by Meraki did not work.  I see it has since changed.

Now we have been having other issues.  The first case I opened was in regards to problems with bandwidth.  We are not getting the bandwidth on these firewalls that we should.   The tech that worked on the case had me upgrade the firewall to pre-release firmware and when that did not work did an RMA.  There was no other troubleshooting done.  I then opened a ticket because I was working on our firewall rules and needed a way to verify each rule.  I was told by the tech that it wasn't possible.  I tried pushing the issue and finally had to tell him to close the case.  I opened an second case and the tech immediately told me how to check the syslogs and verify the rules.  

The last case I opened was because when our firewalls failover it is not working properly.  I was told the tech would have to view a failover to see what was happening.  I scheduled an after hours outage for it and notified support.  I was told just to call in.   I called in and sat in a queue waiting for a tech for over an hour and finally gave up.  I don't believe that when you are calling in to tech support that over an hour on hold is an acceptable level of support.  

The part that concerns me is that Meraki does not seem to be concerned over over any of this.  If we hadn't purchased five year licensing with these firewalls I probably would be looking at replacements rather than support at this time.

[Jwiley78]

Sucks to hear that.  We have about 30 clients that are all 100% Meraki.  I've never had any issues with support and find them just as good as Cisco support.  Hopefully they can get your issues fixed and you can get a better opinion of their product.

[PhilipDAth]

That is a pretty bad experience.

It sounds like the Cisco partner that helped with the deployment didn't quite know enough to help you make a smooth transition.  We've only had great experiences.

[Gordon]

It wasn't the Cisco partner it was Meraki.  The documentation they supplied was wrong and it took two months to convince them of that.  They changed the documentation.

[PhilipDAth]

It sounds like the Cisco Partner hadn't done that kind of deployment before.

The documentation being wrong is not good either.  It just makes your experience worse.

[merakichamp]

@Gordon  really sorry for that experience, but i have followed through the number of issues you have just raised  i can tell you they are workable you just needed some deep understanding on how meraki devices and there configurations work i won't speak for meraki support here but i would advice you sometimes when you have such issues it is better to put them here in the community first you will get answers from different people who might have faced the similar issues  

 and got them solved am not saying you should not involve the support but always try this platform also.... just my suggestion. .

[Gordon]

Well I have been posting a lot to the forums about trying to get these firewalls to work for me.  I have yet to actually get an answer to any of them that works.

[cmr]

@Gordon what exactly isn't working, we have ~25 MXs and although we don't do anything too complex with them, they do do what we need.  We do also mainly use them in HA pairs connected to 3850s (but they are stacked).

[Gordon]

- When a failover occurs a GARP is not sent for the 1:1 NATs therefore in the case of a failover anything that uses our 1:1's stop working

- The hit counters on the firewall rules don't work.  I have verified this and also have confirmation from tech support.

Client VPN.  There isn't a way to apply different rules to users since you can't assign a static IP to a VPN client and the MAC address is not registered on the firewall so you can't apply a group policy to it.  I tried but soon found out that these policies were being randomly assigned to different systems.

No way to positively verify that firewalls rules are working as intended.  We have a large number of rules since we deal with not only our own network but with two clients that connect directly to use and they each have over 10 subnets.  I have spent countless hours trying to make sure that these rules work.  The answer is to send them to syslog but try and work with thousands of syslog messages to determine you haven't missed something.

Cosmetically they are horrible as well.  Firewall rules are hard to read since you can't see everything in the little boxes they have.  I am constantly coping and pasting to and from notepad just to view a firewall rule.

Failover order doesn't make sense.  At least not to me.  

Primary WAN1

Primary WAN2

Secondary WAN1

Secondary WAN2

This means that if something happens to the connection on the Primary WAN1 port the system fails over to the WAN2.  Our WAN2 port is our cellular backup, not our first choice.  I don't think many users will have a high-end secondary ISP connection.  

It just seems every time I try do something with these firewalls it is either very difficult to implement, it isn't supported or doesn't work.   I have a Meraki firewall in a clients office and it is great there.   It is a small office with very few firewall rules or anything.  It is good if you just want a simple setup.  As soon as you try anything complicated you start running in to problem.s

[cmr]

@Gordon I'd have to agree about the Client VPN, we are waiting for the AnyConnect rollout before looking at moving our client VPN users from our existing solution. Our reseller advised against MXs for client VPN at the moment so it wasn't a surprise but it looks like you were misled.

The 1:1 GARP issue seems odd, are you saying that if you have an HA pair and a 1:1 NAT, when the device fails over the 1:1 stops working until the ARP table is cleared or refreshed?

For hit counters I always only use them as a 0 or something, I dont think I've ever used a firewall where the are accurate and I'm not sure why you'd worry?

There are free syslog servers if you don't have a budget, but there are all sorts of reasons to have one and they are generally much better for checking rule actions than firewall logs, many times on logs from assorted vendors I've not seen what I'm looking for only to find it in the syslogs.

Failover order makes sense to me as the likelihood of the patch cable between the WAN switch and one of the MXs failing is far less than an issue on the rest of the ISP connection.  ISP failover is seamless whereas HA failover,  despite being relatively good, is not.

I do agree about simplicity though, I'm waiting for the firewall objects to be widely available before making some changes to ours. 

To be honest the only firewall interface I have ever really liked is the Sophos XG and it looks like that is changing to be more like the awful ASA interface in v18...

[PhilipDAth]

>- When a failover occurs a GARP is not sent for the 1:1 NATs therefore in the case of a failover anything that uses our 1:1's stop working

I haven't run into this issue before.  I'm guessing whatever upstream device you are using is requiring this.

>- The hit counters on the firewall rules don't work.  I have verified this and also have confirmation from tech support.

Agreed.

>Client VPN.  There isn't a way to apply different rules to users since you can't assign a static IP to a VPN client and the MAC address is not registered on the firewall so you can't apply a group policy to it.

Negative.  I do this all the time.  You get the user to VPN in once (I typically do it myself the first time to test everything is working and they are getting the correct access), and then apply the group policy to that connection.  The group policy is applied against the user, not any MAC address in this case.  Then you use group policy firewall rules to control what they can access.

>No way to positively verify that firewalls rules are working as intended.

Agreed.  I wish this was better.

>Failover order doesn't make sense.  At least not to me. 

I guess this is a matter of perception.  The idea is that the warm spare does not kick in unless the primary unit has failed.  That can either occur because the physical unit has failed, or it has lost all connectivity to the Internet.

Typically you connect your primary circuit to both MX units, but this does require a routed /29.

In your case, you should plug your two best circuits into your primary MX, and your backup circuit into the warm spare.

Ageed - they are difficult to use a DC style environment.  They have a particular vertical feature set, and they work great in that vertical.  Once you start going outside of that things get tough or you have to make compromises.