Prisma SD-WAN Reviews

Prisma SD-WAN is intuitive. We have a better idea of the different tools we can use and jump between the menus quickly. 

The tool needs to work on price and complexity. 

I have been working with the product for about two weeks. 

I rate the product a seven out of ten. 

Initially, we deployed it in a hybrid fashion and were utilizing the Internet, but we had MPLS being defined on our WAN routers as well. While the MPLS link wasn't terminated on Prisma SD-WAN, it was helping us route traffic through it. This made the WAN routers kind of redundant since the solution creates its VPN tunnels from Internet links and we have data center devices where it establishes its tunnels. Therefore, if any MPLS goes down in any of our branch offices, it helps us route the traffic through them. 

We have a site where we deployed its VPN tunnels through MPLS, not just the Internet. However, we still have some BFD issues there. Right now, we are transitioning our sites to all Internet circuit sites. We are deploying our Prisma SD-WANs there. So, it is just doing VPN tunnels through the Internet with no MPLS on all new upcoming sites.

We are transitioning into AWS.

When we deployed CloudGenix, we had Internet and MPLS links. We had to manually transition our VPN tunnels and shift the routing from MPLS towards the Internet in case our MPLS went down. During that transition, there were human errors. Sometimes, there was downtime, where the MPLS went down, and people were on a short coffee break when services went down. Then, people had to scramble, come in, and put in commands, typing in everything to just fail over the traffic from MPLS to the VPN tunnels. However, Prisma SD-WAN has taken that out of our minds, because it does that itself. It is pretty smooth. As soon as it analyzes that the MPLS has gone down, it starts to advertise branch routes to others through Internet VPN links. So, it has saved us a lot of time, effort, and cost from this aspect.

We haven't experienced anything ever go down. It sends traffic out, regardless of the fact that we aren't maintaining any SLAs on the Prisma SD-WAN front, because it is doing routing only. There is a traffic flow log where we can clearly see if it wasn't able to reach an AWS-deployed application over the Internet, then it sends the traffic over to MPLS. That transition is very smooth. It's not like we need to go into the aspect of saying that Prisma SD-WAN took time to fail over the traffic because it couldn't understand the cloud-based services. Therefore, we never had a need to define any SLA for its transitioning and work.

It decreases alarms in terms of network link failure. Many times earlier, we could miss some traffic that was being sent over MPLS. For example, if we had 15 applications routed over MPLS and that MPLS failed, we had to manually route all those back towards the Internet. Many times, we missed some applications and that resulted in new tickets trickling in. We then had to identify if the traffic was taking a default routing earlier. In that case, it was working over MPLS, but since MPLS is down, we have to now put in another route and advertise it over BGP so it is reachable over VPN. With Prisma SD-WAN in play, we don't need that because it analyzes applications, like Layer 7 applications, and transitions them based on our policies. We do not need to worry that we may have forgotten something or that Prisma SD-WAN may forget to fail over some stuff if MPLS goes down.

Its valuable features are its use of VPN tunnels. You don't really have to tinker with anything.

If the MPLS goes down, there is a really smooth transition for a branch site to take traffic over the Internet. It will advertise the routes of that site in a jiffy. 

Its VPN tunnel creation is smooth. I have never faced any issues where it wasn't able to establish its VPN tunnels or had trouble doing negotiations. That is pretty awesome. 

Prisma SD-WAN provides deep application visibility, along with Layer 7 intelligence. We can manipulate traffic on Layer 7. It understands the algorithm, packets, and which application it is, according to the traffic going through it. For example, we usually have traffic going out for Zoom. We wanted to understand whether Zoom had some new public IPs every now and then. In its early years, Prisma SD-WAN didn't have the correct signatures to understand that it was a Zoom application, but they have continued to improve it. They published that Prisma SD-WAN can now understand Zoom, as per its Layer 7 signatures. Now, we can pin its traffic over the Internet only. It analyzes the deep packets going out on an application basis. We can manipulate it as well on the affinity. So, we can state, "I do not want the video traffic to be going over MPLS if my Internet goes down. Just shut it off."

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.

We have been using this solution for the past four years. 

It is far more stable now than it was in its initial years. We used to face TCP proxies getting hung and their internal processes getting stuck. Our routes were not advertised in the first year of our Prisma SD-WAN being deployed. Those issues have been smoothed out and we no longer face them. Each passing year, we see less issues with Prisma SD-WAN. As of now, we seldom have any Prisma SD-WAN issues. So, its stability is growing. However, when you throw into the picture the new Prisma SD-WAN appliance, which is a zone-based firewall, then we have some complications like we had when we first deployed Prisma SD-WAN.

