What is our primary use case?
We are using SonicWall for two purposes. One is for clients who want the product for remote access and the other is as a security measure to protect against the recent ransomware attacks. In the latter case, we use SSL-VPN as the initial remote connection to a network and then initiate the connection into the internal network to add a layer of security. This is effective for clients who need remote access as per their requirements for direct connections or mobile users who are using SSL-VPN straightaway.
Some of our clients have remote branch offices where they have only one or two users per branch. Their offices are like a shop or a small outlet where they need connection into the head office because of the company ERP (Enterprise Resource Planning). Some parts of their network are running only at the head office. In that case, we install SSL-VPN into the head office, and then the remote users initiate the connections through the SSL-VPN to their other respective ERP server.
Some clients have other product vendors where they need to give the vendor remote support access to a network securely. In these cases, we give the vendor SSL-VPN connections and then they initialize the SSL-VPN for network access. After that, they do the remote support on the servers through the VPN. It is just additional security measures which we are taking to be sure the company and vendor access is protected.
Then the other use is for mobile telephones. Mobile phones like NEC and Panasonic smart mobile come with an extension. They can't always connect their devices directly so we insert a VPN. Then we can allow them to register their mobiles onto their internal PBX (Private Branch Exchange).
But in general, the main use case is that we are helping to securely connect to the head office from the remote links. This allows access to intranet resources.
How has it helped my organization?
Because of recent ransomware attacks, we can not give access for RDP (Remote Desktop Protocol) connections into the server. Before, we used to give direct connection to RDP and then in the ransomware attacks we got hit by it was very bad because there is not sufficient control over that RDP protocol.
Nowadays, we are using the SSL-VPN for layered security. We are not giving any direct remote access at all. Whatever the case may be, all of the connections have to be routed through a client's SSL-VPN first, and then the users can connect to the RDP or whatever it is they need access to. That way, it saves us from using more difficult security measures. This happens without compromising security or performance. The one thing that happens when you put a lot of security in place is that the network performance degrades. That is true for almost anything you add to a network that makes a device perform additional functions. Like when you do a lot of filtering. It is a little bit of a compromise to use the VPN, but not the level you would have with other solutions. One area which clients can work out for overcoming performance issues — which I have seen done and it works fine — is offloading the SSL-VPN.
But the point is that this SonicWall SSL-VPN solution offers the best protection with the least effect on services.
What is most valuable?
The most valuable part of this solution is that it is faster than other security options when using remote connections both for us and for our clients.
What needs improvement?
I don't really think that there are many ways that this product can get much better for my purposes. Everything is working fine. I cannot find anything here that really needs to be fixed for my needs and really it is perfect as it is. As a user, you have to decide to use whichever solution is comfortable and that solves your problem — whatever that problem may be. That said, there are some things which can help promote the product and its use.
Every customer is influenced by price. They are looking for something to be a lower price as if there is a big competition over only the price and features don't matter because every product is the same. The Dell SSL-VPN product needs to be set at a competitive price or it will lose out to other solutions. Price may be something Dell needs to consider to be competitive in the market.
Recommending the right solution all depends on business needs on a client to client basis. But it is not always the best solution that influences a client's choice. Some of the clients want SonicWall because they see it is a Dell product and they are familiar with the brand or they know someone else who uses it. Then there are decision-makers from other companies who see another product advertised and — for whatever attracted them to the product — they want that product and nothing else. Other people might also say they don't want SonicWall because they don't want Dell. The public opinions all depends on how Dell is doing with pitching itself and SonicWall, and how much they are pushing it in the marketing campaigns they are doing. Depending upon that publicity, they are in competition with other products. If there is an actual comparison one-to-one, people will see there are lots of wizards, all those things that make the product easy to use, it looks okay, and that may be an advantage. But the company needs to promote the product to make the comparison desirable. On the client end, whether it is a global VPN client or SSL-VPN client, it does not matter because it can be made to perform okay. The only thing that matters, in the end, is if it is performing well. But creating a positive face for the business community is something to be improved and maintained by Dell so the product is desirable.
One problem I saw which happens with the product in some cases is where a client uses a mobile device to connect to the VPN. The connection might be coming from a private address because of the local ISP. In that case, the client can face problems when they try to connect. If they are connecting directly, no problem. But if the network is sitting behind a 3G or 4G network and we have the safety measure for remote connections which requires inserting the SSL-VPN, then the client may face a connection problem. Browsing is not a problem, but the SSL-VPN connection can be. They will blame the services for being unstable or unpredictable instead of the networks they are connecting through. That is maybe not a very common problem, but handling this type of situation might be addressed in the product to provide better general connectivity.
An enhancement for the product would be saving configurations to add by drag-and-drop. I don't want it personally but that could be the easiest way to help some kinds of users to deploy the product. For example, there are vendors who specialize in VPN. They install the box, put on the basic API and do the same thing first with all their installations. If they could somehow save this configuration as an object that they can reuse, it would be good for them. They just install the box, drag-and-drop their usual configuration for the box, and it becomes very easy to do deployments. When the vendor says it will take a lot of configuration, it becomes a big pain. Either they or the client may not want a product that is difficult to install and maintain. Implementation improvements would help that perception.
There are still areas that are gray in the area of security. If you ask them, most vendors are not able to tell how security threats are coming exactly and where the weak points are. They give a solution like RDP or this thing or that thing. It may work but they still don't know how it is getting done. I also feel like most companies providing security measures are still researching the topic. In my case, I'm looking for how the ransomware made its attack so we can resolve the actual issue. Everybody has a vague idea but still, nobody knows for sure how that particular infection came into the systems. If they did it would have been stopped. It would be good to know more about what is effective in threat protection.
When you install too much security, people will start complaining. They won't complain about the security maybe, but they could complain about performance depending on the solution. Complicated security introduces performance issues and other issues like files are not being delivered properly. When it takes time, people don't want to wait. That means creating better security without compromising the performance — whatever it takes. Even a small percentage like 2%, 3%, or five percentage in performance enhancement is welcomed. At the same time, you must not compromise on security. If Dell can enhance performance by just a little, it matters.
The last thing is that the knowledge base for the product could be improved for technical users. Again it is not the product that is the problem and it is more like something to do with the technical support and support services.
For how long have I used the solution?
We have been using this product for a minimum of six years.
What do I think about the stability of the solution?
Stability-wise, I don't find any issues. If there is a problem, it is usually due to latency in internet services. It could sometimes be that the FOG (Fibre Optic Cable) cable has broken and then you will not have any services. Once we have configured an installation, we don't even touch the hardware unless there is a significant reason to consider an upgrade. Otherwise, the product itself is pretty stable and we don't have any issues.
What do I think about the scalability of the solution?
So far for us, we have not had much of a reason to scale usage or recommend such to clients for Dell's SonicWall SSL-VPN. We use different things for different clients. For example, sometimes SonicWall will be what we recommend and sometimes we might recommend something like Fortinet. Depending on the needs of that one company, we make different recommendations. We are integrators and we do support our client with what we think is the best solution for them. We try to make the correct decision so we don't regret using the wrong product. We typically use SonicWall based on the clients' size. It can fit for when the client is anywhere from 5 to 60 users. It is a possible choice for a small or mid-sized operation. You can extend it by scaling up to about 100 users. So it is scalable up to a point.
How are customer service and technical support?
The technical support from SonicWall is okay. I have been in this field for the last 30 years. Therefore, most of the time, we solve any issues that we run into by ourselves. We rarely need to call into the support team. If we do it will be for a reason like we encountered something we have never seen before or maybe a problem in an upgrade. But the team is supportive and we work well with them when we use them.
I come to this profession out of the technical side, working from a technical point of view. For the last 10 years, I have been on a techno-commercial side, but I'm more purely from the technical side and work with most of the firewalls. Knowing what I know, I think technical support can grow their knowledge base and that is something that has to be improved for self-service. For example, I think they have to include more installation scenarios, like what you do to customize configurations. That is the most important area they can improve on in the knowledge base.
How was the initial setup?
SonicWall is not very difficult for me to deploy. I think even the layman can figure it out. They would probably configure it by following wizards, but it would work. If it is installed by a technical guy, then you can get detailed in the configuration. There isn't always a reason to get very technical and you ought to know how to do it. That's the thing.
For us, working as an integrator we can do whatever we have to. The client doesn't have to bother whatever is complex. It is our job to solve the issues. For us and our experience, it is pretty easy to do and everything is okay. The more you work on it, the easier it becomes. Usually, the more you work with any product the more you come to know the hidden portions of it.
The first time, it took us a bit longer than it does now. With any firewall — because of the recent changes, upgrades, and advancements to firewalls — a small firewall takes around three to four hours to configure. That is not meaning just a basic installation, it is with a little bit of customized configuration with the DLP's (Data Loss Protection) and that level of configuration details. If it is a bigger firewall for a bigger client, it can take around one day for configuration, testing, and performance adjustments. That is it takes almost a day altogether to finish off the installation. Not just one part alone, it is a total, completed configuration.
What about the implementation team?
We work as consultants so we do our own installation and we work as consultants for other IT companies, as well as regular clients.
Usually, the process which we go through with clients is that we do the deployment and create the configuration. Then we show two, three, or four users how to configure it and the clients take care of it themselves. If they have any issues, they call us and we give them help with things if they need it. But usually, most of the time, any problem that they have is just that they are being silly.
Say they need a total of five to ten users after our configuration. They do one or two in front of us so we are sure they know how to configure users and then the remaining number of users they start doing the configuration by themselves. Maybe they will face some user configuration problems with the initial ten users for special reasons and different remote device access and things like that. After that, they are very comfortable and can take care of it on their own.
From our side, we only require a maximum of two people to implement the deployments.
What's my experience with pricing, setup cost, and licensing?
I don't know about the pricing of the SSL-VPN box. I know the SSL-VPN software is free. Global VPN client, by comparison, is licensed for around $150 or something like that. But the SSL-VPN software is free. It is already built-in with the box.
What other advice do I have?
We like to keep on upgrading to the latest versions because of security and performance advantages. Depending on the client, we push them to the higher versions. The higher versions are often much better and take advantage of enhanced technology. For that reason, we always try to upgrade the client so they have the best security. While we keep on updating, we do study the changes. We don't have an in-house lab but we do testing before deploying to the clients. If it is working fine, then we recommend that upgrade. But primarily, we don't force the updates onto the client because sometimes we do face some problems because of bugs.
In our case, we are using on-premises. We do not have any of our clients using any cloud-based solutions. We are keenly looking into it, but people are still a little bit skeptical of SSL-VPN coming through the cloud. In this part of the world, people are not that trusting in that solution because they do not generally trust deployment on the cloud. Another reason for being on-premises is that we don't have enough bandwidth for this solution and taking it on-premises resolves that potential issue.
Right now everything is working fine with this solution. The SSL-VPN is more compatible with the Mac series, iPhone, MacBook Pros and all Mac devices. Compared to IPsec (Internet Protocol Security), SSL-VPNs are much much easier to configure. SSL-VPN has become very stable and faster than IPsec.
My advice for others looking into implementing SonicWall SMA SSL-VPN is basically, that I feel they should have a look at it as a comparison before taking any SSL-VPN solution. But they also need to do the calculation of the resources like how much bandwidth they need, the right boxes they would have to pick up, etcetera. The minimum requirements have to be there, otherwise, SSL-VPN cannot work as it is supposed to.
The example for this is: Let's say you have capacity on a device for 100 MBPS, you have only 10 MBPS for your upload speeds. This limitation is what the SSL-VPN is going to work with — the standard MBPS speed. This will vary depending on where you are. But this is not the only concern. On the same bandwidth when MBPS speeds are normal, say you can easily have five to six users working and the performance is fine. But say you are experiencing a degradation in performance even though you're having high-end processing devices. Your VPN will be slow with the same number of users if the bandwidth performance drops as there is not enough bandwidth to allocate for that number of users.
This is one of the ideas which users have to really look into before making choices on equipment. The scalability for the SSL-VPNs is affected by the upload bandwidth. It does not matter whatever device you put in place. Without the bandwidth resources, it doesn't make sense to just have the best equipment. The cost calculation, the number of users you expect, and what you are going to want the purpose of the VPN to be will all affect what choices should be made and the success of the deployment.
This is actually one of the biggest lessons I learned in working with the diversity of clients in various areas because of the problems they experienced. We don't want clients to come back and say something is wrong. We have to do a kickoff meeting to do a study on what they have that is an existing solution — if they have anything existing. You have to do your homework on the existing network and set up and then get into deciding what changes to make. That will ease your real burden in support and customer satisfaction and things will work out fine. But just going in and configuring your SSL-VPN like everyone else, you may end up in trouble.
Sometimes, even though a client installation is working for many years, a company we work for as consultants call us back and want to change a configuration in the SSL-VPN. If we go in without really looking at the detailing of their setup, we can end up having a surprise for sure. We need to know what has changed over that time or we can make the same mistakes that we would have made in the initial deployment.
The real lesson I learned most is just to step back and try to collect as much information as possible before implementing any solution for any client. It is not advice that applies for only SonicWall, it applies to any solution. You step back to collect the client's information about the network logic diagrams and other factors that affect their needs. Then take some time to study the information and make the appropriate choices. When you do that, it will go very well without any issues.
On a scale from one to ten, where one is the worst and ten is the best, I would rate SonicWall SSL-VPN as an 8. It is perfect for me but it is not perfect for everyone's needs or solutions.
Which deployment model are you using for this solution?