IT Central Station is now PeerSpot: Here's why
Buyer's Guide
June 2022
Get our free report covering Netgate, Cisco, Sophos, and other competitors of Fortinet FortiGate. Updated: June 2022.
607,127 professionals have used our research since 2012.

Read reviews of Fortinet FortiGate alternatives and competitors

Executive Cyber Security Consultant at a tech services company with 11-50 employees
Top 20
An excellent solution for the right situations and businesses
Pros and Cons
  • "The Palo Alto VM-Series is nice because I can move the firewalls easily."
  • "It has excellent scalability."
  • "The product needs improvement in their Secure Access Service Edge."
  • "They made only a halfhearted attempt to put in DLP (Data Loss Prevention)."
  • "Palo Alto is that it is really bad when it comes to technical support."

What is our primary use case?

Palo Alto VM-Series is something we recommend as a firewall solution in certain situations for clients with particular requirements who have the budget leeway.  

What is most valuable?

The Palo Alto VM-Series is nice because I can move the firewalls easily. For instance, we once went from one cloud provider to another. The nice thing about that situation was that I could just move the VMs almost with a click of a button. It was really convenient and easy and an option that every firewall will not give you.  

What needs improvement?

We would really like to see Palo Alto put an effort into making a real Secure Access Service Edge (SASE). Especially right now where we are seeing companies where everybody is working from home, that becomes an important feature. Before COVID, employees were all sitting in the office at the location and the requirements for firewalls were a different thing.  

$180 billion a year is made on defense contracts. Defense contracts did not stop because of COVID. They just kept going. It is a situation where it seems that no one cared that there was COVID they just had to fulfill the contracts. When people claimed they had to work from home because it was safer for them, they ended up having to prove that they could work from home safely. That became a very interesting situation. Especially when you lack a key element, like the Secure Access Services.  

Palo Alto implemented SASE with Prisma. In my opinion, they made a halfhearted attempt to put in DLP (Data Loss Prevention), those things need to be fixed.  

For how long have I used the solution?

I have been using Palo Alto VM-Series for probably around two to three years.  

What do I think about the stability of the solution?

I think the stability of Palo Alto is good — leaning towards very good.  

What do I think about the scalability of the solution?

Palo Alto does a good job on the scalability. In my opinion, it has excellent scalability.  

How are customer service and technical support?

My experience with Palo Alto is that it is really bad when it comes to technical support. When we have a situation where we have to call them, we should be able to call them up, say, "I have a problem," and they should ask a series of questions to determine the severity and the nature of the problem. If you start with the question "Is the network down?" you are at least approaching prioritizing the call. If it is not down, they should be asking questions to determine how important the issue is. They need to know if it is high, medium, or low priority. Then we can get a callback from the appropriate technician.  

Do you want to know who does the vetting of priority really, well? Cisco. Cisco wins hands down when it comes to support. I do not understand that, for whatever reason, Palo Alto feels that they do not have a need to answer questions, or they just do not want to.  

It is not only that the support does not seem dedicated to resolving issues efficiently. I am a consultant, so I have a lot of clients. When I call up and talk to Palo Alto and ask something  like, "What is the client's password?" That is a general question. Or it might be something even less sensitive like "Can you send me instructions on how to configure [XYZ — whatever that XYZ is]?"  Their response will be something like, "Well, we need your customer number." They could just look it up because they know who I am. Then if I do not know my client's number, I have got to go back to the client and ask them. It is just terribly inefficient. Then depending on the customer number, I might get redirected to talk to Danny over there because I can not talk to Lisa or Ed over here.  

The tedium in the steps to get a simple answer just make it too complicated. When the question is as easy as: "Is the sky sunny in San Diego today?" they should not be worried about your customer representative, your customer number, or a whole bunch of information that they really do not use anyway. They know me, who I am, and the companies I deal with. I have been representing them for seven or eight years. I have a firewall right here, a PA-500. I got it about 11 years ago. They could easily be a lot more efficient.  

Which solution did I use previously and why did I switch?

I have clients whose architecture is configured in a lot of different ways and combinations. I use a lot of different products and make recommendations based on specific situations. For example:  

  • I have one client that actually uses multiple VM-series and then at each one of their physical sites that have the K2-series — or the physical counterpart of the VM-series.  
  • I have other clients that use Fortinet AlarmNet. As a matter of fact, almost all my healthcare providers use Fortinet products.  
  • I have another customer that used to be on F5s and they had had some issues so switched to Fortinet.  
  • I have a couple of holdouts out there that are still using the old Cisco firewalls who refuse to change.  
  • I have a new client that is using a Nokia firewall which is a somewhat unique choice.  

I have a customer that used to be on F5s and they had had some issues. The result of the issue was that they came to me and we did an evaluation of what they really needed. They came in and they said, "We need you to do an evaluation and when you are done with the evaluation, you need to tell us that we need Palo Alto firewalls." I said that was great and I sat down and got to work building the side-by-side comparison of the four firewalls that they wanted to look at. When I was done, just like they wanted the Palo Alto firewall was right there as the first one on the list. They selected the Fortinet firewall instead.  

Nokia is specifically designed to address the LTE (Long Term Evolution, wireless data transmission) threats with faster networks and such. So it is probably not considered to be a mainstream firewall. The client who uses Nokia is a service provider using it on a cellular network. They are a utility and they are using Nokia on a cellular network to protect all their cellular systems and their automated cellular operations. The old Nokia firewalls — the one on frames — was called NetGuard. This client originally had the Palo Alto K-series and they switched over to the Nokia solution. That is my brand new Nokia account. They were not happy with the K-series and I am not sure why.  

The thing about Cisco is nobody is ever going to fire you for buying a Cisco product. It is like the old IBM adage. They just say that it is a Cisco product and that automatically makes it good. What they do not seem to acknowledge is that just because their solution is a Cisco product does not necessarily make it the right solution for them. It is really difficult to tell a customer that they are wrong. I do not want to say that it is difficult to tell them in a polite way — because I am always polite with my customers and I am always pretty straightforward with them. But I have to tell them in a way that is convincing. Sometimes it can be hard to change their mind or it might just be impossible.  