The downtime has been zero, if we have MPLS and Internet at our site. It has transitioned everything smoothly over the Internet. If something previously took an hour, then the solution reduced that amount of time to just 10 minutes because it fails over everything to the Internet.

We might start upgrading all our Prisma SD-WAN devices in the next two or three months.

Prisma SD-WAN is good when it comes to supporting large, complex network architectures. We have global offices and data centers, where it has been working awesomely at catering the traffic. We receive the support from Prisma SD-WAN on time as well. So, the solution can be utilized in any type of scenario: big firms, data centers, small firms, etc.

It is pretty scalable. The device spans across four data centers. It is now deployed in our AWS data center as well in a virtual image. It is deployed at 27 different locations in a HA manner.

When they were just CloudGenix, we had awesome support. The people were candid in answering questions. Many times, we had the co-founders of CGX joining us on our call to understand what the issue was and helping us out. When it moved over to Palo Alto, the usual tech scenario came into the picture: 80% of the time, you get a person who is pretty knowledgeable about the stuff, but 20% of the time you may get a person who does not know that CGX has been adding to the tech. So, the tech is knowledgeable 80% of the time, but 20% of the time, we find ourselves giving directions to the tech rather than getting directions from them.

Under Palo Alto, I would rate their technical support as 8 (out of 10). Before Palo Alto, I would rate them close to 9.5 (out of 10).

GRE tunneling was always present, but they added some other signatures for Office 365, etc. They are doing that on the back-end, then they publish those in subsequent firmware versions. It is like their Prisma SD-WAN stack team is analyzing the traffic going out. They check all the tickets being sent to them for traffic that is not acting properly or the solution is unable to identify. I do not believe the device itself has machine learning where it checks signatures. For example, if we define some traffic between public and private IPs to be real-time traffic or RTP, then it understands that and keeps those signatures as RTP traffic. There is no machine learning defined on the box itself. It is the back-end team who defines the signatures, then rolls them out.

Positive

We were previously using a legacy system. We had Cisco routers in place. We were defining routes, advertising it out via BGP, defining our own VPN tunnels to different sites and data centers, and then shooting stuff out via the legacy way of doing routing.

We started to utilize this solution due to the fact that every big organization was moving to SD-WAN. It had some promising aspects of quick failovers, smooth transition, etc. The downtimes could be reduced, and it literally did that. Those were our main triggers for bringing in SD-WAN capabilities, and this solution was the best that we could find. Our higher management identified this SD-WAN appliance for deployment all over our firm to curb downtimes.

CloudGenix was still a nascent technology, and not yet acquired by Palo Alto, when we were deploying it in our branch offices. They had ION 3000s and ION 7000s then for data centers.

When we were setting up the solution, it was a complex process because there were a lot of moving parts in its transitioning. 

You need to have certain network policies in place so Prisma SD-WAN can work flawlessly, which can depend on different businesses. We have a custom hybrid network in place, so our deployment is usually complex. 

We had to take care of a lot of things before Prisma SD-WAN could be deployed. In the initial years, the deployment of Prisma SD-WAN was a process where we deployed stuff on certain sites and kept it under monitoring for over a week. Our reason was that all the other sites didn't have Prisma SD-WAN, like they have now. So, there was legacy routing that was interacting with SD-WAN. At that point, it was a little tedious to understand which routes were missing, and which were not. If a site whose MPLS went down and it was live with Prisma SD-WAN, then could it even talk with a site which did not have Prisma SD-WAN and worked on legacy routing mechanisms?

For the initial deployment, you need some type of network communication presence so Prisma SD-WAN can communicate to its cloud. From a WAN management perspective, many times when you create third-party tunnels between branch devices, you need to be certain that you are defining NAT IPs for Prisma SD-WAN. Therefore, on a WAN management base, I would say that one has to isolate the traffic and put certain network policies in place so Prisma SD-WAN can work better before it is deployed.

We understood all the routing stuff happening for a site 15 to 20 days prior to Prisma SD-WAN being deployed there. The deployment activity, if everything went fine, took around four to six hours for Prisma SD-WAN to become live. We then put it in a monitoring bucket for a week to discern whether everything was moving fine.

There were instances where some of our traffic, like the BFD path or some underlying BGP sessions, was affected when we put Prisma SD-WAN in front of them. In those scenarios, the Prisma SD-WAN deployment took upwards of 12 hours for the deployment. 

