SonicWall NSa alternatives and competitors

Kerio Control is the primary firewall for our corporate network to the outside world. We use an IP transit that connects to an IP transit, so all the internet traffic in and out of the corporate network goes through the Kerio Control firewall. We use Kerio Control VPN Clients for our remote workers to dial into that corporate network with two-factor authentication.

We service all areas of Queensland in Australia and we've got clients from Thursday Island down to the border. We have regional sales guys, agents, and technicians throughout the state that require access to the corporate network for various reasons and that's how they get in. They require access for our call logging system and all that sort of stuff. It's the primary gateway for that. Apart from that, we also run Kerio devices in the field to do point to point VPNs.

We've had very few problems with the VPN features. Once we've set it up, it's pretty functionally user-friendly in terms of the firewall functions that we need to open and close ports on. Our users don't have a lot of problems with it. We've had to reboot it occasionally, but nothing extraordinary. Just standard maintenance rebates. Other than that, it just does the job.

We about 60 users that have access. Concurrently, there's probably only 10 concurrent users at only one time. Because of COVID, there's a lot more remote work going on. It would have been busier over that time, but I haven't actually looked at the stats since then. I know that it worked well and we didn't have any issues. Which is a nice thing not to have to worry about when there's a lot of other things on your plate.

There are only two of us that would really get in there and reconfigure the firewall. Most of the time we'll run that past TechPath anyway, just to make sure that we're not going to punch a hole. We don't intend to. In terms of checking problems, checking logs, in terms of people management as well, seeing who's been logged in, who hasn't, it's very easy to get online and get onto the device and do from anywhere. It's very easy and flexible to use.

Prior to Kerio, we couldn't uncover that data. Prior to Kerio, we were using a hardware device but it didn't have remote access or any of those features. It was something we had to do on-site and it wasn't very user-friendly. It wasn't something that management could do if they wanted to and yet this one's pretty easy if they had access.

The main example of how Kerio has improved my organization would be through the COVID shutdown in terms of just being able to scale. It scales very easily to users that weren't normally remote workers. The fact that it scales well at very little trouble to scale with the amount of users on there, and then to have no issues over that period with increased usage, it did the job. The less I know about it, the better it's doing.

It has saved a lot of time and it was a secure way of doing it too. We had a whole contact center that worked from home for a period of time and that's a 21 hour a day contact center that we moved, that was spread out across the greater Brisbane region and working on home internet connections. Surprisingly, we didn't have a lot of stability issues anyway on those connections, but Kerio didn't blink, so that was good.

We turned on two-factor authentication just after the shutdown when we knew we were going to get more users using it. That was the only feature that I've used recently that was different and it worked fine. You only have to authenticate once every 30 days, once you've fully authenticated. It was easy. Technically, it's not a full implementation. It's two-factor on every login, but it's certainly more secure than it was.

In terms of the comprehensiveness of the security features, I know that we haven't had any breaches before. We've had security issues before but it hasn't been with the data center implementation. We have a technology partner that we use to consult for configuration and Kerio was their number one recommendation at the time. We've never had an issue since implementing that. While it works, it's not an issue for me. Best to our knowledge, we haven't had any data breaches.

We do a lot of audits in terms of data security. I don't know if that's ever been an issue here because a lot of our production stuff is actually walled off from our corporate network so it's of lesser risk factor. We were regulatory. We're a licensed regulatory body as well. We monitor gaming machines throughout the state. A lot of our security and the production network is a lot higher than our corporate. Not that corporate's not high, but there are a lot more freedoms for the user under the corporate network umbrella anyway. But it does what it needs to do. We haven't had an issue with it. The most we've had to do when we've had an issue is upgrade the VPN Client's software.

Before using Kerio, with another software, we did experience security breaches. Not so much with a firewalling product. We've had issues with breaches of user breaches. So phishing attempts and so forth. Just the general user stuff, but not through the corporate firewall. And honestly, we didn't handle all of that previously. We only took that on board about six or seven years ago when we changed ownership. So a lot of our services are in the cloud these days as well. Office 365 and so forth.