When I refer to Cisco, I mean real Cisco firewalls, not Meraki. Meraki is the biggest problem I think that I deal with. I do not have the network folks manage the Meraki firewalls differently than they manage their physical firewalls. I do not want there to be a difference, or there should be as little difference as possible in how the firewalls are handled. They do have some inherent differences. I try not to let them do stuff on the virtual firewalls that they can not do in the physical firewalls. The reason for that is because in defense-related installations it matters. Anytime you are dealing with defense, the closer I can get to maintaining one configuration, the better off I am. Unless something unique pops up in Panorama, I will not differentiate the setups.  

I say that there are differences because there is a little bit of configuration that inherently has to be different when you are talking about physical and virtual firewalls, but not much. I can sanitize the virtual machine and show the cloud provider that since I was going into a .gov environment or a .gov cloud, that it met all the requirements as stated in the Defense Federal Acquisition Regulation Supplement. That is huge for our situation. Of course with a cloud provider, you are not going to have a physical firewall. Had we had a physical firewall, that becomes a bit of a chore because you have got to download the configuration file, then you have got to sanitize the configuration. Things like that become a bit of a burden. Having a VM-Series for that purpose makes it much easier.  

I did not mention Sophos in the list. Sophos does a semi-decent job with that too, by the way. The only problem with Sophos is that they are not enterprise-ready, no matter what they say. I have deployed Sophos in enterprises before, and the old Sophos models did very well. The new ones do very poorly. The SG-Series — Sierra Golf — they are rock solid. As long as we keep going with them, our customers love it. It works. I have one client with 15,000 seats. They are running 11 or 12 of them and they have nothing but great things to say about the product. The second you go to the X-Series, they are not up to the task.  

How was the initial setup?

Setting up Palo Alto is relatively quick. But I also have an absolute rockstar on our team for when it comes to Palo Alto installations. When he is setting it up, he knows what he is doing. The only thing he had to really learn was the difference between the VM-Series and the PA-Series.  

I lay out the architecture and I tell people doing the installations exactly what has to be there. I sit down and create the rule sets. Early on, the person actually doing the fingers-on-the-keyboard complained a little saying that the setup was a little bit more complicated than it should have been. I agree, generally speaking. I generally feel that Palo Alto is more complicated than it needs to be and they could make an effort to make the installations easier.  

But, installing Palo Alto is not as bad as installing Cisco. Cisco is either a language that you speak or a language that you do not. I mean, I can sit down and plot the firewall and get the firewall together about 45 minutes with a good set of rules and everything. But that is me and it is because I have experience doing it. Somebody who is not very well-versed in Cisco will take two or three days to do the same thing. It is just absolutely horrid. It is like speaking English. It is a horrid language.  

What's my experience with pricing, setup cost, and licensing?

I do not have to do budgets and I am thankful for that. I am just the guy in the chain who tells you what license you are going to need if you choose to go with Palo Alto VM-Series. How they negotiate the license and such is not my department. That is because I do not resell.  

I know what the costs might be and I know it is expensive in comparison to other solutions. I get my licenses from Palo Alto for free because they like me. I have proven to be good to them and good for them. When they have customers that are going to kick them out, I can go in and save the account.  

I will tell you, they do practice something close to price gouging with their pricing model, just like Cisco does. When I can go out and I can get an F5 for less than half of what I pay for Palo Alto, that is a pretty big price jump. An F5 is really a well-regarded firewall. When I can get a firewall that does twice what a Palo Alto does for less than half, that tells me something.  

Sophos decided that they were going to play with the big boys. So what they did is they went in and jacked up all their prices and all their customers are going to start running away now. The model is such that it is actually cheaper to buy a new firewall with a three-year license than it is to renew the Sophos license of the same size firewall for an older product. It sorta does not make sense.  

Which other solutions did I evaluate?

I make recommendations for clients so I have to be familiar with the firewalls that I work with. In essence, I evaluate them all the time.  

I work from home and I have two Cisco firewalls. I have a Fortinet. I have the Palo Alto 500 and I have a Palo Alto 5201. I have a Sophos. My F5 is out on loan. I usually have about eight or nine firewalls on hand. I never go to a client without firing up a firewall that I am going to recommend, testing it, and getting my fingers dirty again to make sure I have it fresh in my mind. I know my firewalls.  

The VM-Series are nice because you can push them into the cloud. The other nice thing is whether you are running a VM-Series or the PA-Series, we can manage it with one console. Not without hiccups, but it works really well. Not only that, we can push other systems out there. For instance, for VMware, we are pushing Prisma out to them. VMware and the Palo Alto VM-Series do really well with Prisma. The issue I have with it is — and this is where Palo Alto and I are going to disagree — they are not as good at SASE (Secure Access Service Edge). I do not care what Palo Alto says. They do a poor job of it and other products do it better.  

Palo Alto claims it is SASE capable, but even Gartner says that it is not. Gartner usually has the opinion that favors those who pay the most, and Palo Alto pays them well. So when Gartner even questions their Secure Access Service Edge, it is an issue. That is one of those places where you want the leader in the field.  

From my hands-on experience, Fortinet's secure access service edge just takes SASE hands down.  

What other advice do I have?

My first lesson when it comes to advice is a rule that I follow. When a new version comes out, we wait a month. If in that month we are not seeing any major complaints or issues with the Palo Alto firewall customer base, then we consider it safe. The client base is usually a pretty good barometer for announcing to the world that Palo Alto upgrades are not ready. When that happens, making the upgrade goes off our list until we hear better news. If we do not see any of those bad experiences, then we do the upgrade. That is the way we treat major revisions. It usually takes about a month, or a month-and-a-half before we commit. Minor revisions, we apply within two weeks.  