Prisma SD-WAN stack engineers have underlying kernel administration rights, so our guys cannot log in and see stuff. We had to call Prisma SD-WAN to help us to discern what was wrong. 

The underlying architecture has been smoothed out. There are quite fewer instances where we have to call them to understand the underlying kernel interactions. However, once in a year, we get a situation where we need to call their tech engineers. Then, they type in their usernames and passwords to log into the underlying kernel shell and check stuff out, because we do not have the rights.

The solution has saved us about 50% of our costs.

Moving from a legacy Layer 3 WAN to Prisma SD-WAN has resulted in a reduction in outages.

This solution stood out because it cost considerably less than the other SD-WAN solutions out there from Cisco.

It is a nascent technology when you compare it with the big guys, like Cisco. I am stating this because we have been helping Prisma SD-WAN to mature its technology for the past four years. We had issues where BFD packets were black holed by Prisma SD-WAN. So, we had to remove BFD from our Cisco Catalyst Switches. Though it is fairly mature now and able to route traffic in a pretty smooth manner, there are still some issues, e.g., in every new firmware, sometimes they change their route manipulation base. Now, there is traffic going in and out of a branch office, i.e., traffic from LAN to WAN and WAN to LAN. 

The general cost of Cisco routers is high, and we are deploying Prisma SD-WAN everywhere. This solution costs less than Cisco Routers, saving us time and effort. It is about a 50% cost savings.

I still want to understand why, in subsequent firmware versions, Prisma SD-WAN thinks of changing the route mechanism. Those route mechanisms adversely affect our policy creation. Even though Prisma SD-WAN is a capable device of symmetry, we define and design our network based on those routing mechanisms. However, if they keep on changing with subsequent major releases, then we need to go through all the network designs each time that change occurs.

I would rate it as 7 out of 10. We have many other options coming out from Palo Alto. The interactions between those and other network gears has a lack of documentation. 

The solution is used for multi-cloud and remote access for workers. On top of that is the CASB use case. We are going for zero-trust. If you want to implement zero-trust, this approach is very successful.

The mix between the normal gateway of my firewall and the other branches or the head office firewall is great. The gateway is available on the cloud which allows you to gain access from anywhere and still connect to your home gateway. 

Also, if I want to access a resource on the cloud, it can be accessed from the nearest EU tower data center right from London, not from here where I am.

Its connectivity and security are great.

The initial setup is easy.

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. 

I've used the solution for about two years now. Since they started, I've been using it.

The solution is both stable and reliable. There are no bugs or glitches. It doesn't crash or freeze. 

We mostly deal with medium and large-sized organizations, specifically in retail and multi-national branches. It works well and can scale to meet the needs of businesses of that size. 

It should scale well. We don't have a large implementation - which I would consider as 100 branches or more. Until now, we've been able to handle 35 to 36 branches without issue.  It should scale. I haven't had issues yet in this regard.

Palo Alto support is good. We are an old Palo Alto partner. We're not a customer, however, instead, we have our own setup with Palo Alto. It's not a limitation. They're good. Technical support has been amazing for us. 

I have used both Prisma SD-WAN and Juniper Contrail SD-WAN.

We found the initial setup to be very simple and straightforward. it wasn't overly complex or difficult. 

That said, it depends on how many sites it allows and what the complications related to that might be. If your setup is not ready, and you need to work on it, normalize it, and baseline it, it could take longer. That's it.

For us, for 20 sites, it took us two days to complete with just one resource.

In terms of maintenance, we receive the updates automatically. This is scheduled for the weekends. It's non-disruptive. The updates are frequent. They happen frequently and mostly on the firewall, or the ION itself.

The solution is expensive. Its competitor, Zscaler, is far less expensive. It's half the price. I haven't however, tried it to compare them. 

It's sort of like iPhone versus Android. They are both phones, yes, however, I don't care about the money, I care about the product. I'll choose an iPhone even if it is more expensive due to the fact that I love the experience I get from Apple. The same is true with Prisma. It's not cheap, however, I really appreciate the service they offer. 

There are different ways they can deliver their services, and these have different costs associated. There's Prisma Access, Prisma SaaS, and Prisma Cloud.

We are a Palo Alto partner. 

We are a system integrator and not a customer. We're selling to customers right now.

We are using the solution with a SASE subscription, Prisma Access.

I've used both on-premises and cloud deployments. 

I'd recommend the solution to the users and companies. It comes with all the security and the good direct point to the cloud application as well.

I would rate the solution at a ten out of ten. It's a really great product.