In a roundabout way, its security features played a role in our decision to go with it. We rely on the advice of our consultant and the consultant recommended this configuration, this software, and this appliance. So, it was more about the appliance. It was more about the flexibility than what we needed to do in a data center environment as well, to be able to manage it remotely and securely. It's been very easy to manage. 

The consultant was TechPath. TechPath is very good. I have full faith in TechPath. They're an MSP and we've just used them as a consultant when we initially set up our wide area networks and the security around it. They have good guys there. We don't have a lot of network engineers in what we do. That's their job. That's why we use another consultant.

Because it's all ID integrated, it's very easy for a user to get online step by step. And in terms of the actual configuration of the firewall itself, it's an intuitive interface if you know what you're doing, in terms of logging traffic, spanning, and the rest of it. The logging is fine. 

Remote work has been increased by 100%. We would have had around 25 - 30 remote users. That's probably increased to 60 over the shutdown, including contact center staff. That'll scale back a little bit as people come back into the office, but overall, people don't stay connected during office hours, it's more of an as-needed basis. We still only have 10 to 15 concurrent users, but in terms of licensing, we have under five concurrent users at any one time before that. There was an increase, but it was not a resource-hungry increase. We said to make sure the licenses were sourced in advance.

If I would suggest anything, it would be to expand on its multifactor authentication to be a little bit more user-friendly. They should do multifactor authentications for the client itself perhaps, rather than served on a webpage, in a page hijack, that might be more user-friendly, but I don't have a lot of complaints about it. It's doing its job. You have to have a certain amount of skills to configure these things anyway, the ones that we use on-site doing point-to-point, and we've been tricked up a few times with their interfaces. That's been more of an experience thing as well, you have to have some networking experience to understand what you're trying to do when you set up these things, whereas it could be a little bit more user-friendly, wizard-based.

I've been using Kerio Control for six years. It was introduced to us by a previous sister company. We started some of the systems that we took over that were using Kerio Clients and so forth.

We use it primarily to get into our corporate network through a data center appliance. So our off-site workers use Kerio Control VPN to get into the corporate network. We have a private data center space that we use for our production network as well. It's the primary gateway into our corporate network from remote workers. It's a private cloud. We've got our own rackspace in one of the data centers in Brisbane. And then we've got connectivity that lands in the DC to allow satellite sites.

The stability has been very good. I can only think of one or two occasions where we've had an issue and a restart of the firewall seems to bring it up again. I don't think I've ever had a major issue with it at all.

The high availability and failover protection haven't been that critical for us. The stability of it has been so good that we haven't needed to look at it. Because of the use case, an outage doesn't affect us as much as if it was a production network. And TechPath would be on standby with other hardware if we needed or with assistance. So we never really looked at the high availability stuff.

In terms of scalability, we did not see any limitation for the amount of users that we increased to. We had to add some licensing once we evaluated how many end users are going to be in the end but that was very quick as well. I think that came through in a day or two. We just added in the licensing to it and there we went. It was very easy to do. If there was a huge increase in numbers, as in if the appliance itself might need to be increased, but it's actually a virtual appliance anyway so resourcing is not that big a deal. We can increase the resources pretty easily.

Whether or not we increase usage depends on users. I don't think we'll exceed what we've currently grown in the last six months, based on the fact that everyone's currently working remotely. We don't have real plans to expand at this stage but it's nice to know that we can.

I would consider my company to be an SMB. We have 110 staff. Our company is part of a larger group of companies called the Federal Group. Our business unit is 110 employees, and we're fairly self-sufficient in that respect, but the Federal Group of companies is 1,800 employees and we run a number of different businesses around the country, hospitality businesses, casinos, cape transport, trucking companies, that sort of thing. For our size, definitely, it's worked flawlessly for what we needed it to do.

A lot of the IT is within the Federal Group. We've only actually been part of them for just over a year now. They have their own technical services group and a lot of those guys are hardcore Cisco nuts. They're based in Tasmania, which is the other end of the country for us. It's hard to get anything done when we've got to chase someone on the other side of the country. They've desegregated the business unit, so we can manage our own internal business decisions on that infrastructure. But I wouldn't be surprised if they did use Kerio in some form, I know that a lot of those guys are gold plated in what they do.

