New firewall recommendations

I know this question gets asked frequently but every network is different.

We have tried and tried to make our Meraki MX84 work for our network and it has let us down again. Our main issues are on failover between WAN1 and WAN2 and the traffic shaping policies just not working correctly. When we had Sonicwall I had much more granularity on how I wanted to shape traffic and how I wanted failover to work. These are the primary things I’m looking for.

  • Advanced Traffic Shaping (that works) and ability to shape/limit at Layer 7 as well
  • Failover that allows me to choose what I want to fail over (not all or nothing). I’m fine if in a fail over situation if the guest wi-fi doesn’t work.
  • Central web management for multiple firewalls
  • Performance monitoring - We had WhatsUp Gold before with Cisco and Sonicwall but it didn’t work on Meraki. I’d like something similar built into the firewall.
  • More performance - I don’t want to have to buy 2 or 3 x the size box that I need just to turn on the features I pay for or be told that I need a larger device to handle the traffic.
  • SD WAN
  • Easy site to site VPN (Like Meraki)
  • Solid reliability - I need good hardware and software reliability. We haven’t run hot standby and it’s going to be hard for me to justify the jump to two units, but I’ll do it if the price is right.

Right now I’m just looking to replace the 2 MX84’s that I have but may replace the 6 other MX64’s if it works out well.

Right now this is our setup for each campus:

  • 200-300 clients max at any given time.
  • Lots of Dropbox traffic on the weekend that I need to manage and not take all bandwidth
  • Living as One broadcasting and receiving at site.
  • 50 x 50 Mbps Comcast Fiber (mainly for Living as One. Will be upgrading bandwidth soon)
  • 100 x 20 Mbps Comcast Coax (everything else. Also used in failover situation)

Thanks in advance for any recommendations!

I’m not aware of any firewall product that does

  • Failover that allows me to choose what I want to fail over (not all or nothing). I’m fine if in a fail over situation if the guest wi-fi doesn’t work.

or at least in the case where you’re failing over to a primary circuit. You’d need a tertiary circuit to accomplish this type of failover.

Honestly, what I’m seeing here looks mostly like misconfiguration and a slightly undersized device. (MX84 is sized for 200 maximum users and a 500 Mbit WAN, so you’ll see high CPU if you’re doing 300 clients and trying to shape traffic heavily). Additionally, depending on your content filtering has a higher performance penalty. A bit of config tweaking and some more bandwidth is likely all you need to get this working well.

1 Like

I have a reasonable number of MX devices in the field. Mostly 68s/84s/100s. I can confidently say that we have yet to see a circumstance where Meraki’s sizing guidelines were anything less than accurate. More so than any other vendor I have ever worked with, in fact.

Your failover request isn’t available in the way you describe from any provider. Those who want it essentially get it by putting a big leaf or similar between their firewall and WAN connections. Failover in general works very well on Meraki, at least as well as any other product I have used.

Setting aside failover, for what your feature requests are the closest thing you will get is Meraki. What you give up will be L7 traffic shaping - but that’s resolvable in other ways.

If you are unwilling to give up L7 traffic shaping, then you want a Palo Alto box, probably a 820-TP-URL4-WF-BKLN-3YR based on your description. Here you won’t get “easy” S2S VPN, web management, or SD-WAN as you would describe it in Meraki.

Meraki is as reliable as anything else. If you are not pleased with the reliability there, then you’ll want an HA setup of anything you choose.

If I were you I’d upgrade your primary connection to 250mb (or better). Based on every experience with church IT I have ever had - that’ll be a more appropriate circuit size for your use case. Then if you are still having problems demo (for free) an MX100. If you don’t like that either go back to something like an FG-100E or the aforementioned Palo 820.

Note that if you change your primary campus firewall(s) from Meraki to something else, you’ll likely want to change all other firewalls at the same time.


1 Like

Thanks for the quick replies! I’m fairly confident that I had a setup on Sonicwall before where I selective failover and probes. I will have to fire up our old SonicWall and see if I can find that.
I did hear back from Meraki and they said there is a beta feature they can enable to allow the primary internet to fail to Cellular even though one doesn’t exist. Essentially stopping traffic from failing over to WAN2.

I am working with them again on traffic shaping. Even though I have set the rules up as they suggested before they don’t work correctly.
The last time we had issues with LAO, it was because our ISP was dropping burst traffic and the MX wasn’t shaping it correctly (and still isn’t).

Traffic shaping is incredibly demanding on any system, and any appreciable amount of traffic in shaping will cause you to have to derate the hardware for performance by a significant degree.

That said, the problems you are describing here are an undersized WAN circuit. Comcast will only be dropping your “burst” traffic if you have too much of it, or are hitting it consistently.

Everything you are describing here is correct. Meraki does not, and should not, instantaneously hard clamp on bandwidth utilization. Comcast does not, and should not, allow prolonged communications above rate limit. Saturating your bandwidth absolutely should cause packet loss.

Correctly size your circuit (including appropriate margin) and not only will your problems go away, but the above behaviors will serve to improve the experience and reliability across your use-cases.

I often times these days see bandwidth sizing recommendations as 1mbps/device. Where devices mean every connected system. Be that laptop, tablet, desk phone or thermostat. While this is a nice simple number, I don’t always find it works well in churches.

