Barracuda vs Meraki - firewalls
-
While the discussion doesn't have to focus only on Meraki vs. Barracuda, the only thing mentioned other than a casual "if you need to spend money, buy PAN" has been a profound "anything other than UBNT is a huge waste of money".
While I deploy UBNT for many orgs, it isn't the only solution. It doesn't even fit with this deployment. Does UBNT offer a comprehensive firewall? No, USG is garbage. Captive portal offering sucks, zero hand off is buggy at best, limited support, and limited warranty. Can't manage multiple CloudKeys under one portal, no WIDS/WIPS from what I've looked at (handled by separate system). But, it's reliable, inexpensive WiFi; I especially like their point to point wireless gear for campus buildings for either primary or failover.
What about Meraki firewalls are "underpowered"? Of course, you have to size according to the need. If it's underperforming, it's the wrong appliance for the application. Someone had pointed out in another discussion that a MX84 throughput is 500Mb where a competitor was rated at 1Gb. But the competitor was listing as stateless, and Meraki was listed as stateful. Comparing stateful, they actually were rated as higher throughput.
I love PAN, but they also have their problems. I've witnessed some of their more expensive firewalls literally (physically) melt down in front of us. But, there are many cases where PAN fits nicely into a given solution.
So is that it... Nothing but UBNT to discuss? They have a solid product for a given application, but the needs of this project extend beyond those capabilities.
-
We have deployed 10 Meraki Mx 84 firewalls in a mesh VPN configbeith minimal fuss so far. Bandwidth on the tunnels between sites has been great and all. Where I have had issues was with content filtering turned on, some necessary ports over the VPN (port 587 to exchange server for our mfp devices) were blocked for no reason. Also the interface is not "logical" in that certain items are not obvious to where they are located.
Now we have added a MX 250 into the mix and it's VPN tunnel bandwidth is beyond poor it's dreadful. I have yet to open a case with Meraki as I'm still troubleshooting but it is nowhere near claimed capabilities; it is on a fiber delivered 1 gig circuit, I am getting less than 50 meg bandwidth. -
@jt1001001 said in Barracuda vs Meraki - firewalls:
We have deployed 10 Meraki Mx 84 firewalls in a mesh VPN configbeith minimal fuss so far. Bandwidth on the tunnels between sites has been great and all. Where I have had issues was with content filtering turned on, some necessary ports over the VPN (port 587 to exchange server for our mfp devices) were blocked for no reason. Also the interface is not "logical" in that certain items are not obvious to where they are located.
Now we have added a MX 250 into the mix and it's VPN tunnel bandwidth is beyond poor it's dreadful. I have yet to open a case with Meraki as I'm still troubleshooting but it is nowhere near claimed capabilities; it is on a fiber delivered 1 gig circuit, I am getting less than 50 meg bandwidth.That stuff is really good to know, thanks.
If you could go back and redo everything, whether it is a different (specific) manufacturer in mind, or different model within Meraki, or different architectural design, etc... What would you have changed, specifically?
-
I would eliminate the need for a mesh VPN and just go pure Internet/"Cloud" for everything. We are working our way towards that but at the time mesh VPN was the quicker option. I would have put my resources on moving to cloud and just needing very basic firewall/routing options for our branches.
-
@dustinb3403 said in Barracuda vs Meraki - firewalls:
ou can include your wireless equipment and optical GPON devices as well
My understanding is it manages their WISP targeted (AirMax) and EdgeSwitch and not their Commercial/enterprise focused UniFI. The edge line of firewall/routers also lack any layer 7 content etc filtering.
-
@jt1001001 said in Barracuda vs Meraki - firewalls:
I would eliminate the need for a mesh VPN and just go pure Internet/"Cloud" for everything. We are working our way towards that but at the time mesh VPN was the quicker option. I would have put my resources on moving to cloud and just needing very basic firewall/routing options for our branches.
While I agree with you (I only use VPN to get to a handful of things like R&D, and even then VDI is a better choice most of the time), there tends for IT people to be some things that need VPN. Sometimes replacing the HVAC management equipment is more expensive than setting up a VPN back to the main site.
It's also worth considering some sort of SD-WAN solution. One benefit to this is if you backhaul your internet pop to a central place you can centralize edge security and content filtering. Some of the SD-WAN systems are managed by the ISP leaving you with even less to mess with.
-
I won't do manage sd wan from the carrier ever again! Ask around here how much I love carriers!
-
@storageninja said in Barracuda vs Meraki - firewalls:
@dustinb3403 said in Barracuda vs Meraki - firewalls:
ou can include your wireless equipment and optical GPON devices as well
My understanding is it manages their WISP targeted (AirMax) and EdgeSwitch and not their Commercial/enterprise focused UniFI. The edge line of firewall/routers also lack any layer 7 content etc filtering.
Correct for UniFi devices, it will simply link you to the UniFi controller, while supplying minimal status information.
-
@jt1001001 said in Barracuda vs Meraki - firewalls:
I won't do manage sd wan from the carrier ever again! Ask around here how much I love carriers!
OH yeah, such a bad idea. Just a VPN that you don't control and pay a fortune for.
-
@scottalanmiller said in Barracuda vs Meraki - firewalls:
@jt1001001 said in Barracuda vs Meraki - firewalls:
I won't do manage sd wan from the carrier ever again! Ask around here how much I love carriers!
OH yeah, such a bad idea. Just a VPN that you don't control and pay a fortune for.
SDWAN is a hell of a lot more than VPN tunnels...
- Link bonding. Mix MPLS/Cable/T1/4G etc.
- Per packet routing. Have the same session use multiple links depending on requirements...
- Jitter management for the above. Can strategically use buffer bloat to make 2 similar segments match on one way latency (Inflate the lower link to match the higher one). This reduces the need for packet re-odrering (expensive from a compute basis).
- Per segment monitoring. Latency isn't symmetric. Using things like 2 party clock synchronization and packet tagging you can measure with packet stamps in real time the one way latency of a link (Critical to keep jitter under control).
- Automated rules engines with multiple factors that can even handle encrypted. Massive centrally collected rules engines based on destination IP, Ports, CNAME on SSL Cert for encrypted, packet headers if not encrypted etc.
- Packet loss mitigation. For bulk media store and re-forward to avoid TCP retransmits keep throughput up. More sensitive real time protocols that are narrower can benefit from duel transmit (send packet down both links) as well as parity injected into packet streams.
Reason why you would pay a 3rd party....
-
Management of hardware for disparate links. Someone to deal with all the 4G cards, Cable Modems etc.
-
Management of billing. Having to sort and verify through billing for 5 different carriers
-
Awareness of options and scale. WAN resellers who do this for a living tend to aggregate a lot more demand and can get better pricing, as well as already have the fiber maps and quote tooling backend hooks for the tier 1 players so they can quickly identify the best options for each site.
Here's the dirty secret about not wanting to deal with someone else reselling someone else's links.... You always are. Thats how the internet (and wireless Networks) work. Everyone is leasing lines and transit from everyone.
-
@storageninja said in Barracuda vs Meraki - firewalls:
@scottalanmiller said in Barracuda vs Meraki - firewalls:
@jt1001001 said in Barracuda vs Meraki - firewalls:
I won't do manage sd wan from the carrier ever again! Ask around here how much I love carriers!
OH yeah, such a bad idea. Just a VPN that you don't control and pay a fortune for.
SDWAN is a hell of a lot more than VPN tunnels...
- Link bonding. Mix MPLS/Cable/T1/4G etc.
- Per packet routing. Have the same session use multiple links depending on requirements...
- Jitter management for the above. Can strategically use buffer bloat to make 2 similar segments match on one way latency (Inflate the lower link to match the higher one). This reduces the need for packet re-odrering (expensive from a compute basis).
- Per segment monitoring. Latency isn't symmetric. Using things like 2 party clock synchronization and packet tagging you can measure with packet stamps in real time the one way latency of a link (Critical to keep jitter under control).
- Automated rules engines with multiple factors that can even handle encrypted. Massive centrally collected rules engines based on destination IP, Ports, CNAME on SSL Cert for encrypted, packet headers if not encrypted etc.
- Packet loss mitigation. For bulk media store and re-forward to avoid TCP retransmits keep throughput up. More sensitive real time protocols that are narrower can benefit from duel transmit (send packet down both links) as well as parity injected into packet streams.
None of those things are SD-WAN. Those things CAN be, but they CAN be part of non-SD-WAN too. A VPN can be required to do all of that. These kinds of assumptions are bad, because people get expectations of a technology that does not imply them.
-
@storageninja said in Barracuda vs Meraki - firewalls:
Reason why you would pay a 3rd party....
-
Management of hardware for disparate links. Someone to deal with all the 4G cards, Cable Modems etc. Solution looking for a problem, what management is needed here?
-
Management of billing. Having to sort and verify through billing for 5 different carriers Not a real thing, SD-WAN doesn't address this, you still have to pay all those people PLUS the sixth company, the one with the WAN.
-
Awareness of options and scale. WAN resellers who do this for a living tend to aggregate a lot more demand and can get better pricing, as well as already have the fiber maps and quote tooling backend hooks for the tier 1 players so they can quickly identify the best options for each site. This can be done without the SD-WAN, this is not really a benefit of the service offering but of going through a broker in general.
Here's the dirty secret about not wanting to deal with someone else reselling someone else's links.... You always are. Thats how the internet (and wireless Networks) work. Everyone is leasing lines and transit from everyone. Sure, but not really related to SD-WAN.
-
-
@scottalanmiller said in Barracuda vs Meraki - firewalls:
@storageninja said in Barracuda vs Meraki - firewalls:
@scottalanmiller said in Barracuda vs Meraki - firewalls:
@jt1001001 said in Barracuda vs Meraki - firewalls:
I won't do manage sd wan from the carrier ever again! Ask around here how much I love carriers!
OH yeah, such a bad idea. Just a VPN that you don't control and pay a fortune for.
SDWAN is a hell of a lot more than VPN tunnels...
- Link bonding. Mix MPLS/Cable/T1/4G etc.
- Per packet routing. Have the same session use multiple links depending on requirements...
- Jitter management for the above. Can strategically use buffer bloat to make 2 similar segments match on one way latency (Inflate the lower link to match the higher one). This reduces the need for packet re-odrering (expensive from a compute basis).
- Per segment monitoring. Latency isn't symmetric. Using things like 2 party clock synchronization and packet tagging you can measure with packet stamps in real time the one way latency of a link (Critical to keep jitter under control).
- Automated rules engines with multiple factors that can even handle encrypted. Massive centrally collected rules engines based on destination IP, Ports, CNAME on SSL Cert for encrypted, packet headers if not encrypted etc.
- Packet loss mitigation. For bulk media store and re-forward to avoid TCP retransmits keep throughput up. More sensitive real time protocols that are narrower can benefit from duel transmit (send packet down both links) as well as parity injected into packet streams.
None of those things are SD-WAN. Those things CAN be, but they CAN be part of non-SD-WAN too. A VPN can be required to do all of that. These kinds of assumptions are bad, because people get expectations of a technology that does not imply them.
Bullshit. Those things all together are what makes it SD-WAN instead of some random guy trying to say all of his Ubiquiti ERLs with IPSEC tunnels are SD-WAN, because they are not.
@StorageNinja is exactly right on this.
-
@jaredbusch said in Barracuda vs Meraki - firewalls:
Bullshit. Those things all together are what makes it SD-WAN instead of some random guy trying to say all of his Ubiquiti ERLs with IPSEC tunnels are SD-WAN, because they are not.
@StorageNinja is exactly right on this.SD-WAN in general simplifies management at large scale (and nore than just the devices, but also the links), optimizies performance in ways BGP, Shaping DSCP alone can't (and with a 1000x less work, no need for bespoke optimizations), enables unlimited choice on the WAN links without unlimited management hell as you try to deal with 10 different CLEC providers, and brings costs down for CPE gear (Virtualized, x86 rather than proprietary ASICs).
-
@jaredbusch said in Barracuda vs Meraki - firewalls:
@scottalanmiller said in Barracuda vs Meraki - firewalls:
@storageninja said in Barracuda vs Meraki - firewalls:
@scottalanmiller said in Barracuda vs Meraki - firewalls:
@jt1001001 said in Barracuda vs Meraki - firewalls:
I won't do manage sd wan from the carrier ever again! Ask around here how much I love carriers!
OH yeah, such a bad idea. Just a VPN that you don't control and pay a fortune for.
SDWAN is a hell of a lot more than VPN tunnels...
- Link bonding. Mix MPLS/Cable/T1/4G etc.
- Per packet routing. Have the same session use multiple links depending on requirements...
- Jitter management for the above. Can strategically use buffer bloat to make 2 similar segments match on one way latency (Inflate the lower link to match the higher one). This reduces the need for packet re-odrering (expensive from a compute basis).
- Per segment monitoring. Latency isn't symmetric. Using things like 2 party clock synchronization and packet tagging you can measure with packet stamps in real time the one way latency of a link (Critical to keep jitter under control).
- Automated rules engines with multiple factors that can even handle encrypted. Massive centrally collected rules engines based on destination IP, Ports, CNAME on SSL Cert for encrypted, packet headers if not encrypted etc.
- Packet loss mitigation. For bulk media store and re-forward to avoid TCP retransmits keep throughput up. More sensitive real time protocols that are narrower can benefit from duel transmit (send packet down both links) as well as parity injected into packet streams.
None of those things are SD-WAN. Those things CAN be, but they CAN be part of non-SD-WAN too. A VPN can be required to do all of that. These kinds of assumptions are bad, because people get expectations of a technology that does not imply them.
Bullshit. Those things all together are what makes it SD-WAN instead of some random guy trying to say all of his Ubiquiti ERLs with IPSEC tunnels are SD-WAN, because they are not.
@StorageNinja is exactly right on this.
Nope. SD-WAN exists without any of those. And I never said that they were. But SD-WAN existed and was standard before anyone associated these things with them. This is like claiming you need all of the things in a UTM to be a firewall.
Lots of SD-WAN products don't offer these features.
-
@storageninja said in Barracuda vs Meraki - firewalls:
@jaredbusch said in Barracuda vs Meraki - firewalls:
Bullshit. Those things all together are what makes it SD-WAN instead of some random guy trying to say all of his Ubiquiti ERLs with IPSEC tunnels are SD-WAN, because they are not.
@StorageNinja is exactly right on this.SD-WAN in general simplifies management at large scale (and nore than just the devices, but also the links), optimizies performance in ways BGP, Shaping DSCP alone can't (and with a 1000x less work, no need for bespoke optimizations), enables unlimited choice on the WAN links without unlimited management hell as you try to deal with 10 different CLEC providers, and brings costs down for CPE gear (Virtualized, x86 rather than proprietary ASICs).
These might be common features of a certain type of SD-WAN, but come from things outside of the SD-WAN itself. It's like confusing an implementation with the concept. If you look at Windows, you might think that an OS means a GUI because a few major implementations tie the two together, but that woudl be wrong because DOS didn't have a GUI but was an OS.
-
From Wikipedia: "SD-WAN is an acronym for software-defined networking in a wide area network (WAN). An SD-WAN simplifies the management and operation of a WAN by decoupling (separating) the networking hardware from its control mechanism. This concept is similar to how software-defined networking implements virtualization technology to improve data center management and operation."
Notice that what it IS does not guarantee or even suggest any of those things. You are working form revisionist marketing material and not what an SD-WAN actually is. Very dangerous because it makes it trivial for salesman to sell you an SD-WAN with you thinking that they sold you all this stuff, and get nothing. And they did nothing wrong, because they were being honest.
-
@scottalanmiller said in Barracuda vs Meraki - firewalls:
From Wikipedia: "SD-WAN is an acronym for software-defined networking in a wide area network (WAN). An SD-WAN simplifies the management and operation of a WAN by decoupling (separating) the networking hardware from its control mechanism. This concept is similar to how software-defined networking implements virtualization technology to improve data center management and operation."
Notice that what it IS does not guarantee or even suggest any of those things. You are working form revisionist marketing material and not what an SD-WAN actually is. Very dangerous because it makes it trivial for salesman to sell you an SD-WAN with you thinking that they sold you all this stuff, and get nothing. And they did nothing wrong, because they were being honest.
Or keep reading the wikipedia article and see that I was largely describing the feature section....
I'll argue it's pedantic to try to separate SD-WAN from Hybrid-WAN at this point as (the majority) of deployments of SD-WAN will be Hybrid-WAN. Wayyyyy to much of IT spend in companies is telco's, and the combined technologies are going to do what virutaliation in x86 did to compute, and what HCI and cloud is doing to storage.
-
To get the topic somewhat back on the rails, @bbigford I have enjoyed working with Juniper. They have at least feature equivalence with Cisco and a significantly better engineered OS (based on FreeBSD). Their pricing is significantly better than Cisco (although not in the same range as Ubiquiti).
-
@storageninja said in Barracuda vs Meraki - firewalls:
@scottalanmiller said in Barracuda vs Meraki - firewalls:
From Wikipedia: "SD-WAN is an acronym for software-defined networking in a wide area network (WAN). An SD-WAN simplifies the management and operation of a WAN by decoupling (separating) the networking hardware from its control mechanism. This concept is similar to how software-defined networking implements virtualization technology to improve data center management and operation."
Notice that what it IS does not guarantee or even suggest any of those things. You are working form revisionist marketing material and not what an SD-WAN actually is. Very dangerous because it makes it trivial for salesman to sell you an SD-WAN with you thinking that they sold you all this stuff, and get nothing. And they did nothing wrong, because they were being honest.
Or keep reading the wikipedia article and see that I was largely describing the feature section....
Yes, but you were describing possible features as defining characteristics which are wholly different things. That's how sales people trick customers all the time. Customer things X means Y, sales people know this is a common misconception, they promise X knowing the customers wants Y, customer is at fault for buying the wrong thing.
UTM and SAN are famously sold this way.