I haven't contacted their technical support. If there are any issues then I get a network engineer guy first and see if he can take care of it.

We have used SonicWall and I've also used Ubiquiti around the place a little bit, but nothing on a production level. We've played around with Ubiquiti internally. We used to implement SonicWall at our customers to do some deep-end firewalling on their gear but now we're mostly using Kerio devices at the moment in the field as well.

Our systems supplier became our sister company. We got bought and converged in a vertical integration, and then we got divested again. We checked the systems, and the staff from our sister company got taken away to our opposition company. SonicWall was something that we inherited and we weren't really familiar with its use. I was familiar with Kerio's configuration, so we moved to a Kerio device to do the same job.

For our main firewall, the setup was fairly complex at the time because we had multiple internal networks to deal with. We had test environments versus operational environments. We had a lot of rules we wanted to put in place for corporate, so it was complex. It wasn't confusing in terms of how to configure it, but it was fairly complex. 

We started off focusing on corporate first. This was the least risk and then we moved our production phases over to that as we were confident in that we were secure and connected up correctly, so to speak, or the data center configuration was the way we needed it to be. Then we did a little post-testing in the configuration, not just with the firewall and stuff, but overall with penetration testing.

The deployment didn't take very long. TechPath took care of most of it. In terms of the site to site stuff, we do that fairly regularly. It might take an hour to configure devices, but it's not onerous. You've just got to make sure you get the settings right. The setup required a few engineers from their end, myself, and another employee. 

We do maintenance once a month and it requires one person. It doesn't quite a lot of maintenance because we just give it a courtesy reboot more than anything like we do with a lot of our gear. We just make sure that the updates are up to date, from time to time.

I have definitely seen ROI since the shutdown. Given its stability and its function, it certainly hasn't slowed down our ability to produce in a diverse environment especially with the contact center. A lot of what they do is hybrid Software as a Service, telephony, and all the rest of it, so having corporate access was key to be able to do their jobs. We went from a very secure, regulated on-prem environment to a diverse working from home environment overnight, and Kerio was key to that.

I never had to go out there and try and find an alternate solution because Kerio just did the job. I don't know how long it would've taken or how much it would've cost, but it certainly would have been at best, a minimum of setting up a much more permanent type of secure connection from each user's premises. It would have been a lot harder to do.

I didn't even blink at the price but I can't even remember what it cost. It was pretty reasonable. The cost was very affordable. We just ended up licensing our own because we didn't know who was going to be working remotely at the end of the day. I think anyone that had a chance to work at home, they got the license. It wasn't a factor of having to do to a view and make sure that every user absolutely needed one. It is a very affordable solution.

There are no additional costs to the standard licensing that I know of. We maintain the highway that it sits on and obviously the data center space and there might be transit and costs and that sort of thing associated with it, but not with Kerio itself. 

We didn't really look into other solutions. We were using MikroTik routers to do some of the work, but not really. Rather than learn SonicWall, we just switched to Kerio, because we we're familiar with the interfacing.

The biggest lesson I've learned from using Kerio is that you can quite easily and securely diversify your network security and access without compromising on cost and central control. Since this all comes down to is that it's all centrally controlled, I have confidence that the users were accessing our systems remotely and securely.

We have used the Kerio Control appliances to do point to point VPNs at the customer sites quite a few times now, and that's the one we recommend. Customers have been using Ubiquiti and have issues so we replaced them with Kerio appliances and they seem to work great. They're moderately priced, good value, and I haven't had to reboot one of those devices in the field yet. These things run point to point VPN for some pretty business-critical functions, such as wide-area gaming systems that transfer money between venues. I haven't had any issues.

I would rate Kerio Control a nine out of ten.

We are a managed services company, and we are also a partner with Fortinet and Cisco Meraki. The firmware that I just started using is 6.4.4. Most of the FortiGates that I sell are 60E and 60F. For some of our larger customers, I have got a handful of FortiGate 80, 100, and 200.

Fundamentally, its primary purpose is security at the edge of the network. I have got some clients who are starting to use the SD-WAN feature for a multi-location setup. I have got other clients who are using a lot of IPSec tunnels. I also have some clients who, with the increase in remote workers, are taking advantage of the FortiClient product that ties in. They are using that for remote VPN connections. 