I am of the opinion right now that there are some features missing on Palo Alto that may or may not be important to particular organizations. What they have is what you have to look at. Sit down and be sure it is the right solution for what you need to do. I mean, if the organization is a PCI (Payment Card Industry) type service — in other words, they need to follow PCI regulations — Palo Alto works great. It is solid, and you do not have remote users. If you are a Department of Defense type organization, then there are some really strong arguments to look elsewhere. That is one of the few times where Cisco is kind of strong choice and I could make an argument for using them as a solution. That is really bad for me to say because I do not like Cisco firewalls.  

On a scale from one to ten (where one is the worst and ten is the best), I would rate the Palo Alto Networks VM-series as an eight-out-of-ten.  

Disclosure: I am a real user, and this review is based on my own experience and opinions.
Project Engineer at Telindus B.V.
Real User
Talos continuously enriches intelligence so that you get information about upcoming threats on time
Pros and Cons
  • "The most important feature is the intensive way you can troubleshoot Cisco Firepower Firewalls. You can go to the bit level to see why traffic is not handled in the correct way, and the majority of the time it's a networking issue and not a firewall issue. You can solve any problem without Cisco TAC help, because you can go very deeply under the hood to find out how traffic is flowing and whether it is not flowing as expected. That is something I have never seen with other brands."
  • "The Firepower FTD code is missing some old ASA firewalls codes. It's a small thing. But Firepower software isn't missing things that are essential, anymore."

What is our primary use case?

Telindus, our company, is an integrator. We sell Firepower and we do use it ourselves. I use all the different versions of the product. 

We either replace our customers' other brands of firewalls with Firepower, or we upgrade their old Cisco ASA Firewalls to the new Firepower firewalls. The type of device we advise them to install depends on the customer's requirements and the throughputs needed.

Our primary use case for Firepower is for big networks.

What is most valuable?

The most important feature is the intensive way you can troubleshoot Cisco Firepower Firewalls. You can go to the bit level to see why traffic is not handled in the correct way, and the majority of the time it's a networking issue and not a firewall issue. You can solve any problem without Cisco TAC help, because you can go very deeply under the hood to find out how traffic is flowing and whether it is not flowing as expected. That is something I have never seen with other brands. That is why, when people move from another brand to Cisco, they never leave Cisco. They see that advantage.

Something I like about Firepower, in general, is that it still relies on the old ASA code. That's something customers really like because when they go into the CLI, they remember, "Oh, that's the ASA, that I am familiar with," but it's enriched with all the next-gen features of Snort. When a customer has knowledge of the ASA codes, they can do intensive troubleshooting because they know the device.

Customers also like Talos, which is the intelligence behind all of Cisco's security products, including Firepower. Talos is very good and is actually the most important part of a security product. It's important that you have something in the background that is continuously enriching intelligence so that you get information about upcoming threats on time. That keeps you protected as soon as possible when a Zero-day happens. Something that customers like about Cisco Firepower, in combination with Talos intelligence, is that full-time people are working in the background to provide information to Cisco security products.

Customers really want visibility into their networks. For example, they want identity management and that is something you can use Firepower for. With it, in addition to an IP address going somewhere, you can also see the username. That's a big advantage of Firepower, and can be set up quite easily.

Also, in very large networks, our customers use Cisco DNA Center. They have automation orchestration for their access network and that works seamlessly with Cisco Firepower firewalls. Security Group Tags can be used from DNA to an edge Firepower firewall. That way, they have microsegmentation within their access network for DNA. And they can extend that to their firewall rules for Firepower. 

Our customers also use Cisco ISE to get user information. ISE is connected to DNA Center. That is something that Firepower works seamlessly with, and we do sell it a lot. We sell a lot of Cisco's other security equipment, and they all send their information to SecureX. Having more Cisco security products means your security information is becoming enriched within the SecureX platform. The integration among these Cisco products is more than easy. Cisco documents everything, in detail, when it comes to how to integrate the different parts. I've never had an issue with integrating Cisco security products with each other.

And for smaller networks, like those our government customers have, what they like about Cisco Firepower, and why they purchase it nine out of 10 times, is its ease of use and the reporting in Firepower Management Center. That is something they really like. They can look up things themselves and they like the SecureX integration.

What needs improvement?

The Firepower FTD code is missing some old ASA firewalls codes. It's a small thing. But Firepower software isn't missing things that are essential, anymore.

For how long have I used the solution?

I've been using Cisco Firepower NGFW Firewall since it came out; from the time Cisco started to use the name Firepower and they bought Snort. That's when they put in the next-generation features. 

What do I think about the stability of the solution?

Firepower is rock-stable. So far, I have not seen any failed firewall. The only thing that was not quite stable in the past was Firepower Management Center, but since version 6.6 that has also been rock-stable. I haven't had any failed components in the last couple of years. I did have them two years ago and further in the past, where firewalls were not functioning and needed a reboot, but since 6.6, the stability is very good. We don't have priority-one tickets anymore.

What do I think about the scalability of the solution?

In the Netherlands, where I work, we don't have very big customers requiring very high throughput. So I cannot say anything about clustering where you can pile different ASAs or Firepower devices together to increase performance when you require it. 

But scalability, in general, is pretty hard. Competition-wise, sometimes it's hard to sell Cisco security products because, in my opinion, Cisco is quite honest about the real throughput they are able to provide. Other vendors may be giving figures that are a little bit "too perfect." Sometimes it's hard for us to sell Cisco firewalls because a customer says, "Well, when I go to other brands they say they have double the throughput for half the price." Well, that's great on paper, but... 

In general, after we have installed Cisco firewalls, our customers are very pleased by the performance. They also like that they can tweak settings to get more performance out of the firewall by enabling specific policies for specific traffic, and by disabling inspection for very internal data center traffic. That provides a big boost to the overall firewall performance. When a customer complains that we didn't scale it correctly, and they say it's not performing as well as they expected, I'm always able to tweak things so that it performs the way the customer requires.

How are customer service and technical support?

I have interacted with Cisco's technical support many times. Nowadays, it sometimes takes a while to get to the person with the correct knowledge, but that is happening in the world in general. First-line people are common around the world and they are trying to figure out if an issue is actually a second-or third-line issue. But when you do reach the correct department, and they know that you are knowledgeable and that you are really facing a high-priority issue or a strange behavior, Cisco's support does everything it can to help you fix things, including involving the development department. I'm very happy with their tech support.

