Juniper vSRX Reviews

The product’s quality and performance are better than other vendors.

The solution could improve its technical support. It could also improve its performance and ticket handling.

I am working on the solution currently for three of my clients.

Most of the clients might choose Cisco, Palo Alto, and Fortinet over Juniper because of the difference in pricing, quality, performance, ticket handling, and technical support.

The product has a good market in our country. Juniper’s MX1000 and other series have firewall and routing features. However, in other products, the firewall and routing feature is separated. Most Juniper devices combine routing switches and firewalls on a single platform.

Overall, I rate the solution a six or seven out of ten.

The software is good. It's similar to when we used LAN and Cisco routers and firewalls in the past. We were able to scale. Juniper is better than Cisco for management.

It is pretty complex to manage and could be easier.

We have been using this solution for about nine years, and it is deployed on-premises. We are using version SRX 500.

The hardware is stable and more stable than Sophos.

It is a scalable solution. We have about 500 users using this solution in our company.

It is easy to install.

I rate this solution a seven out of ten, and I would recommend it to other people.

This solution works well. Their switches and firewall are good.

Fortinet is more user friendly than Juniper. In terms of remote access, I actually prefer using Fortinet. It is much easier to configure. When someone uses Juniper for the first time, it can be very intimidating. At one time, Juniper had what was known as a MAG, which was meant for remote access for users on the SRX.

They sold MAG and now remote access on Juniper leaves a lot to be desired because they don't have their own client. You have to use Pulse Secure or another solution. When there's a bug, Juniper relies on Pulse Secure and in our experience, this took six months to fix.

I have been using this solution for ten years. 

This is a scalable solution. 

For those who can afford it afford it, I would recommend Palo Alto over Juniper.

I would rate this solution an eight out of ten.  

It's where we face some of our IPsec tunnels.

It's basic functionality is probably the most valuable feature.

Juniper has some really good ideas, but I think they have missed the boat with regard to execution.

The GUI really needs a lot of work, and it has got worse with successive version updates. There are some things that are just easier to look at in the GUI, and they've removed some features that were very helpful.

Even though the features are still available in the CLI, sometimes it's just easier to look at the rules in a hierarchical fashion in the GUI.

The hardware needs some serious work as well. In the four years we've had Juniper vSRX, we've had four RMAs. Each of the three physical devices that we have has been replaced at least once.

A better methodology of looking at how a proposed rule would act on the network would be good to have. For example, Cisco ASA had a tool where you could write a rule or a policy, and it would tell you whether it stopped specific traffic.

I've used it for the last four years.

My impressions of this solution's stability is not very favorable. We haven't had any problems with actual stability in the last couple of years, but it has lost its mind a couple of times and required rebooting.

The technical support for this solution is fair. I've had a lot worse, and I've had better, so it's run of the mill.

We were using Cisco ASA before Juniper vSRX.

The reason that we didn't go with Cisco is that their products were behind the times. Other products had more up-to-date technology.

We're a small organization, and the initial setup was pretty straightforward. I do the maintenance of the solution.

We hired an outside vendor to help with initial deployment.

On a qualitative level, Juniper vSRX is taking care of what we need it to. So far, we haven't had an attack, but we did have a breach.

The ongoing licensing cost seems to be pretty standard. There are no additional costs.

I recommend looking elsewhere. I'm not particularly enamored with Juniper vSRX. I've had a lot of problems with it. We're looking to replace Juniper with either Aruba or FortiGate based on usability and affordability.

Overall, I would rate this solution at four on a scale from one to ten.

I primarily use the solution for experimentation. I just wanted to create a site to site VPN. I was hoping that you can make the SRX like a hub, so if I had a site here and then I had a new site, I could just create another VPN from that new site to the virtual X in the cloud. I don't know if it works like that. I'm skeptical if it can. Maybe there is a roundabout with the actual Azure AWS, however, I'm not so sure about that part. That's why I'm learning about Azure, and how that works in connecting to the cloud.

I'm told the solution is the fastest, and, so far, I do find that to be the case. 

I'm familiar with the solution, so I'm pretty comfortable with the processes. There's pretty good usability.

Largely the solution seems fine to me.

It could use more tutorials.

I think there's a step missing or the use cases are missing information. I'm not sure why you have to connect from the descendant to another SRX. The why part, why would I do that and what's practical, is not really answered in any documentation I have access to. At my last job, we used to hook up a VPN to the data center, and then at each site we would have a device connecting to that data center. Now that project is not 100% right now, I'm still wondering if I were to go and do that project, how would I do it? Should I make it cloud-based?

If I want to use it virtually in the cloud as a hub, I want to see if that's possible, and, if it's possible, they should have documentation on that.

I looked at the config. I played around with the config and then I say, "Okay, I see what they're doing, with the actual Azure part, and yet, on AWS, I'm having the same problem." It's something to do with the public IP. It's only functioning on the management side, on the virtual firewall. I can't get the other side, the other network interface to connect out. I don't have a connection out technically. I could ping, but through management and that's not how it's supposed to work. It's just through the management. I'm not seeing the departments.

I haven't been using the solution for that long. Basically it's just this year. I've been tinkering with it since March.

The solution is stable. It seemed very good. I'm just trying to learn everything right now, however, from what I've experienced, I'd say it's reliable.

Scalability is very good. I'm not an expert yet, however, I would recommend it to anybody who needs to expand.

There's hundreds, if not thousands, or users on the solution currently.

I believe there is something on Amazon and you can ask questions about the solution. I was trying to go through something like that, and maybe they can help. I didn't really follow through, due to the fact that I didn't get an email, so I don't know who could contact me. With Azure, I didn't really go that far in depth.

