Hacker News Reader

Comment by intsunny | Hacker News Reader

I wish more people knew about Pritunl: https://pritunl.com/

It is a 100% open source front end for OpenVPN.

It has one of the slickest interfaces in open source history, and supports numerous features you'd expect from enterprise VPN solutions (SSO, 2FA, etc).

View on HN

Author of Algo here: Pritunl looks great, but Algo aims to use less code to get the job done. Less code = less that can go wrong. We reduced the attack surface to a minimum, don't support out of date clients or crypto, and turned up operating system level hardening to the max. Our goal is to provide the most secure VPN hosting possible with standard clients and tools. Pritunl looks like it optimizes for different goals, and as a result, introduces a lot of additional failure points that I'm not comfortable with. It's certainly the right choice for some people though!

When you write "less code" I see "less readable" and therefore "less maintainable" and more that can go wrong. Less code should not be the goal.

Code is a liability.

Having a dead code base in 3 years because the author left and nobody else wants to decipher it and contribute back is a bigger liability.

The irony here is OpenVPN's code is terrible, unmaintainable and verbose while strongSwan is much better maintained. (OpenBSD's IPSec stack is on another level)

Don't confuse "less code" with "fewer characters and/or lines." Sure, you can write "less code" by implementing trickery in compact bitwise C operators (or, $DEITY forbid, writing a Perl one-liner.) But I've never seen the phrase "less code" to describe that situation.

I see "less code" used to mean that the solution has been distilled down to the essentials without fluff. For example, no need to write a full-featured JSON parsing library when a simple decode-to-native-dictionary will do. I don't have a good example for VPN-related code.

I've never seen the phrase "less code" used as a benefit to describe a code base as a benefit so something along the lines of an eye gouging Perl one-liner is what comes to mind. Using some existing module or library rather than building your own from scratch is absolutely something I would agree with.

Less code can also be the consequence of having less superfluous features.

While less code = less possibility of mistakes, there are more factors at play. OpenVPN is often the best choice for most people, especially people who don't know what they are doing (who else needs a front end).

HTTPS, while seen as a liability in case of IPSec and therefore avoided, is actually good for OVPN. OpenVPN traffic, if set to tcp/443, can pass off as HTTPS traffic, in most cases (except for DPI). I've had problems with IPSec since it operates at a different layer and sticks out like a sore thumb. In environments where the network manager doesn't appreciate VPNs, IPSec is useless.

Better security is important, but not when it comes at a steep cost of not being able to use it when one needs it the most, a not-so-friendly network.

I'm not saying one should go for the 'easy' security, because if OpenVPN is not sufficient for their needs, they shouldn't be using a VPN in the first place.

Reply on news.ycombinator.com