Which solution did I use previously and why did I switch?

Most of the time we replace Sophos, Check Point, SonicWall, and Fortinet firewalls with Cisco firewalls. Customers really like the overall integration with SecureX. They see the advantage of having more security products from Cisco to get more visibility into their security. We also replace old, non-next-generation firewalls from Cisco; old ASAs.

How was the initial setup?

The initial deployment of Firepower is a straightforward process. For me, it's pretty easy. If you have never worked with it, I can imagine it might be complex. 

Cisco makes it easier all the time. You can now deploy a remote branch by managing the device on an external interface. In the beginning, with previous software versions, that was hard. You needed to configure the file as a remote branch, but for that you needed the central Firepower Management Center to configure it and you didn't have a connection yet. It was a big issue to set up an initial firewall remotely when there was no connection to the Management Center. But that's been fixed.

In general, you just put down some management IP addresses and configure things so that the devices see each other and it starts to work. It's far from complex.

Generally, the initial setup takes four hours. The implementation strategy depends on the customer. I always have a conversation with the customer upfront. I explain how the connectivity works for Cisco Firepower, and then I say that I want to be in a specific subnet field. Then I start configuring the basics, and that is the part that takes about four hours, for Firepower Management Center and two firewalls in HA. Then, I start to configure the firewalls themselves, the policies, et cetera.

Which other solutions did I evaluate?

I have experience with SonicWall, Fortinet, Juniper, and Sophos firewalls, among others. We work with Fortinet and Palo Alto. It's not that we only do Cisco. But I can say from my experience that I am really more convinced about Cisco products.

What customers really like about Cisco, the number-one thing that they are really happy about within Firepower—and it was also in the old ASA code, but it's even more a feature in Firepower—is that the configuration is in modules. It's modular. You have different policies for the different functions within your firewall, so that your access control policy is only for your access lists and that's it. You have a different network address translation policy. It's all separated into different policies, so a customer knows exactly where to look to configure something, to change something, or to look at something which is not working properly.

Also, with Cisco, when a customer is not totally certain about a change he's going to make, he can make a copy of the specific access control policy or the NAT policy. If something doesn't go right, he can assign the copied policy back to the device and everything is back to the way it was. 

These are the biggest advantages our customers see. When a customer doesn't have any knowledge about firewalls, I can explain the basics in a couple of hours and they have enough familiarity to start working with it. They see the different modules and they know how to make a backup of a specific module so that they can go back to the previous state if something goes wrong.

What other advice do I have?

My advice is "buy it." A lot of people prefer a specific brand and it's fairly hard to convince them that something else, like Cisco, is not bad, as well. They are so convinced about their existing firewall that they want to keep that brand because they are familiar with it and they won't need to learn a new firewall. It's hard for a customer to learn how a firewall works in the first place.

But my advice is that people should read about how Cisco security, in general, is set up and how it is trying to protect them with Talos. They need to understand that Cisco security is very good at what it does. They shouldn't blindly believe in what they have at the moment. I always hear, "My firewalls are good enough. I don't need Cisco. I will just buy the same ones, but new." Cisco Firepower is superior to other firewalls and people should not be afraid to dive in. By educating themselves about the firewall, they will be fine in managing it.

Practically speaking, Cisco firewalls are easier to manage than the firewalls they have at the moment, but they need to make the leap and try something else. That is the hardest part. When I do show them what they are capable of, and how you can configure all kinds of different things, they start to understand.

We don't have many customers that use other vendors' security products together with Firepower. We convince nine out of 10 customers to go over to Cisco fully. We do have customers who don't do that, and then we try to find a way to get the solutions to work together. For example, we try to integrate other brands' switches or firewalls with Cisco security products, but most of the time that is pretty hard. It's not the fault of Cisco. It requires that the other brands speak a protocol language that will support integration, but in the end, it's not perfect and the integration does not work very well. The majority of the time, we are not able to integrate into other security products. Cisco is using standard protocols, but the other vendor is abusing some sort of protocol and then it doesn't work well.

I don't prefer using applications in firewall rules, but our customers do use the application visibility and control, and it works perfectly. Firepower is very good at recognizing the application and is very good at showing you the kind of application that has been recognized. Customers use that in their access control policy rules, and I have never heard bad things about it. Cisco Firepower works very well in recognizing applications.

I get questions from customers because they do not understand threat messages generated by Firepower. Sometimes, it's hard to read what exactly the message is saying. In my opinion, that is not something that is specific to Cisco security or Firepower, rather it is an issue with security in general. Most networking people get these fancy firewalls and they get fancy security events. It's hard for some of them to understand what is meant, and what the severity level is of the message. It's more that a networking guy is trying to read security events. Firepower is doing a good job, but customers sometimes have problems understanding it and then they stop looking at it because they don't understand it. They assume that Firepower is taking the correct actions for them.

Firepower is not a fire-and-forget box. It is something you actually do have to take a look at. What I tell customers is, "Please enable Impact-One and Impact-Two messages in your mailbox, and if it's really something that you cannot understand, just forward it to me and I will take a look for you. Most of the time they are not very high-impact messages. There are only one or two high-impact messages per month.

There are customers who say, "We want you to review the messages in Firepower once a week." I have a look at them when I have time. We try to help the customer check security events once a week or so. That's not great, but it's always a question of finding a good balance between the money a customer can spend and the security aspects. When we do monitor all the events, 24/7, for a customer, you can imagine that it is quite expensive.

I configure every customer's automatic tweaking of IPS policies so that the IPS policy is enabled for the devices seen by Firepower, for recognition of what kinds of clients and hosts are in the network. Other than that, we do not do a lot of automation within Firepower.

