OpenVPN Access Server Reviews

I primarily use Open VPN Access Server as a remote-access VPN to log into our infrastructure.

Open VPN Access Server could be more user-friendly.

I've been using Open VPN Access Server for three years.

Open VPN Access Server is fully stable.

Open VPN Access Server is scalable.

The initial setup was easy.

Open VPN Access Server is open-source and free of charge.

I would strongly advise anybody considering installing Open VPN Access Server to use it. I would rate it as ten out of ten.

We use OpenVPN Access Server to connect from site to site from our data center to our customer site and to dial and access our VPN to our network.

I have been using OpenVPN Access Server for approximately one year.

OpenVPN Access Server is very stable.

I have found OpenVPN Access Server to be scalable.

We have approximately 10 users using this solution.

I have been using Palo Alto and the Fortinet VPN as a comparison to OpenVPN Access Server.

OpenVPN Access Server is complicated to deploy, but we have a script that helps us with it. If we are using a script, it takes us approximately 15 minutes to deploy and without a script, it will take much longer. The process could be easier.

We did the deployment of the OpenVPN Access Server in-house.

We are using the community version of the OpenVPN Access Server and it is free.

I would recommend OpenVPN Access Server to others.

I rate OpenVPN Access Server an eight out of ten.

I mainly use OpenVPN for remote access.

The most valuable feature is that I can access my local network remotely and avoid doing all the port forwarding and redirections, and so on.

The server configuration file needs to be improved, it's the biggest problem in the configuration process. I would also like the product's routing to be easier.

I've been using OpenVPN for almost three years.

OpenVPN is very stable.

The initial setup is a little complex - you need to know what you're doing to go through the process. I would rate the setup process two out of five.

OpenVPN is a free and open-source solution.

Before choosing OpenVPN, I tested the Microsoft Remote Access VPN, and I can say that Microsoft are far away from OpenVPN's level and have a lot of work to get there which can get really expensive.

If somebody asked me about VPNs, I would recommend OpenVPN 100%. I would rate it seven out of ten.

We've been using OpenVPN Access Server for node accessing.

For us, it's important that OpenVPN Access Server is cheap and that we get to use it ourselves. It is also a stable solution.

The scalability of the solution could be improved.

I've been using it for nine years.

It is a stable solution.

It is not scalable. We have 20 people who use this solution. Most of them are developers, one is a system admin person, and one is a DevOps person.

I'm the CEO of the company, and there is a technical team that takes care of the installation. As far as I know, it was straightforward and easy enough for them. I think it took a day to install it.

We have internal staff who implemented it.

It is an open-source solution, so we don't pay for anything.

On a scale from one to ten, I would rate OpenVPN Access Server at seven.

It was very easy to set up users.

The high availability deployment is not very straightforward. They can make it simpler. 

OpenVPN does not support some of the additional protocols that Pulse Secure and Cisco AnyConnect support. They can include support for these additional protocols.

I have been using this solution for close to a year. I set it up and configured it. I also supported it from time to time and documented standard operating procedures because there were other people who were going to maintain it and operate it. We have about 15 users of this solution.

It was not very complicated. I did it for the first time, and for somebody who was doing it for the first time, it was okay. I could do it.

It is important to document the steps so that if one person is not available, another person can continue the work. 

I would rate OpenVPN Access Server a seven out of ten.

We are a solution provider and the OpenVPN Access Server was one of the products that we used for our customers. It is used to create remote desktop connections into the cloud network, where people who are working from home can share resources with people in the office. When people are working in an office then they have a local network, and OpenVPN expands the network for use externally.

We are no longer using this solution because of complaints raised by our customers about security vulnerabilities. The server is now shut down.

This server allows you to connect to a network that does not have any public IP addresses. You first dial-up the OpenVPN to get onto the network, then directly use the private IP for the local device. Once the connection is made, we can do development work, maintenance, or whatever is required.

The most valuable feature is the remote connection capability.

It is easy to use.

There is support for multi-factor authentication.

We would like to be able to access the parts of the network that belong to other virtual LANs, which is not currently possible. For example, if an organization has different VLANs for sales, developers, and production, then we can only connect and view one of these segments. If you can access sales then you will have visibility of that particular subnet and not be able to see the developer VLAN resources.

