If Palo Alto could open the platform to manage other SD-WANs, it would be beneficial. Currently, it only manages Palo Alto. Also, if there were an option to extend management to other firewalls, users could perform staggered migrations.
The pricing for Prisma SD-WAN needs improvement. It's a perfect solution, but its price is above the market average. An additional feature that can be introduced is the inclusion of a remote browser solution with the same license as Prisma SD-WAN. This could complement and improve the overall solution.
Senior Solutions Specialist at a comms service provider with 201-500 employees
Real User
Top 5
2023-11-13T10:41:02Z
Nov 13, 2023
There are some small issues in Prisma SD-WAN's area related to bypass pair or couple ports related to redundancy. Sometimes, during the product's initial setup phase, bypass pair or couple ports don't come up normally, and it requires an hour and a half to troubleshoot to reset the box from Prisma SD-WAN to factory default. Prisma SD-WAN has some minor issues in its physical port, especially in bypass pair or couple ports. Bypass pair or couple ports are not abnormal ports. It is just that the aforementioned ports behave differently. If Prisma SD-WAN can fix bypass pair or couple ports and make them robust enough to work after the initial setup in the first attempt, then it can save a lot of time. The physical device's bypass pair or couple ports generally have issues.
Prisma SD-WAN's technical support should be improved. When we have some issues, the technical support should be available on time, and the engineer should join to help us. It can increase the bandwidth capacity for some of the small branches. A warning message comes to us to notify us that something is going wrong, but we cannot understand that information. Prisma SD-WAN can be automated so that our network will be faster and our work will be reduced.
Event correlation and analysis capabilities do not help minimize the number of alarms from a single event. That is the problem. We are getting a lot of incidents, and there is some issue with the correlation. That is still a drawback. Sometimes we get many alerts when a device is going down, and when it goes up again the alerts are not automatically cleared. Some type of modification is required. Another drawback I have observed is that Prisma SD-WAN has a tunnel to the Zscaler endpoint. It forms the tunnel through an API call and that is not sufficient from the client side. Improvement is needed to the parameters they're using for the Zscaler endpoint. There are new features, new protocols, that need to be applied so that it can be checked and work properly. Improvement is needed from Prisma to the Zscaler endpoint because when the tunnel goes down, there are no intelligent parameters, like an alert timer.
Pcs at a computer software company with 1,001-5,000 employees
Real User
Top 20
2022-12-25T16:37:00Z
Dec 25, 2022
There are two parallel things that we want Palo Alto to work on. First, customers want a unified appliance that does the work of all firewalls in addition to SD-WAN. Second, the cloud presence should be completely automated. If I purchase the SASE architecture, I shouldn't worry about deployments in Prisma Access or on Prisma SD-WAN. It should be deployed in one go.
In some areas, compared to other SD-WANs, Prisma SD-WAN has fewer features. First of all, sometimes, if one device is down, the other device will not come up. When there are two devices and we have created HA, that means one device gets a priority of 100 and the other is given 90. The 100 priority is active and the 90 is the backup. In some cases, the primary device is down, but the secondary device is not becoming active. In that case, we have to reboot the devices, causing an outage. I would also like to see improvement in the product training for customers. Palo Alto has not initiated very much training but they have to do so because this is a new product. If you have experience in a legacy environment, and you are moving to Prisma SD-WAN, you don't have a training framework. That is one of the disadvantages. Although they have a training portal, it is a read-only platform. They need training for engineers so that engineers can work very quickly and properly. And with software upgrades, sometimes the device does not come up and we have to do a manual restart. It doesn't happen every time, maybe one or two times out of 100. It's minimal but it does happen.
IT Communications engineer at a construction company with 10,001+ employees
Real User
2022-09-20T16:46:00Z
Sep 20, 2022
The dashboard is okay. The dashboard gives us enough flexibility to get the information needed so that we can act upon any issues or data that is represented. It serves our purpose for our use case. Like with any other product, it takes time to get acquainted with it. The only con is the pricing because it's more premium.
I'm happy with it as it is. Maybe they could introduce some new features that make things easier. That said, for me, I didn't find it lacking in any major way. It gives me all that I really need. I'd like to see them move more towards CASB. The solution does do a lot of frequent updating.
Technical Lead at a tech services company with 10,001+ employees
Real User
2021-12-27T20:54:00Z
Dec 27, 2021
Previously, they were sending traffic from their data center primarily over VPN lines. This was the default routing behavior for them. We had routing policies in our branch offices, which basically did the routing on outgoing traffic regardless of where the traffic was received. If we had a policy that stated, "Do not send it back over the VPN. Send it over any other link." The data center understood that, because it has persistent routing enabled. It would send it over that link, then start sending it back over the link with the routing policy in effect. Recently, regardless of our routing policy, the data center devices keep sending traffic on the VM and our return traffic is sent according to our policy. This can now have some effect on stateful devices, which are in between, because they see traffic going in from another link and coming out from another link. They sometimes change their routing design and manipulations with their firmware, which shouldn't be happening. We are incorporating their zone-based firewalls. Prisma SD-WAN has limited documentation on how it manipulates traffic, e.g., how it is interacting with TCP and UDP. We recently had some traffic that was black holing. We literally had to do packet captures to see that the new zone-based firewall, which runs on top of Prisma SD-WAN, was causing issues. It is growing in its routing policy. Its transitioning is pretty smooth, but its maintenance is what takes time and understanding. From the maintenance aspect, if there are any issues caused by Prisma SD-WAN, you really need to dig down and troubleshoot. Many times, it is not evident from its traffic logs whether you can assert that Prisma SD-WAN is doing something wrong. You need to understand the interactions between Prisma SD-WAN and other networking gears. When you need to troubleshoot something, then you really need to dig down. Two or three people have needed to do packet captures so many times on different devices. So, if you are on a shift and four people are working, and there is a major routing issue, then you need at least two people to work on the routing issue and the other two people to cover the day-to-day normal operations. We don't want our MPLS link to get saturated if the Internet goes down. This minimizes other application bandwidth utilization. So, it analyzes Layer 7 applications as well, e.g., we saw that with Zoom. We can also limit some web-based public IPs based on regions. We can apply a policy that states, "If it understands that this application is Zoom and the outgoing traffic is going towards these public IPs, put a strict affinity on them and just pin them on an Internet link. If the Internet goes down, then just drop those packets." We are deploying the new zone-based firewall of Prisma SD-WAN into our network. The original CGX appliance and the new firewall do not always go hand to hand, because the former one is a stateless device and their new firewall is stateful. If an event occurred and Prisma SD-WAN finds that event, it defines that in its dashboard. However, there is a gripe that it is not very good at defining traps and sending alerts over to third-party monitoring software. For example, if you have SolarWinds or LM in your environment, and you have people who are watching over those monitoring appliances' GUIs. Sometimes those alerts are missed because they are present over in the Prisma SD-WAN dashboard, but Prisma SD-WAN does not have that flexible communication with monitoring appliances. Therefore, we have experienced stuff where some traffic was pinned over MPLS and there were no secondary paths defined for them. The MPLS went down and failed over everything to the Internet. Since we had it set for certain kinds of traffic to be pinned over on MPLS only, or the dedicated circuit, it didn't actually put out an alert. If you check its traffic logs, it states there that the L3 path reachability for this traffic has been lost and is being dropped. The policy control is a bit lacking with the event correlation because we do not get active alerts on our monitoring applications. We need to go into Prisma SD-WAN traffic flow logs to see if certain flows have been dropped.
Simplify management, enable app-defined SD-WAN policies and deliver a secure, cloud-delivered branch today with the Industry’s first next-generation SD-WAN.
If Palo Alto could open the platform to manage other SD-WANs, it would be beneficial. Currently, it only manages Palo Alto. Also, if there were an option to extend management to other firewalls, users could perform staggered migrations.
The pricing model could be improved to make it more affordable for smaller companies.
The solution should include custom ports and group voice connections.
The pricing for Prisma SD-WAN needs improvement. It's a perfect solution, but its price is above the market average. An additional feature that can be introduced is the inclusion of a remote browser solution with the same license as Prisma SD-WAN. This could complement and improve the overall solution.
Prisma SD-WAN should provide more flexibility and scalability on the hardware. The solution's conversions and failover need to be improved.
There are some small issues in Prisma SD-WAN's area related to bypass pair or couple ports related to redundancy. Sometimes, during the product's initial setup phase, bypass pair or couple ports don't come up normally, and it requires an hour and a half to troubleshoot to reset the box from Prisma SD-WAN to factory default. Prisma SD-WAN has some minor issues in its physical port, especially in bypass pair or couple ports. Bypass pair or couple ports are not abnormal ports. It is just that the aforementioned ports behave differently. If Prisma SD-WAN can fix bypass pair or couple ports and make them robust enough to work after the initial setup in the first attempt, then it can save a lot of time. The physical device's bypass pair or couple ports generally have issues.
The tool needs to work on price and complexity.
Prisma could be a little cheaper.
Prisma SD-WAN's technical support should be improved. When we have some issues, the technical support should be available on time, and the engineer should join to help us. It can increase the bandwidth capacity for some of the small branches. A warning message comes to us to notify us that something is going wrong, but we cannot understand that information. Prisma SD-WAN can be automated so that our network will be faster and our work will be reduced.
Event correlation and analysis capabilities do not help minimize the number of alarms from a single event. That is the problem. We are getting a lot of incidents, and there is some issue with the correlation. That is still a drawback. Sometimes we get many alerts when a device is going down, and when it goes up again the alerts are not automatically cleared. Some type of modification is required. Another drawback I have observed is that Prisma SD-WAN has a tunnel to the Zscaler endpoint. It forms the tunnel through an API call and that is not sufficient from the client side. Improvement is needed to the parameters they're using for the Zscaler endpoint. There are new features, new protocols, that need to be applied so that it can be checked and work properly. Improvement is needed from Prisma to the Zscaler endpoint because when the tunnel goes down, there are no intelligent parameters, like an alert timer.
There are two parallel things that we want Palo Alto to work on. First, customers want a unified appliance that does the work of all firewalls in addition to SD-WAN. Second, the cloud presence should be completely automated. If I purchase the SASE architecture, I shouldn't worry about deployments in Prisma Access or on Prisma SD-WAN. It should be deployed in one go.
In some areas, compared to other SD-WANs, Prisma SD-WAN has fewer features. First of all, sometimes, if one device is down, the other device will not come up. When there are two devices and we have created HA, that means one device gets a priority of 100 and the other is given 90. The 100 priority is active and the 90 is the backup. In some cases, the primary device is down, but the secondary device is not becoming active. In that case, we have to reboot the devices, causing an outage. I would also like to see improvement in the product training for customers. Palo Alto has not initiated very much training but they have to do so because this is a new product. If you have experience in a legacy environment, and you are moving to Prisma SD-WAN, you don't have a training framework. That is one of the disadvantages. Although they have a training portal, it is a read-only platform. They need training for engineers so that engineers can work very quickly and properly. And with software upgrades, sometimes the device does not come up and we have to do a manual restart. It doesn't happen every time, maybe one or two times out of 100. It's minimal but it does happen.
The dashboard is okay. The dashboard gives us enough flexibility to get the information needed so that we can act upon any issues or data that is represented. It serves our purpose for our use case. Like with any other product, it takes time to get acquainted with it. The only con is the pricing because it's more premium.
I'm happy with it as it is. Maybe they could introduce some new features that make things easier. That said, for me, I didn't find it lacking in any major way. It gives me all that I really need. I'd like to see them move more towards CASB. The solution does do a lot of frequent updating.
Previously, they were sending traffic from their data center primarily over VPN lines. This was the default routing behavior for them. We had routing policies in our branch offices, which basically did the routing on outgoing traffic regardless of where the traffic was received. If we had a policy that stated, "Do not send it back over the VPN. Send it over any other link." The data center understood that, because it has persistent routing enabled. It would send it over that link, then start sending it back over the link with the routing policy in effect. Recently, regardless of our routing policy, the data center devices keep sending traffic on the VM and our return traffic is sent according to our policy. This can now have some effect on stateful devices, which are in between, because they see traffic going in from another link and coming out from another link. They sometimes change their routing design and manipulations with their firmware, which shouldn't be happening. We are incorporating their zone-based firewalls. Prisma SD-WAN has limited documentation on how it manipulates traffic, e.g., how it is interacting with TCP and UDP. We recently had some traffic that was black holing. We literally had to do packet captures to see that the new zone-based firewall, which runs on top of Prisma SD-WAN, was causing issues. It is growing in its routing policy. Its transitioning is pretty smooth, but its maintenance is what takes time and understanding. From the maintenance aspect, if there are any issues caused by Prisma SD-WAN, you really need to dig down and troubleshoot. Many times, it is not evident from its traffic logs whether you can assert that Prisma SD-WAN is doing something wrong. You need to understand the interactions between Prisma SD-WAN and other networking gears. When you need to troubleshoot something, then you really need to dig down. Two or three people have needed to do packet captures so many times on different devices. So, if you are on a shift and four people are working, and there is a major routing issue, then you need at least two people to work on the routing issue and the other two people to cover the day-to-day normal operations. We don't want our MPLS link to get saturated if the Internet goes down. This minimizes other application bandwidth utilization. So, it analyzes Layer 7 applications as well, e.g., we saw that with Zoom. We can also limit some web-based public IPs based on regions. We can apply a policy that states, "If it understands that this application is Zoom and the outgoing traffic is going towards these public IPs, put a strict affinity on them and just pin them on an Internet link. If the Internet goes down, then just drop those packets." We are deploying the new zone-based firewall of Prisma SD-WAN into our network. The original CGX appliance and the new firewall do not always go hand to hand, because the former one is a stateless device and their new firewall is stateful. If an event occurred and Prisma SD-WAN finds that event, it defines that in its dashboard. However, there is a gripe that it is not very good at defining traps and sending alerts over to third-party monitoring software. For example, if you have SolarWinds or LM in your environment, and you have people who are watching over those monitoring appliances' GUIs. Sometimes those alerts are missed because they are present over in the Prisma SD-WAN dashboard, but Prisma SD-WAN does not have that flexible communication with monitoring appliances. Therefore, we have experienced stuff where some traffic was pinned over MPLS and there were no secondary paths defined for them. The MPLS went down and failed over everything to the Internet. Since we had it set for certain kinds of traffic to be pinned over on MPLS only, or the dedicated circuit, it didn't actually put out an alert. If you check its traffic logs, it states there that the L3 path reachability for this traffic has been lost and is being dropped. The policy control is a bit lacking with the event correlation because we do not get active alerts on our monitoring applications. We need to go into Prisma SD-WAN traffic flow logs to see if certain flows have been dropped.