Since 7.0, I don't have a lot of things to complain about. If I do have suggestions for improvements, I will give them during the beta programs. The speed of the FMC is very good. The deployment time is much better. They added the policy deployment rollback. That was something I really missed, because if I destroyed something I was able to undo that. Now, for me, it's actually almost perfect.

Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor. The reviewer's company has a business relationship with this vendor other than being a customer: Reseller
Shashidhara B N - PeerSpot reviewer
Director - Technology Solutions & Services at Connectivity IT Services Private Limited
Real User
Top 10
This best in class Next-Gen firewall is elegant in its ease-of-use and architecture
Pros and Cons
  • "Juniper is one of the most powerful network security solutions while remaining simple to use, set up, and scale."
  • "It could have features that other products support like blade options and stand-alone endpoint security."

What is our primary use case?

For different customers, we use the product in different ways. In some cases, it is going to be an on-premises solution. In some cases, it is going to be a cloud-integrated solution. That is one of the best things about Juniper. We can use a single box and have the same unified policy structure if it is off the cloud or it is on-premises.  

Our primary use case is basically to use it like you would any other firewall. I do not call this a firewall anymore because it has functionality beyond what we traditionally think of as a firewall. Those days are gone where a firewall does just one thing. Today most of the firewall products are station firewalls. You have various options in each firewall station. In terms of comparison, you can compare Juniper with Cisco, with Fortinet, with Palo Alto and other leading products. It depends on what exactly you are planning to have it do.  

What is most valuable?

The most valuable feature for me over-all is that Juniper is simplified and can still do everything that is necessary to be effective. 

On the SRX box, it has what I call a one model concept for security. I work especially with hybrid environments. With an SRX we have a single management dashboard. We can manage the internal framework easily with the centralized management component. You can work with the threat prevention, you can work with the integration, you can work with traffic management. Another good part about SRX is that you have opportunities for automation. Another thing that is very good is that all the operating systems for all Juniper boxes are the same. You do not work on different operating systems using different boxes. 

It does user validation automatically and has automated threat detection and defense. It does threat analytics, which is integrated. So as a single box, it does not just address security, it does not just handle switching, it does not just work as a firewall. It addresses everything.  

What needs improvement?

I have not given a lot of thought as to what needs to be improved because so much of technology and capabilities are expanding.  

Probably Juniper could come up with their own dedicated endpoint security. Today they have an integration with Sophos. If you really look at what SRX has as far as antivirus capability, it is really only the integration with Sophos. Sophos is good, I am not saying Sophos is a bad solution. But Juniper having their own antivirus solution may be a batter idea to make it a stand-alone product.  

If you look at Check Point. They have a lot of experience in the area of security which is integrated with their product. In comparison, Juniper could start developing its own strong capabilities with antivirus and have its own security which may even surpass relying on Sophos. Sophos could improve more but it is definitely a wonderful architecture.  

For how long have I used the solution?

I have around 22 years of experience with various similar products. My experience for the last 10 years has been on Juniper. I have worked on Cisco, on Foundry, and on Xstream. And you can make comparisons with products like Fortinet and Palo Alto next-generation firewalls.  

What do I think about the stability of the solution?

I would rate stability on a scale of one to ten. If ten is best, I would rate a nine-point-five. I would not rate anything a ten in this industry in any case because nothing is perfect and there is always room for improvement. It is very robust. Because the product is robust and very agile that carries over well into the potential for reliability.  

What do I think about the scalability of the solution?

When it comes to scalability, basically Juniper is modular. The SRX architecture is very important. Say I am a small-time customer with 50 people in my company and I deploy on the SRX 300 Series. If my business grows exponentially and I now have 500 people in the company. My traffic has boosted significantly — say about ten times what it was. I do not have to really worry. Within one hour, I can just switch and get a new SRX box in place. Let's say I go with the 500 Series or the 4000 Series. This is my new capacity.

The change over is so simple, because the architecture is common. Whether you talk about SRX 300 or you talk about the service provider architecture, it is the same thing except for the capability to expand and handle the volume. That is very important from a technical perspective, which normally you only need one tech person to deploy.  

For mid-sized companies or even large-sized companies, you have a lot of clients from SRX 300 to SRX 5000 Series and the product line covers all the options. This is from a very basic server-level SRX box to the Next-Generation Firewall and advanced threat mitigation.  

But one thing that scalability should really take into account is that Juniper is an enterprise product. If you are really only talking about using the Sophos UTM or only want to use the product like a firewall, then you should consider a UTM box. If you then want to add an SD-WAN as an additional part of the architecture, the UTM is not the right choice. You just take an SRX box and you have SD-WAN on that. You can have a firewall on that. You can have a UTM on that. You can integrate with the cloud. You can integrate with Linux infrastructure. You can have network security.  

Today when we talk about Check Point, we talk about Next-Generation Firewalls. That includes the Palo Alto Next-Generation Firewall and Cisco Next-Generation. But no one talks about what the definition of Next-Gen is. The only difference about Next-Generation is that it has a staple firewall, by definition.  

If you are a small company and you only have five in your office, obviously you want a secure network. To do this you will buy a simple firewall. When you think of the most simple firewall, people buy a router. Then people buy a switch. Then people buy a firewall. Three devices. I would say, do not buy anything. Just buy one SRX box, which does all the three.  

Now I can also expand the same SRX 300 with a branch location. Let's say, I'm a bank customer. I have branches. Simple, I can now have the simplest of SRX 300 at all my branches or SRX 500. I just connect to my main SRX, let's say a 1500 Series with an SD-WAN topology. The project is done. Simple. I secure my network. I handle my routing. I handle my security. And I have an option for just enabling the license to get the latest threat mitigation.  

For comparison, let's take a very big enterprise network. Maybe I was the head of Informatica at APAC. I am in a situation where I have 6000 R&D developers in the organization. We monitor our total performance. Latency on the firewall should be as low as possible. This is especially critical with the current environment where people work from home. Everyone who is working from home now because of COVID has all their data still in the office and people come onto the network to get connected from home to the office.  

Imagine the load on my firewall in that situation. All the people from inside my organization are sitting outside of the office now accessing the data in the internal network through the firewall. Imagine all the data tracking is coming from all over like an external traffic base. You need to have the proper solution to handle the change in traffic and scalability is the most important factor in this case for successfully running a demanding environment.  