We are a managed services provider, and I would say that it has improved the way our client's organization functions. I would also hope that it is seamless for them. They don't even know it. The biggest improvement for us is that it allows us to do more with a smaller staff.

One of the nice things about FortiGate is that it can be deployed on the cloud or on-premises. You can actually do both. That's the biggest reason why I stick with this solution as opposed to something like Cisco Meraki. Another nice thing is that I can log directly into a FortiGate or get to it through their FortiCloud access products. They're pretty reliable and consistent.

One of the reasons why I started using the product was their single pane of management. I can deploy their line of firewalls in conjunction with their switching and access points, and I can manage the entire network from one interface. I don't have to log into one interface for the firewall, another one for the access points, and another one for the switches. These firewalls have access point controller functionality built right into the system, so I don't even have to purchase additional devices to manage them.

FortiLink is the interface on the firewall that allows you to extend switch management across all of your switches in the network. The problem with it is that you can't use multiple interfaces unless you set them up in a lag. Only then you can run them. So, it forces you to use a core type of switch to propagate that management out to the rest of the switches, and then it is running the case at 200. It leaves you with 18 ports on the firewall because it is also a layer-three router that could also be used as a switch, but as soon as you do that, you can't really use them. They could do a little bit more clean up in the way the stacking interface works.

Some use cases and the documentation on the FortiLink checking interface are a little outdated. I can find stuff on version 5 or more, but it is hard to find information on some of the newer firmware.

The biggest thing I would like to see is some improvement in the switch management feature. I would like to be able to relegate some of the ports, which are on the firewall itself, to act as a switch to take advantage of those ports. Some of these firewalls have clarity ports on them. If I can use those, it would mean that I need to buy two less switches, which saves time. I get why they don't, but I would still like to see it because it would save a little bit of space in the server rack.

I have been using this solution since 2007.

If you have the firmware version 6.4.3 and are using FortiLink in VLAN, it has trouble with tunneling networks for a wireless network. It won't give it a route to the internet. I found it just last week. There was a version back in 6.2 where it required 12 characters for the password of a wireless network on Web 2.0 as opposed to the traditional eight characters. The problem came when you wanted to edit it. If you upgraded to that firmware from a previous version, it wouldn't let you save any changes without changing the password, making it a requirement. That was kind of problematic for a while, but for the most part, it has been pretty stable and responsive.

It is easy to scale as long as you start with the right firewall. Our clients are of different sizes. We have clients with the home office with two or three employees. One of the clients has about 26 locations in all four time zones and about 400 employees.

I haven't used their official tech support, which is actually a good thing. The reason I haven't used their official tech support is that they have a support mechanism in place. I have direct access to a local sales engineer, and when I have problems, I call him up on the cell phone. Based on that, they definitely support their partners 100%. They are definitely channel driven, and it shows.

I have deployed SonicWall, WatchGuard, Cisco ASA, Rockies, and Palo Alto. The biggest reason I went with Fortinet is that it felt like it has got Palo Alto type of functionality at a much more reasonable price point.

I spent seven years working at the state level education, and budgets were tough. We had SonicWall subscription services. I could replace them with the brand new FortiGate with a three-year subscription for the same cost. That really changed things. The single pane of management that they have was just the frosting on the cake.

It is pretty simple. For example, I just set up a new network with a 100E, and I have got four stackable switches. It will run a network with 23 access points. I set up all the VLANs, routing, rules, and other things. It won't take more than four hours of work. I am getting ready to box up and ship it out. It will be plug and play once it gets to the site.

Take the training. They've got free training that is available online, and there are different levels for technical training. It is crucial. If you sign up as a partner, which doesn't cost you anything, the training is free. If you want to go for the test and get certified, you got to pay for the test, but the actual training materials are available to every partner for free. I would say that definitely take advantage of those. When you have new employees as network engineers, make this training a part of the routine.

I would rate Fortinet FortiGate an eight out of ten. I have been using it for years, and I do try to evaluate it on a regular basis and continue to stick with them. I just don't have a lot of bad things to say about them. Aside from their product, I'm a also fan of their company and how they do business, which makes it easier to do business with them. I don't necessarily appreciate the business practices of some of their competitors. It is nice not to have to worry about that.

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.