The security needs to be improved because it was a complaint that our customers had. I'm not sure exactly what the specific issue is, other than they told us that it was not compliant with their organizational policies.

It is not possible to scale this solution horizontally, which is something that should be improved. They could allow multiple instances to run in different zones, synchronizing with each using a round-robin scheduler.

It would be great if they added intrusion prevention and detection (IPS/IDS) features. If they had these then there would be less need to use other products, such as firewalls. It would allow everything to run under one umbrella with centralized control.

We were using OpenVPN for about one year and we migrated away from it about three months ago.

Horizontally, this solution is definitely not scalable. Vertically, it is possible but there will be some downtime. Scaling requires that we stop the server, upscale it, select a different instance, and then restart it. The downtime is approximately five minutes.

I have been in contact with technical support and the experience was good. They have knowledgeable people.

We have migrated to Fortinet because of security vulnerabilities.

The initial setup is easy. Once we go to the marketplace for the license, we can install and start using it. This involves selecting an image, then selecting a VM, and deploying on that. You then install the certificate and create the users. Creating users is also easy to do.

 One person is enough for this task and it will take between 15 and 30 minutes to deploy.

Our in-house team deploys OpenVPN for our customers. After the deployment is complete, users will log in, download their profile, and then they can connect.

Before migrating to Fortinet, we looked at other vendors including Cisco. We found that based on the sizing we needed, the pricing of Cisco AnyConnect was not as competitive.

Personally, I have not found any differences between these products that affect what I need to do.

Personally, I like this product and our decision to shut down the server is in response to decisions made by our customers. I have not found any issues with it, myself.

I would rate this solution a nine out of ten.

OpenVPN is an excellent candidate for establishing secure point-to-point connections between home office locations and satellite locations. It can be configured to limit exposure of the network, from just between the specific endpoints, all the way to full access between local area networks. Performance is consistent and positive. Security has been outstanding, passing some of the greatest tests we've put them to regulating bodies looking for vulnerabilities. If you're looking for a solid solution to establish VPN tunnels between sites, be sure to put OpenVPN on your list to check out.

OpenVPN has allowed me to have the ability to VPN into my environment from anywhere, using Open Source technologies, which helps me control my costs. My clients have capitalized on it when WAN alternatives were too expensive to consider. Yes, there are appliance equivalents out there, but for full customization and low cost, you can't beat it, in my opinion.

The features I have found to be most valuable are the levels of encryption I can enact and the compression I can apply to improve throughput. Obviously, the higher the level of encryption the more difficult it will be to intercept valuable content; and of course, the more we can compress data through the tunnel, the higher the level of relative throughput we can achieve.

The product is fully customized through configuration files, which is all achieved through manual data entry. This is where it becomes unattractive. If there was a Graphical User Interface to help streamline the configuration, I believe OpenVPN would probably venture more into the non-geek realm as it were. What I mean by this is, if there was a form-driven configuration process, like a "File -> Settings" kind of thing, where the end user can enter data into fields to specify the connection specifics, e.g. hostname/IP Address, protocols, etc. that could be written into the config file in the background, similar to what you see in YaST over in openSuSE in some of the services area, etc., and basically foolproof the VPN configuration, you may see more GUI-oriented folks using OpenVPN. Of course in saying this, I anticipate what's going to happen: "Well, give it a try, Elliott!" I'd love to, but my programming skills aren't there yet - I'm a "Edit the file" guy...

I have had a hard time trying to get OpenVPN to crash. I have achieved it on occasion when I am constantly breaking connectivity between the hosts, which I only do when I'm experimenting with things. Otherwise, once your configuration is stable, the tunnel remains stable.

Scalability, as far as I can tell thus far, is limited to the hardware capabilities of your Linux router or host from which you intend to run OpenVPN.

I cannot recall whether I worked with customer support on OpenVPN; being an Open Source project, when you have questions, you really end up working with fellow users in the OSS community. That being said, I can also say that the documentation for OpenVPN is outstanding. It gives you a full explanation of the product and case examples of how it can be applied. From there, you really need to start experimenting with it and post questions to the forums. You will find that people will respond and help you through your issues. People are happy to help out with products they've come to enjoy, and OpenVPN is one of those, as I think you'll find out.