How are customer service and technical support?

Juniper support is very good. But more than the technical support, their documentation is awesome. You can just Google a solution right now by stating your problem. You get into the and there is wonderful documentation. As a technical person, I have never seen any technical documentation that is as good. I would say it is awesome. Any person who has an interest to learn, who has the interest to scale his capability with the product, just has to go to the Juniper site and they will get all the information on every one of their products. I think that it is written well enough for a non-technical person to become technical.  

They have different levels of training available. They make it very easy and available for anybody to explore the solution. There are knowledgeable people available in the technical community. It is a very good solution overall.  

How was the initial setup?

I consider the setup for the product to be very easy. A basic technical person can do it. But, a person would need to know the capability of a robust box like SRX to make full use of the capabilities and the right choice of the product.  

You install the box, configure the hostname, a password, and set your IP address. By default, Juniper handles the basic configurations automatically. The control frame architecture is very nice. The whole platform architecture is very good. When you work with that box, you just divide the box into two layers: the top layer and the bottom layer. The top layer is exclusively made for the SRX box. The bottom layer is nothing but throughput where the packets get in and get out. We call it a packet forwarding engine, PFE.  

Initiating the routing packets actually go in the mapping connection between the top and the bottom, which is managed as with Oracle in an internal zone. The box is already secured when an attack happens. Nothing is 100% in the world. So, there is the possibility of an attack but at least the control center protects your network.  

The entire installation is just a couple of hours. It depends on the Oracle sizing. Let's say that you want to work on the agility of SRX, something you really need to understand is where you are deploying this product. It is different if you are comparing an SRX box or the cloud. When you are using an SRX box will it be deployed for a small enterprise, a mid-size enterprise, and a data center. You can have SRX boxes for a large data center. That is a difference in the agility of Juniper SRX compared to Cisco. For example, when I work with the cloud, I have an SRX virtual firewall, which is a high-performance network security in the virtual cloud. It is especially good for rapid deployments. It hardly takes hours to deploy on the cloud.  

When you have a container with a firewall, it is known as cSRX. Which is again, a highly available container firewall. These are used especially for microservices. When you start with a small enterprise you start with either the SRX 300 series or a 500 series, which is a next-generation firewall. It is comparable to the Cisco ASA. Probably the next good product to compare is Check Point. But the SRX product is easier to manage and deploy when compared to Check Point or Cisco.  

For the mid-size enterprise organization, we have the SRX 1400 Series or you can consider the 4000 Series. It is just an appliance. You just plug it in, switch it on, configure the network IP address, and then start configuring the protocols. You enable the licenses there, malware prevention, and all the other features you want by just adding on to the licenses.  

So it is just a matter of choosing the right appliance and from there it is practically plug-and-play. The challenge is not the initial setup and deployment, it is what you make use of.  

Which other solutions did I evaluate?

The main competitors for Juniper are Palo Alto, Check Point, and Cisco. Juniper has a lot of features that are good for engineering. Things like Fortinet and Cyberoam can not really compete with these others when it comes to these important features. Specifically, when you talk about Juniper SRX you talk about cloud deployment. You talk about malware remediation. You talk about reporting analytics. You talk about quarantining or threat intelligence (Unified Threat Management or UTM). You talk about data throttle, control prevention, email, web analysis, and integrated management. It can even just work as a router or assisting layer. It works best especially in large networks — like when you talk about service providers — where you have huge traffic flow. It is built to have flexibility and ease-of-use.  

What other advice do I have?

My advice to anyone considering Juniper as a solution would be to first understand that the product needs to be chosen to fit the environment. You want to get the one right box that has the capacity you need. You have everything you need in the model by just updating your license. You do not have to look for a new box when your traffic remains under the upper limits of the capacity. If you are under the limitations of the capacity, the traffic goes straight out, unimpeded.  

On a scale from one to ten where one is the worst and ten is the best, I would rate Juniper SRX as a nine or even a nine-point-five overall. Additional features that could be added to make this solution a ten that other competitors have would technically make it the best product. For example, Check Point offers Blade Architecture. You just keep adding more and more blades. Because of this, Check Point — especially in the area of their security database — they are quite superior to Juniper. o there is room for improvement.  

When you really study on an enterprise level where Check Point stands out or where Juniper stands out, you have got to look into the way each product fits your needs. I mean Check Point is currently easy-to-use, and very good, global product. It also has quite a good rating from the industry over the past few years. Certainly, someone considering a purchase needs to consider options and trends.  

Which deployment model are you using for this solution?

Hybrid Cloud
Disclosure: My company has a business relationship with this vendor other than being a customer: Partner
Ifeanyi Onyiaodike - PeerSpot reviewer
Network security engineer at Fidelity Bank
Real User
Top 5
Enabled us to virtualize multiple firewalls on one machine
Pros and Cons
  • "The most valuable feature for us is the VSX, the virtualization."
  • "The VPN part was actually one of the most complex parts for us. It was not easy for us to switch from Cisco, because of one particular part of the integration: connecting the Check Point device to an Entrust server. Entrust is a solution that provides two-factor authentication. We got around it by using another server, a solution called RADIUS."

What is our primary use case?

We use it for VSX virtualization and we use it for normal firewall functions as well as NAT. And we use it for VPN. We don't use a mobile client, we just use the VPN for mobile users.

How has it helped my organization?

We are able to virtualize about four firewalls on one machine. Before, we needed to have four firewall hardware devices, physical devices, from Cisco. We had four appliances, but now, with Check Point, we just have one. We can manage them, we can integrate them, and we can increase connections using one and the other. It has broken down connection complexities into just a GUI.

Also, previously we had downtime due to memory saturation with our old firewalls. We were using Cisco ASA before. During peak periods, CPU utilization was high. Immediately, when we switched to Check Point, that was the first thing we started monitoring. What is the CPU utilization on the device? We observed that CPU utilization stayed around 30 percent, as compared to 70 percent with the Cisco we had before, although it was an old-generation Cisco. Now, at worst, CPU utilization goes to 35 percent. That gives us confidence in the device. 