Mostly I just do my own research and try to troubleshoot issues on my own. I'm figuring out everything from scratch.

I'm kind of familiar with ASA firewalls from Cisco. I've worked with SonicWall a lot and Pablo Alto a little bit, however, I'm not 100% familiar with it. I've worked on it, but not every day. For Palo Alto, I just worked on it once. I know the interface. I know some other firewalls as well, however, I don't think they need to be mentioned, as they're not that popular. ASA firewall, I would say, is the most popular one.

At first the implementation was straightforward. I got around quickly. I was able to, after a week, feel like I had the hang of everything. I can move around in Azure and AWS. That said, it's just the part with the elastic IP. I don't know if it's a Juniper issue or it's on there and there's another connection, and that's the part I'm not getting.

I was able to deploy the solution in days. It's just getting it to work properly, however. In that sense, it took weeks, or, at least a week and a half. I had to say "Okay, let me give up this for now" before I really got anywhere.

There isn't really maintenance per se. It's just running. There's 24/7 support. When it goes down, I guess, we're there.

I did the implementation myself, however, I have a lot of tutorials and documentation on hand. I use YouTube as well. I even got Pluralsight the other day. I have IME. I have CBT Nuggets. Anything I can use to find out more about the product I will look at. What has really helped me was I got a lot of PDF files from Juniper and it had some stuff about AWS.

I would say this solution was the default selection, however, I know that ASA is up there too. That said, the virtual SRX is what's most popular now.

Our organization is partners with Juniper. We have a business relationship with them.

At work I see it a lot, however, a lot of tasks are automated at work. It's not like you have hands-on from scratch experience. In my position, I'm doing more support or some automation to build the VRX or the virtuals needed for lab equipment. At home and in the labs I am able to learn from scratch, and I'm trying to connect VPNs, etc. I am hoping to get into the cloud in the future.

The version of the solution we use should be the latest. I downloaded it a couple of months ago. It should be the latest, due to the fact that I have a virtual that's a trial. I get it through the partnership through my job. The virtual that I've got is on AWS. Azure is the recommended platform.

I'd recommend the solution. I'd rate it ten out of ten.

The tool's most valuable features are routing features and service quality. 

The tool's basic license does not cover everything. It needs to improve visibility and availability. 

I have been working with the product for two to three years. 

The tool is very stable. 

Juniper vSRX's scalability is good. 

We chose Juniper vSRX for its price. 

I rate the tool's deployment a four out of ten. You need one month to complete the deployment for 50 sites. 

Juniper vSRX is worth its money. 

I rate the tool's pricing a five out of ten. 

We evaluated Cisco before choosing Juniper vSRX. 

I rate the product a seven out of ten. 

Mine control is not an easy area to control in Juniper. There are also too many steps for configuration, like the IP address policy. There are too many types of licenses, which can be confusing. Simple licenses should be built in.

Processing is too slow between Juniper and Cisco. Palo Alto is faster. The database is not as complete as Cisco or Palo Alto.

I've been using this solution for around 11 years.

I also use Cisco and Palo Alto.

I would rate this solution 6 out of 10.

We are a solution provider and the vSRX is something that we have included in one of the solutions that we sell to our customers for cyber security protection. Our initial deployment was on-premises at one of our customer's sites.

We were so happy with vSRX that we expanded its usage. We design and prepare solutions for ships, and we have included the vSRX as part of our cyber security solution for them. It is still an on-premises deployment, although the premises is a vessel.

This product is primarily used for its UTM functionality. We collect all of the logs that the UTM produces onboard each ship and bring them onshore. At that point, we reevaluate them. We give full accessibility to the customers, allowing them to see what the UTM is doing on their ships.

This product has improved the way our organization functions because prior to implementing it, vessels did not have this technology. There was nothing equal to it.

The most valuable features are application filtering, content filtering, the intrusion prevention system (IPS), and definitely the application firewall.

We use the SSL inspection capability, which we really like a lot.

The reporting can be improved.

I have been working with Juniper vSRX for three years.

Stability-wise, it is very good. This product is very stable and it's proven to be a very good tool for us. It is used extensively because it is part of the ship's main operations. All of the data that goes in or out of the vessel is inspected by it.

This is quite a scalable product. It is easier to scale than the SRX because it's virtual. It's easier to assign more resources than it is to add more hardware.

We have installed this solution on approximately 450 ships with about 20 people in each of them. Many more of our customers have ships and we expect to surpass 1,000 installations within the next two or three years.

The technical support is very good.

We did not use another solution prior to this one. A product did not exist for our customers' ships, so we introduced it using the vSRX.

We have also implemented the Juniper SRX and the vSRX takes a little bit longer because the design is more complex. From the design phase to implementation and deployment, it takes between two and three days to complete.

We had a partner do the implementation for us. The maintenance is also done by a partner. We have a lot of vSRX devices out there, and we are not actively maintaining them ourselves, so we have our partner to take care of it.

We did not evaluate other options before implementing this solution. We are Juniper SRX users and we were so happy with that product that we decided the only solution had to be the vSRX.

My advice for anybody who is implementing this product is that the whole thing is about the design. If you design it well, consider how you should introduce it into your organization, and have a good implementor to ensure that it integrates well into the platforms you already have in place, then you won't have any problems with the implementation phase. Having a good integrator is very important.

Feature-wise, this product isn't missing anything. There is nothing that we have asked for that isn't there. Our only complaint is about the reporting.

I would rate this solution a ten out of ten.