Prior to OpenVPN, I've had some experience with SonicWALL VPN, Fortinet, and CiscoVPN. All of these are fine alternatives, and I rarely experienced a problem using them. The big push for me to look at OpenVPN came when I started to work in heterogeneous environments, using both Windows and Linux.

As I started to discover the options available through the Linux platform, I naturally continued to expand my curiosity and experiment with the options I found. In many cases, I found some that were okay, but too unstable to really consider, and in others, I found outstanding products developed by some brilliant people.

OpenVPN became the perfect solution for me when I tried to connect two DRBD farms together and needed to encrypt the data stream between the two. It made sense to use the product from the host responsible for managing the DRBD stack, and simply add the remote farm via the tunnel. I then began to see other opportunities where I could apply it, and finally jumped in full force.

Going through the setup for the first time will be a challenge. What I have done is write down a procedure to follow, that I have used every time since. I make modifications from time to time, as new features have been introduced, or old features have been replaced. Having a working set of config files available to use as a basis to build out new tunnels have been a blessing, too!

The project I described previously, I developed on my own. I was then hired by my clients to deploy the solution for them. To be honest, I knew nothing about OpenVPN when I started, but I was able to come up to speed pretty quickly. And if I was able to do it, I have no doubt you can be successful, too!

Overall, I believe the ROI is high. The initial investment can be costly, as you go through the process of learning the application. But in the long run, you gain more than just financial benefits; the intellectual knowledge gained can be invaluable.

With regard to setup cost, pricing and/or licensing, the simple answer is that you'll need to set aside some time to learn it and experiment with it. That's the only cost you will incur, with the exception of freeing up some hardware on which you can install Linux. OpenVPN is freely available through all of the major distributions. My experience thus far has been with openSUSE, which is a great platform for you to explore.

In my DRBD example above, I couldn't find a solution without introducing additional hardware between the two farms that either complicated access from authorized hosts or potentially impacted performance. I really needed it to occur at the point of management: the DRBD master of the farm. So, when I am asked, "Did you evaluate other options?", the short answer is "Yes", but on paper only; none of them could accomplish what I needed to achieve.

You can see a quick description of the DRBD project I mentioned on my website along with a graphic showing the layout of it. Visit http://www.scottsolutions.us/p... for more details.

Our primary use case was to give mobile knowledge workers a secure connection across the Internet to our LAN, whether by laptop, mobile tablet or smart phone.

It allowed people to remotely access files from their mobile devices. It was so easy for end-users to use that they were able to work more efficiently no matter where they were, whether at a client’s campus, home, traveling – wherever they had a device and internet access.

This open-source solution provided the easiest UX for our end-users and had the greatest interoperability with all the operating systems we used, including but not limited to: iOS, Android, OS X, Windows, and Linux.

The upgrade path from older versions was more difficult than we wanted to tackle, so we ran an older version of the software for longer than I wanted. Patching, updating, and migrating to newer versions was a problem for us. That said, we were on a rather old version that I inherited yet it worked rock solid.

No issues.

We more than doubled our staff at my previous company and our OpenVPN appliance handled it well.

Tech support wasn’t needed during my 5 years administrating OpenVPN.

OpenVPN was already implemented when I took over the IT department. I do know that there was also a Cisco VPN product in place, but it was finicky and many of our end-users had issues with the Cisco VPN. At the time, it also didn’t work on mobile devices and the required ports were blocked by certain ISPs (like some hotel internet connections, cellular providers, etc.)

In-house expertise.

At one point I had to purchase addition connection licenses. I was very pleased with the pricing and licensing; so much easier than navigating the confusing jungle of Microsoft and Cisco licensing and pricing. That alone made the product a delight to manage.

I didn’t purchase OpenVPN, but I have evaluated other products for other departments I managed at other companies. Cisco and Fortinet are the two I remember off hand.

We did not use this product on AWS. We hosted the server on our network.

My advice would be, if OpenVPN fits your environment and needs, it’s a great solution. Do it.