In addition, the way Check Point built their solution, there is a Management Server that you do your administration on. You have the main security gateway, so it's like they broke them down into two devices. Previously, on the Cisco, everything was in one box: both the management and the gateway were in one box. With Check Point breaking it into two boxes, if there's a failure point, you know it's either in the management or the security gateway. The management is segmented from the main security gateway. If the security gateway is not functioning properly, we know that we have to isolate the security gateway and find out what the problem is. Or if the management is not coming up or is not sending the rules to the security gateway, we know there's something wrong with it so we isolate it and treat it differently. Just that ability to break them down into different parts, isolating them and isolating problems, is a really nice concept.

And with the security gateway there are two devices, so there's also a failover.

What is most valuable?

  • The most valuable feature for us is the VSX, the virtualization.
  • The GUI is also better than what we had previously.
  • The third feature is basic IP rules, which are more straightforward.
  • And let's not forget the VPN.

The way we use the VPN is usually for partners to connect with. We want a secure connection between our bank and other enterprises so we use the VPN for them. Also, when we want to secure a connection to our staff workstations, when employees want to work from home, we use a VPN. That has been a very crucial feature because of COVID-19. A lot of our people needed to work remotely.

What needs improvement?

The VPN part was actually one of the most complex parts for us. It was not easy for us to switch from Cisco, because of one particular part of the integration: connecting the Check Point device to an Entrust server. Entrust is a solution that provides two-factor authentication. We got around it by using another server, a solution called RADIUS.

It was very difficult to integrate the VPN. Until now, we still don't know why it didn't work. With our previous environment, Cisco, it worked seamlessly. We could connect an Active Directory server to a two-factor authentication server, and that to the firewall. But when we came onboard with Check Point, the point-of-sale said it's possible for you to use what you have on your old infrastructure. We tried with the same configurations, and we even invited the vendor that provided the stuff for us, but we were not able to go about it. At the end of day they had to use a different two-FA solution. I don't if Check Point has a limitation in connecting with other two-FAs. Maybe it only connects with Microsoft two-FA or Google two-FA or some proprietary two-FA. They could work on this issue to make it easier.

Apart from that, we are coming from something that was not so good to something that is much better.

For how long have I used the solution?

I have been using the Check Point Next Generation Firewall for 10 months.

What do I think about the stability of the solution?

The stability of Check Point's firewall, for what we use it for now, is pretty good. Especially, with the licensing of blades and the way they script it down into different managers. You have a part that manages blades, you have the part that manages NAT, and you have the part that manages identity. The VSX is another one on its own. So it is very stable for us.

When we add more load to it, when we go full-blown with what we want to use the device for, that will be a really good test of strength for the device. But for now the stability is top-notch.

What do I think about the scalability of the solution?

They scale well.

All information passes through the firewall. We have about 8,000-plus users, including communicating with third-party or the networks of other enterprises that we do business with.

How are customer service and technical support?

We've not used technical support. We asked our questions of the vendor that deployed and he was quite free and open in providing solutions. Anytime we call him we can ask. He was like our own local support.

There is also a Check Point community, although we've not really been active there, but you can go and ask questions there too, apart from support.

How was the initial setup?

The initial setup was pretty straightforward.

It took a while about a month, but it was not because of the complexity. It was because we gave them what we already have on the ground. We were on Cisco before and they had to come up with a replica of the configurations for Check Point. When they got back to us we had to make some corrections, and there was some back-and-forth before everything finally stabilized.

Four our day-to-day administrative work, we have about four people involved.

What about the implementation team?

We used a Check Point partner for the installation. I was involved in the deployment, meaning that while they were deploying I was there. They even took us through some training.

What was our ROI?

We have surely seen ROI compared to the other vendors I mentioned, in terms of costs. And we tested all the firewall features to see if it is doing what it says can do. And so far so good, it's excellent. It's a good return.

What's my experience with pricing, setup cost, and licensing?

Check Point offers good solutions, but it won't kill your budget.

Going into Next-Generation firewalls, you should know what the different blades are for, and when you want to buy a solution, know what you want to use that solution for. If it's for your normal IP rule set, for identity awareness, content awareness, for VPN, or for NAT, know the blades you want. Every solution or every feature of the firewall has license blades. If you want to activate a feature to see how that feature handles the kind of work you give, and it handles it pretty well, you can then move to other features.

Which other solutions did I evaluate?

We evaluated Palo Alto, Fortinet FortiGate, and Cisco FirePOWER.

Check Point was new to the market so we had to ask questions among other users. "How is this solution? Is it fine?" We got some top users, some top enterprises, that said, "Yes, we've been using it for a while and it's not bad. It's actually great." So we said, "Okay, let's go ahead."

What other advice do I have?

I would recommend going into Check Point solutions. Although Check Point has the option of implementing your firewall on a server, I would advise implementing it on a perimeter device because servers have latency. So deploy it on a dedicated device. Carry out a survey to find out if the device can handle the kind of workload you need to put through it.

Also, make it a redundant solution, apart from the Management Server, which can be just one device. Although I should note that up until now, we have not had anything like that.

Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
Executive Vice President Operations and IT at Sterling National Bank
Real User
Top 20
A solution for integrating services to enhance up-time, performance and lower costs
Pros and Cons
  • "Using SD-WAN to combine services can result in better up time, higher speeds, and much lower costs."
  • "There have been no issues with stability."
  • "Huge companies use SD-WAN. It is largely scalable."
  • "Any technical support we needed was great."
  • "Cisco could do more to offer bundling of the SD-WAN and other solutions."

What is our primary use case?

With my first client on Viptela were getting MPLS (MultiProtocol Label Service). That is a type of communications network that most of the major providers like Verizon offer. They were paying roughly $3,000 a month for each one of their 30 branches. That was giving them 10 megabits per second. We replaced that with the likes of Verizon Fios and Comcast. Each one of those business internet services cost about $200 apiece per month. The cost of the SD-WAN was maybe another $200. So for $600 a month, we replaced something that was costing them $3000 a month, and they were getting a minimum of about 50 megabits-per-second upload and download.  

