Barracuda vs Meraki - firewalls
-
it manages the entire stack.
-
The Ubiquiti is not an UTM in any way. In that space, the leader is Fortinet. No one can beat their price/performance for what they do. I use Ubiquiti in many places, but when a real UTM is needed I choose Fortinet.
-
@francesco-provino said in Barracuda vs Meraki - firewalls:
The Ubiquiti is not an UTM in any way. In that space, the leader is Fortinet. No one can beat their price/performance for what they do. I use Ubiquiti in many places, but when a real UTM is needed I choose Fortinet.
Key word in that is need. When do you ever need all of your network security provided by a single appliance? If they did a better job, or didn't have much lower priced competition, then they'd make a lot more sense.
-
@francesco-provino said in Barracuda vs Meraki - firewalls:
The Ubiquiti is not an UTM in any way.
No, but it's more of a security device than the Barracuda is, which is the point. An insecure UTM has no purpose.
-
@storageninja said in Barracuda vs Meraki - firewalls:
That can't manage switches or AP's though right? One of the selling points on Meraki is it can do the entire "stack" in a single UI/management tool.
Switches, yes. APs, no, you use Unifi for that. Very similar.
-
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.