We use it to segregate traffic between different tenant instances and to manage secure access to environments, DMZ zones, and to communicate what the firewall is doing.

With Palo Alto NG Firewalls, we can pass all compliance requirements. We trust it and we are building the security of our environment based on it. We feel that we are secure in our network.

It also provides a unified platform that natively integrates all security capabilities. It's very important because it gives us one solution that covers all aspects of security. The unified platform helps to eliminate security holes by enabling detection. It helps us to manage edge access to our network from outside sources on the internet and we can do so per application. It also provides URL filtering. The unified platform has helped to eliminate multiple network security tools and the effort needed to get them to work together with each other. In one appliance it combines URL filtering, intrusion prevention and detection, general firewall rules, and reporting. It combines all of those tools in one appliance. As a result, our network operations are better because we have a single point of view for our firewall and all related security issues. It's definitely a benefit that we don't need different appliances, different interfaces, and different configurations. Everything is managed from one place.

The most valuable features include the different security zones and the ability to identify applications not only by port numbers but by the applications themselves.

The DNS Security with predictive analytics and machine learning for instantly blocking DNS-related attacks works fine. We are happy with it.

And with the single-pass architecture, it provides a good trade-off between security and network performance. It provides good security and good network throughput.

The machine learning in Palo Alto NG Firewalls for securing networks against threats that are able to evolve and morph rapidly is good, in general. But there have been some cases where we get false positives and Palo Alto has denied traffic when there have been new updates and signature releases. Valid traffic gets blocked. We have had some bad experiences with this. If there were an ability, before it denies traffic, to get some kind of notification that some traffic is going to be blocked, that would be good.

In addition, there is room for improvement with the troubleshooting tools and packet simulator. It would help to be able to see how packets traverse the firewall and, if it's denied, at what level it is denied. We would like to see this information if we simulate traffic so we can predict behavior of the traffic flow, and not just see that information on real traffic.

I have been using Palo Alto Networks NG Firewalls for about three years.

The solution is pretty stable.

The scalability is good.

In terms of the extensiveness of use, it depends on business needs. Every communication from the company is going through this solution, so it's highly used and we are highly dependent on the solution. 

In terms of increasing our use of the solution, it all comes down to business needs. If the business needs it, and we get to the limit of the current appliance, we will consider updating it or adding more appliances. At this point, we're good.

We previously used Cisco. The switch was a business decision and may have had to do with cost savings, but I'm not sure what the driver was.

The initial setup was a little bit complex, but not terrible. The complexity was not related to the product. It was more to do with needing to prepare and plan things properly so that in the future the solution will be scalable. If there were some predefined templates for different use cases, that would help. Maybe it has that feature, but I'm not familiar with it.

The time needed for deployment depends on the requirements. We also continuously optimized it, so we didn't just deploy it and forget it.

Our implementation strategy was to start with allowing less access and then allowing more and more as needed. We made the first configuration more restrictive to collect data on denied traffic, and then we analyzed the traffic and allowed it as needed.

We have less than 10 users and their roles are security engineers and network engineers. We have three to four people for deployment and maintenance and for coordinating with the business, including things such as downtime and a cut-over. The network and security engineers work to confirm that the configuration of the solution is meeting our requirements.

We did it ourselves.

I'm not sure about pricing. I don't know if Palo Alto NG Firewalls are cheaper or not, but I would definitely recommend Palo Alto as an option.

If you need additional features, you need additional licenses, but I'm not aware of the cost details.

We evaluated Cisco, Sophos, Dell EMC SonicWall, and FortiGate. Cost and reputation were some of the key factors we looked at, as well as the flexibility of configuration. Another factor was how many users could comfortably work on the solution when publicly deployed.

The fact that Palo Alto NG Firewalls embed machine learning in the core of the firewall to provide inline, real-time attack prevention is important, but I still don't completely trust it. I haven't really seen this feature. Maybe it's somewhere in the background, but I haven't gotten any notifications that something was found or prevented. At this point, we still use traditional approaches with human interaction.

