I would suggest improving the pricing, particularly the licensing model. Although it is currently quite reasonable, making it more accessible would be beneficial.
In contrast to hardware firewalls, if the hardware fails, we need to wait for a replacement, renew the support contract, or purchase an additional warranty. We don’t face these issues with the vSRX firewall. It should also support modern data technologies like zero-day protection and zero-trust network access. The firewall must filter traffic from SaaS applications like Microsoft 365 and other cloud services. It should also integrate easily with identity engines such as Okta and Microsoft Azure Active Directory, offering simpler integration than other brands.
The biggest downside of Juniper vSRX is its pricing, which may be too high for smaller organizations. While it's a decent solution, the cost may limit its accessibility to smaller customers.
Sub Divisional Engineer NOC Bangalore at a comms service provider with 10,001+ employees
Real User
Top 10
2024-03-19T15:27:33Z
Mar 19, 2024
They could provide support for cloud deployments. We are currently focused on on-premises deployments but see the potential for expanding into cloud environments. It would be beneficial to have a single dashboard or interface to differentiate between control and user plane functionalities, enhancing overall management and scalability. Additionally, we are interested in exploring options for scaling the Juniper vSRX firewall across different locations, including private cloud environments, and having the ability to centralize control and monitoring from a single point would be highly advantageous.
The solution can be improved by allowing automatic updates for the OS devices. For example, when we want to update our hardware device system, we have to download the OS package, attach the file with the hardware, and send a command to upgrade that package. However, with others, we can use the D-Link devices and click to check the online update and update it. In this case, we have to attach something from our local storage and then send a command to update Juniper.
ICT Administrator at a energy/utilities company with 51-200 employees
Real User
2022-06-03T07:10:37Z
Jun 3, 2022
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.
Senior Network Specialist at EDGE COMMUNICATIONS SOLUTIONS LLC
Reseller
Top 10
2022-05-27T16:47:57Z
May 27, 2022
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.
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.
Senior Network Planning Engineer at a comms service provider with 1,001-5,000 employees
Real User
2020-09-23T06:10:03Z
Sep 23, 2020
The solution works quite well. I can't think of any features that are lacking. I don't know where it could be improved. Some people complain that the solution tends to have a steep learning curve. It could be because most people have basic familiarity with Cisco or other similar products and maybe have never worked closely with Juniper products. I don't find that it's a problem, however, I have heard this mentioned as an issue for some people.
Network Operations Support at EOS IT Management Solutions Ltd
MSP
2020-08-05T06:59:28Z
Aug 5, 2020
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.
Network Security Engineer at a tech services company with 51-200 employees
Real User
2020-07-27T07:17:00Z
Jul 27, 2020
We worked with Cisco's support and Juniper's support and there are some differences, to be honest, Cisco is more available and is more competent at addressing our cases. So that is something negative about Juniper but otherwise, the architecture of Juniper's OS is flexible and scalable and technically Juniper is good. The GUI is really bad. Cisco's is more advanced with their ASDM platforms. Cisco has more advantages.
Network Security Engineer at a tech services company with 51-200 employees
Real User
2019-11-27T05:42:00Z
Nov 27, 2019
The support can be improved. The GUI needs to be improved, as Cisco is more advanced with their ASDM platform. In the next release, I would like to see improvements made to the GUI because it isn't very good. I would like them to discard some of the existing commands because we have to delete them. It should be more practical.
IT Manager at a comms service provider with 1,001-5,000 employees
Real User
2019-09-11T10:12:00Z
Sep 11, 2019
We have some weird errors and some weird behavior on the solution occasionally. The device gets buggy without anyone touching it. It would work and then suddenly stop. Sometimes you need to just move the cards out and restart it again, and it will work. The solution itself, the hardware and the software, there must be some bugs that need to be dealt with. We are using high-end devices. For the high-end devices, all the features are there; we don't need more features. What we need are for the features we have to work exactly as we want them to. Especially on the IT desk. There's something wrong between the hardware and the software. As I mentioned, some hardware is not working correctly in some integrations, and I'm not sure why.
Security Administrator at a comms service provider with 11-50 employees
Real User
2019-09-02T05:33:00Z
Sep 2, 2019
It seems that most of the problems were the device from management and not from support. We would spend a lot of time with support trying to solve the problems we had. We didn't resolve it because it was a problem from the device and management. The technical support did not seem to help. I've talked to people that say Juniper now, as a device, can be a solution for a data center, but in the past, I have not seen this as being possible.
Senior Information Security Engineer at SOCIALEYEZ
Real User
2019-07-14T10:21:00Z
Jul 14, 2019
The syndication or domain controllers, quick policies, and user rules - like being able to see the IP source and destination could be improved. This feature already exists in Palo Alto. They really need to improve the GUI.
Network Engineer at a tech services company with 11-50 employees
Real User
2019-07-07T06:35:00Z
Jul 7, 2019
The stability could be improved. For the moment I think it has all of the features I need. The only thing I'd like to see is the ability to create firewalls. That's the only feature I lack. Also, when you need to upgrade and when you need to reboot it, there's some downtime, and I'd like to be able to upgrade it without downtime.
Technical Product Manager at a financial services firm with 5,001-10,000 employees
Real User
2018-12-11T08:31:00Z
Dec 11, 2018
Right now, we are going through issues and problems where the product gets dropped with the connection or during the authentication initial phase. While it could be our problem, we would like to see more stability in this area.
Systems Analyst at a university with 10,001+ employees
Real User
2018-12-11T08:31:00Z
Dec 11, 2018
The user interface could always be better. They could make it simpler and more intuitive. While it is pretty good now, they could always make improvements.
Juniper vSRX is a virtualized security platform that provides advanced threat protection for virtualized and cloud environments. It offers a comprehensive set of security features, including firewall, VPN, intrusion prevention system (IPS), and unified threat management (UTM).
With its scalable architecture, the vSRX can be easily deployed and managed across multiple virtual machines, making it ideal for organizations with dynamic and distributed networks. It also supports...
I would suggest improving the pricing, particularly the licensing model. Although it is currently quite reasonable, making it more accessible would be beneficial.
In contrast to hardware firewalls, if the hardware fails, we need to wait for a replacement, renew the support contract, or purchase an additional warranty. We don’t face these issues with the vSRX firewall. It should also support modern data technologies like zero-day protection and zero-trust network access. The firewall must filter traffic from SaaS applications like Microsoft 365 and other cloud services. It should also integrate easily with identity engines such as Okta and Microsoft Azure Active Directory, offering simpler integration than other brands.
The GUI needs to be faster.
The biggest downside of Juniper vSRX is its pricing, which may be too high for smaller organizations. While it's a decent solution, the cost may limit its accessibility to smaller customers.
They could provide support for cloud deployments. We are currently focused on on-premises deployments but see the potential for expanding into cloud environments. It would be beneficial to have a single dashboard or interface to differentiate between control and user plane functionalities, enhancing overall management and scalability. Additionally, we are interested in exploring options for scaling the Juniper vSRX firewall across different locations, including private cloud environments, and having the ability to centralize control and monitoring from a single point would be highly advantageous.
The graphical unit is slow. Also, Juniper vendor shipping of UPM devices, support, Bandwidth shift, and other activities are very complex.
Juniper vSRX is expensive.
The solution's GUI needs improvement. Whenever we do some modifications, the systems get restarted. Thus, I have to use the command line interface.
The solution could improve its technical support. It could also improve its performance and ticket handling.
The solution should consider improving its licensing policies. It would be better if we could make a one-time payment for the hardware.
The solution can be improved by allowing automatic updates for the OS devices. For example, when we want to update our hardware device system, we have to download the OS package, attach the file with the hardware, and send a command to upgrade that package. However, with others, we can use the D-Link devices and click to check the online update and update it. In this case, we have to attach something from our local storage and then send a command to update Juniper.
It is pretty complex to manage and could be easier.
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.
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.
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.
The reporting can be improved.
I would like to see an activity sensor for malicious content or sensor for viruses and malware.
VPN access is an area that needs improvement.
The solution works quite well. I can't think of any features that are lacking. I don't know where it could be improved. Some people complain that the solution tends to have a steep learning curve. It could be because most people have basic familiarity with Cisco or other similar products and maybe have never worked closely with Juniper products. I don't find that it's a problem, however, I have heard this mentioned as an issue for some people.
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.
We worked with Cisco's support and Juniper's support and there are some differences, to be honest, Cisco is more available and is more competent at addressing our cases. So that is something negative about Juniper but otherwise, the architecture of Juniper's OS is flexible and scalable and technically Juniper is good. The GUI is really bad. Cisco's is more advanced with their ASDM platforms. Cisco has more advantages.
The support can be improved. The GUI needs to be improved, as Cisco is more advanced with their ASDM platform. In the next release, I would like to see improvements made to the GUI because it isn't very good. I would like them to discard some of the existing commands because we have to delete them. It should be more practical.
We have some weird errors and some weird behavior on the solution occasionally. The device gets buggy without anyone touching it. It would work and then suddenly stop. Sometimes you need to just move the cards out and restart it again, and it will work. The solution itself, the hardware and the software, there must be some bugs that need to be dealt with. We are using high-end devices. For the high-end devices, all the features are there; we don't need more features. What we need are for the features we have to work exactly as we want them to. Especially on the IT desk. There's something wrong between the hardware and the software. As I mentioned, some hardware is not working correctly in some integrations, and I'm not sure why.
It seems that most of the problems were the device from management and not from support. We would spend a lot of time with support trying to solve the problems we had. We didn't resolve it because it was a problem from the device and management. The technical support did not seem to help. I've talked to people that say Juniper now, as a device, can be a solution for a data center, but in the past, I have not seen this as being possible.
The syndication or domain controllers, quick policies, and user rules - like being able to see the IP source and destination could be improved. This feature already exists in Palo Alto. They really need to improve the GUI.
The stability could be improved. For the moment I think it has all of the features I need. The only thing I'd like to see is the ability to create firewalls. That's the only feature I lack. Also, when you need to upgrade and when you need to reboot it, there's some downtime, and I'd like to be able to upgrade it without downtime.
Up to the point we have used it now, there is no need for anything extra in the product.
Right now, we are going through issues and problems where the product gets dropped with the connection or during the authentication initial phase. While it could be our problem, we would like to see more stability in this area.
The user interface could always be better. They could make it simpler and more intuitive. While it is pretty good now, they could always make improvements.
The GUI interface needs improvement. It also needs improvement with the VPCs.