For you I would size based on 10mb/s per video stream*, 4mb/s per security camera**, 1.5mbp/s per staff member, .5mbp/s per simultaneous guest, and .1/mbps per connected other “thing” ***, these numbers include margin, etc.

(desk phones, printers, network connected

  • LAO or church online stream
    ** Which can be remotely accessed, be that as S2S VPN, remote-view apps, or centralized recording
    ** Desk phones, printers, network connected AVL gear - essentially take the total network clients, and then remove any you have already counted.

So if I have 2 video streams, 20 cameras i view remotely, 30 staff, 300 simul-wifi-guests, and 150 “other” devices that would be (2x10)+(20x4)+(30x1.5)+(300x.5)+(150x0.1) = 460mbp/s.

In reality my experience tells me that I would likely be fine with ~300 mbps, but the cost difference between 300mb and 500mb isn’t much these days, so in reality if my math puts me over ~325mb I go to a 500mb circuit.

To expand on that even further, if my math puts me between 0~150mb of “needed” bandwidth, I use a 100mb circuit. If my math puts me between 150~325mb I go to 250mb. Between 325~550 I go to 500mb. Above 550 I go to gig. Above 1200 I go multi-gig as appropriate.

Anyways - your WAN is undersized.


tl;dr: traffic shaping is for handling traffic peaks. If you’re experiencing sustained saturation you’re into exotic territory. There are technical methods of dealing with this, but first and foremost you need to understand how shaping works (by discarding packets). Generally speaking, you expect to drop packets of all priorities during congestion - but lower priorities will drop more packets.

The strategy I use for traffic shaping is to keep things simple and don’t worry about maximizing your bandwidth constantly. Cap and Prioritize.

For example, file sharing & sync can always be treated as low-priority traffic and likely should be capped to no more than 20% of your circuit’s capacity. Video streaming (youtube & co) can safely be capped to 3 mbit/user for 720p and 1.2 for standard definition. The reason to limit low priority traffic is that it improves quality of experience for low priority traffic. Rather than having bandwidth jump up and down during congestion, you get predictable transfers and fewer window size changes and less overall packet loss. It also leaves “space” for normal and high priority traffic without them fighting for buffer and experience increased latency.

High priority traffic should always be limited as well. For example, Voice over IP can be limited to ~120 kbit/user. This prevents buffer-filling operations from collapsing the TCP connections of lower priority traffic.

Meraki support can help you with the implementation of shaping but not the theory of shaping or network architecture. If you aren’t able to size up your Fiber line to support your needs, bringing in something like Bigleaf alongside an increased Coax line can get you a bit more granular control on a per-packet basis while having really sane out of the box defaults.

Hi Jeremy-

We’re using Untangle Firewalls ( in our environment and I have been pleasantly surprised. Untangle was a significant cost savings for us and their service has been awesome. They have non-profit pricing available and other than SD WAN (which I know it does we just don’t use), everything you listed I’m currently doing.

Obviously it doesn’t have the name recognition of Meraki of Sonicwall, but I have been pleased. We have not problem with traffic shaping with 5 outbound streams and usually 500 clients on a normal Sunday.

Let me know if you have any questions - I’m happy to demo our setup.


We switched to Fortigate and have been really happy with their products. Offer SD-Wan, layer 7 traffic shaping, you can buy product to manage all from cloud, easy site-site vpn. Corporate Armor has them on sale right now,

Alex, I had more buckets for traffic but found that they didn’t work any better so we paired them down to High, Medium, and Low priority buckets and assigned priorities. I do not have any bandwidth limits on them. If things get congested, should the queues kick in and prioritize traffic accordingly? It doesn’t appear that Meraki has any sort of bandwidth reservations, just bandwidth caps. On Cisco and Sonicwall firewalls I’ve used before you could set a guaranteed bandwidth and it worked pretty well. I will check with Meraki to see if they recommend setting some limits.

I am working with meraki now and they did inform me that they have a feature in beta that they can turn on that will allow my WAN1 (which is the coax) to fail over to Cellular (which I don’t have) and that will effectively prevent WAN1 from failing to WAN2, but WAN2 can still fail to WAN1. I’ll test after they set it up and see if it works.
I learned something else about the failover as well. It will take 5 minutes for the MX to realize at a WAN link is dead if the port doesn’t physically go down before it will fail over to a secondary WAN. This isn’t great news since we don’t run Living as One at a 5+ min buffer. They also said there is no way for me to change it or them either.

Watchguard firewalls do allow for per policy WAN failover. Been using this for our WAN failover which is a similar setup. I don’t know if there is a way to disable the guest connection in the event of a failover, but it’s been a while since I looked into this.

Watchguard Knowledge Base

I just noticed that you mentioned central web management, which I don’t believe Watchguard has. My bad.

Thanks Joshua! It looks like Watchguard has replaced that feature with SD-WAN. From reading though it looks like it does one key thing that Meraki doesn’t do in their SD-WAN, allow you to apply policies to external traffic. The Meraki SD-WAN should really be called SD-VPN because their policies only apply to VPN Traffic. You can’t for example, tell Meraki to take the lowest latency path to AWS if you have 2 WAN connections.

I did just get off the phone with Meraki though and I think we got the selective failover working now. I’m going to test it tonight.