Overall, what I have learned from using Palo Alto is that you need to be very detailed in  your requirements.

My clients are mostly based in the government. They are my core clients. I install the solution for my clients.

The solution is very easy to use. 

Of course, we have the skills, however, it's very easy for us to deploy the solution. That's one of the valuable features. 

They have a communication between the endpoint and the firewall which is very, very useful for security purposes.

Pricing is now pretty good. They changed the pricing structure a few months ago.

The initial setup is pretty easy.

The integration could be a bit better. They need to allow their solution to integrate with other products and not just other Sophos solutions.

Sophos has a feature that in my opinion is very limited. They don't have enough VPNs on their models. They have the XG 750, which is a sizeable appliance. On those models, they used to have not enough VPNs. They always were short on that area. 

Pricing used to be very bad, however, they've adjusted their strategy recently. 

The product needs to improve its marketing in Mexico. It's not a well-recognized product in our country.

The solution's technical support is very bad.

There is an overall lack of documentation in relation to features and capabilities. We need these to help explain aspects of the solution to our clients. 

I've used the solution since around 2014. I have about six years of experience at this point. It's been a while. I've definitely worked with the product in the last 12 months.

The solution is quite stable. There are no bugs and glitches. It doesn't crash and freeze. It's quite reliable. We don't have problems with it.

The solution is very scalable. It is not a problem. Sometimes we have issues when we are trying to do something with a different traditional version of hardware as sometimes the new hardware has more ports. However, if we are talking about scalability in a huge customer, we can do it very easily. 

Mexico is very different than other countries and continents as here, when we say it's a big customer, we are talking about 2,000 to maybe 3,000 users. There aren't too many large-scale operations in the country. However, in general, for our area, we tend to deal with large-scale companies.

For a company that has maybe 1,000 users, Sophos seems to work very well. We have one operation with 10,000 endpoints and it is working quite well.

Technical support from Sophos is very bad.

Sometimes we lose a project due to the fact that we need to solve some issues or answer questions. Things that may be technical but also involve the administrative side. I'm talking about licensing and the capabilities of the feature. We need some documentation, something we can show clients. They can better in those cases. They can either help us or supply us with what we need. 

In response time, they are terrible. In the area of technical knowledge, they are getting better, however, they aren't where they need to be. Right now, we are not satisfied with the level of support provided.

The initial setup is not complex. However, here in Mexico, it's very complex to sell the product. The brand is not as well known.

That said, the process is pretty straightforward. 

The deployment times vary. It depends on the end-user and what they need. Sometimes, it's easy as they don't have too many policies. The more policies they have, the longer it takes.

In other cases, clients may have a lot of VPNs. We have to work on those VPNs, and we have to do a lot of routing. However, that depends on the customer. Not all are like that.

For one appliance, you just need one person for deployment and maintenance. If we are working a lot of VPNs, we would have to use more people. We need to involve maybe two or three individuals and re-apply the configuration in that case. 

We handle the installation process ourselves. We do not need the assistance of consultants.

The pricing has recently changed on Sophos. Their licensing and cost structures are much more clear now. It's much better than it was.

Clients, in many cases, evaluate for Check Point, Forcepoint, and sometimes Fortinet. Occasionally, they may look at SonicWall, or Palo Alto however, the others are the main big competitors. 

Palo Alto is very expensive as are Check Point and Forcepoint. That's why we sometimes win the projects. We find Fortinet, is very, very hard to beat as they have a lot of market share, have a lot of marketing. Sophos doesn't have that presence, that marketing. Also, when you have to think about prices, Fortinet gives customers everything and it's hard to beat.

The biggest issue I've found with Sophos is the small number of VPNs that we can do compared to a similar appliance with Fortinet or in the same level center. In fact, many other brands offer more VPNs than Sophos.

I'm a Sophos reseller.

We use multiple versions. We have worked with XG 460 and XG 135 and some others -such as XG 230. In those cases, sometimes it has been Rev 1 and in other cases Rev 2 in terms of the hardware versions.

I mostly work with on-premise deployments. The only item I have installed in the cloud is an email solution by Sophos.

I'd recommend the solution to other organizations. Overall, I would rate it at a nine out of ten.