What is most valuable?

Because our client uses two different ISPs at each location, the service is always up. The chances of Comcast going down at the same time that Verizon Files goes down is very, very small. The result is that the client's services are always up with much higher speeds and much lower costs. I think that those benefits are the ones that people are primarily interested in and that is what SD-WAN allowed us to achieve.  

What needs improvement?

I think that the SD-WAN had everything that my client was interested in in our first experience with it. I think that some of the solutions now are being integrated with other services. As an example, Fortinet has a product called FortiGuard. Included in the FortiGuard product is an SD-WAN. So some of these products are expanding capabilities so that they have more to offer in a single product.  

That would be a nice thing for Cisco. They could provide you your firewall and your SD-WAN solution together. Some people like that approach of nesting products or bundling because they have fewer vendors to deal with and immediate integration.  

I am sure as time goes on that the threat landscape will continue to change all the time. What was good encryption five years ago may not be such great encryption today. Because of that, I am sure that you have to constantly be looking at the threat landscape to see if you need to change anything. I do not know if I am close enough to that cutting edge of the problem to answer the question as to what Cisco's solution really needs. All I know is that my client is very happy with what they have got in the way of savings and functionality. That does not mean that there are not some other things that they would like to see. I just do not know what they are.  

There are a number of large companies that have bought out various SD-WAN vendors. If you looked at VMware, you will find that they also have an SD-WAN that they bought. There are several other companies that have bought SD-WAN services because the technology is so good and the cost benefit is so great that it is worthwhile for almost any company to implement it. They get the advantage of performance and the benefit that these systems never go down.  

As an example, one time locally there was an incident where two providers, CenturyLink and Level 3, went down at the same time. If you had CenturyLink and Level 3, your connection to the internet would have gone down for six or seven hours or whatever the overlap of those outages was. That would be an extreme case. There is another local ISP service called Cox, if you had CenturyLink and Cox, Cox did not go down. In that case, you would continue using your internet or your connections to your branches without ever experiencing an outage and it would just go through Cox. The reason is that Cox's infrastructure, their central office, their wiring, their co-ax cables, or fiber are completely separate from what CenturyLink uses. CenturyLink has got a completely separate central office and completely separate wire. So the chances of those two entities going down exactly at the same time is something that just never happens.  

For how long have I used the solution?

I helped a client implement a solution called Viptela a while back. Cisco purchased Viptela in August of 2017 and that is what Cisco uses as thier main SD-WAN solution. That first encounter was probably about four years ago.  

What do I think about the stability of the solution?

The system worked extremely well from the beginning and there have been no issues with stability. In fact, stability is the reason why the solution was put in place.  

What do I think about the scalability of the solution?

SD-WAN is certainly scalable. Huge companies use SD-WAN. Ever heard of Jiffy Lube? Ever heard of PNC Bank? Ever heard of Gap? (I do not know whether Gap surviving because of COVID) Those are just a couple of companies off the top of my head who are using SD-WAN solutions. It is largely scalable. I think that PNC Bank had something like 4,000 locations. It is very scalable.  

In the SD-WAN world, they have something called an orchestrator. On the orchestrator, you can see everything that is happening on your SD-WAN. So you can see if a particular carrier is going down, or if you are experiencing errors or whatever. You can see a complete picture of your entire wide area network in one pane of glass. In the old days before SD-WAN, if you had six carriers, you would have to go and look on six different carrier systems to find out what was going on. Even then, you were not necessarily getting all the information that you needed. SD-WAN is the greatest thing since sliced bread when it comes to having an overview of services.  

It is very widely adopted because it is better and cheaper and easier. You are seeing more companies looking for those solutions. Some of the telecom companies are offering SD-WAN. Some of the UCaaS (Unified Communications as a Service) companies are also promoting SD-WAN. One of the reasons that they are is to assure their clients that their telephone service will always be up.  

How are customer service and technical support?

Any technical support we needed was great. Everything worked from day one so there was not a lot of need for those services.  

Which solution did I use previously and why did I switch?

Our client was using a single service and they wanted a more reliable service, higher speed, and much lower price. We found that solution for them by integrating services. Instead of paying $3000 a month for each of 30 locations, they got it down to about $600 a month for each location. They switched because they got what they wanted.  

How was the initial setup?

The initial setup and installation was pretty straight forward.  

What about the implementation team?

The people from Viptela, at the time, assisted in the implementation. They were helpful in pushing along the implementation and it went smoothly.  

What's my experience with pricing, setup cost, and licensing?

Depending upon the speed and depending upon the vendor, if you are getting SD-WAN as a service, it is probably something in the neighborhood of $100 to $200 a month per location. That is the cost of the SD-WAN. Then, of course, you need your business broadband connections. Business broadband with like 50 megs symmetrical or 100 megs symmetrical and may cost something like $100 a month or so. But at any rate, the services are not very expensive and they are widely available.  

What other advice do I have?

The advice that I would give someone in the market for an SD-WAN is to look at Gartner and see what Gartner has to say. My information is recent in that the bank that I implemented it in does other business with me and they tell me that everything is working great. They have never had a problem. It is now four years later and it is probably worthwhile taking a look at what the competition is doing — including Cisco Meraki, which is another SD-WAN offering from Cisco. A lot of companies have implemented Cisco Meraki, and Cisco Meraki is a good solution. But there is also Versa which is a good SD-WAN solution. There are at least seven or eight very well-known companies that provide SD-WAN solutions.  

On a scale of one to ten (where one is the worst and ten is the best), I would rate Cisco SD-WAN as a ten-out-of-ten. For my client, it was certainly a ten between the cost savings of 80% and a performance boost of 400% or so. It worked right from the beginning and saved them a ton of money.  

Disclosure: My company has a business relationship with this vendor other than being a customer: Consultant
Buyer's Guide
June 2022
Get our free report covering Netgate, Cisco, Sophos, and other competitors of Fortinet FortiGate. Updated: June 2022.
607,127 professionals have used our research since 2012.