OpenVPN vs IPsec VPN

[JoelM]

I am looking at deploying an Untangle unit and will be setting up a VPN for a few traveling workers to access the network and file shares.
I am trying to determine if I will use the free OpenVPN or paying for the IPsec VPN. From this article and a couple of others it seems OpenVPN is actually better even though it's free.

https://www.shellfire.net/blog/pptp-vs-ipsec-vs-openvpn-differences/

Why would I pay for IPsec VPN when I can't seem to find any information that says it's better. I would appreciate any feedback.

Thanks

 

[Markverhyden]

The real question is might your customer show up on someone's radar for some reason. If not I'd think it's a wash.

 

[Sky-Knight]

OpenVPN is light years better than L2TP. UDP carrier vs TCP? (TCP is too bloody slow) Certificate based security that can be hardened with a password or just a password? (Single factor is for idiots)

As far as I'm concerned the IPSec module's L2TP feature doesn't exist, and you shouldn't consider it either. You're signing up to use known broken VPN clients built into various operating systems that will make your phone ring.

Or, you can use OpenVPN...

Now, I'll throw out here the massive catch to OpenVPN on Untangle. The default configurations enable compression, this is a known security issue as compression and encryption at the same time is known to be a general problem. OpenVPN's devs have said they plan to phase out compression from the product over time.

So if you pull out an Untangle right now, and setup the OpenVPN module with all defaults, and then deploy a client to a mobile device... it will connect, but not actually move traffic. Why? Because the mobile clients will not enable compression as instructed by the deployed configuration file from the Untangle server without the user manually going into his client settings and enabling it. For this reason, I advise all Untangle admins on new installs to go into OpenVPN's Advanced tab, and tick the exclude box next to the compress lz4 line in both the client, and server configuration sections.

This will disable compression, and allow OpenVPN to operate in a more secure fashion that doesn't make your mobile devices pitch a fit.

If your OpenVPN module doesn't have a compress lz4 line, and has something else... you may have other issues. Especially if you see comp-lzo. If you have comp-lzo, you need to enable SSH, log into Untangle via the command line and run this command: openssl x509 -text -noout -in /usr/share/untangle/settings/openvpn/server.crt | grep "Signature Algo"

If that spits back MD5 instead of SHA, you've got a server that needs pushed over. The only way to fix that certificate is to remove the OpenVPN module, reinstall it from defaults, recreate your OpenVPN clients, and redistribute them. Old Untangle installs will have an MD5 based certificate chain that's based on a cracked algorithm. There is no upgrade, there is no fix, it must be ripped and replaced.

Which illustrates the largest problem with OpenVPN, the need to maintain an acceptable version of VPN client on the end point, as well as a functional configuration, and a secure certificate chain for authentication. None of this is trivial... but I find all of it is EASIER to manage than the constant drum beat of stupidity caused by the Windows L2TP client!

If you have AAD involved, SSTP and move on.

 

[SAFCasper]

IPSec is still largely the preferred choice for site-to-site connections due to operating at layer 3 (or layer 2 with L2TP). Remote clients essentially behave like they are part of the local network, which is exactly what you want from a site-site connection.

SSL (OpenVPN) is more preferred for remote workers. It operates at a higher level (layer 5/6) allowing you to limit access to services based on the user account connecting. For example you could restrict standard users to just accessing your intranet page while managers can also use an RDS server.

 

[Sky-Knight]

@SAFCasper, Site to Site with OpenVPN performs substantially better, but yes if you need multi-vendor support IPSec is the way to go. In Untangle specifically, that gap is a bit odd because the IPSec module that allows for IPSec tunnels also does L2TP for road warriors. The GUI makes you think it's one service, but it's actually two.

Untangle's IPSec module for site to site IPSec tunneling works wonderfully.

OpenVPN is SSL based, but it doesn't work like an SSL VPN. Untangle however, can use the VPN client's name, as a "username" in the firewall module, allowing for user based access control directly in the firewall module. So you can indeed do everything you just described, and very easily too. The names also make the reports and logs much easier to read.

Oh, and one last thing... IPSec, OpenVPN, or L2TP, the ISPs of the world handle them each differently. So what's "faster" in one actual use case, may not be true in another use case. Because... traffic shaping happens.

 

[JoelM]

Thanks for your help. I have the Untangle unit installed now and we are getting their static IP today. Last night I did a test setup of OpenVPN with their current IP address from my machine and it was crazy easy to deploy. I have not setup a VPN in years because they used to be very difficult so I have a preferred ISP that I work with that if he is providing their internet he will do it for an additional charge. Now with this option it is very easy to do myself.

@Markverhyden I am curious on your feedback regarding the customer being on someone's radar. I don't feel they are but if they were what additional feedback did you have?

 

[YeOldeStonecat]

I used to prefer utilizing Windows native VPN...basically a dial up adapter, versus "thick VPN client" software. The heavier VPN clients (like my years of experience with Sonicwall and Cisco)...used to frequently break and need attention. So this means I'd normally choose L2TP VPN to Untangle.
However, Untangles OpenVPN client is crazy small and simple....so why not?

 

[Sky-Knight]

@YeOldeStonecat The problem with OpenVPN shows up when Untangle themselves use bad settings, which is happening right now. A fresh OpenVPN install will enable compression, a feature that's deprecated due to security concerns. And if you want to change that after the fact, you run into the real technical challenge... the fact that clients are configured using flat text files stored on the client machines themselves. And there is no easy way to change that configuration once deployed. So if you make the change to disable compression, or change the nature of it or anything else on the server side, you wind up having to redeploy all the clients. To make matters worse, there usually isn't an easy way to enable both the old and new configuration for a time, so you can't really cut over cleanly. Microsoft's SSTP client avoids all of this, and can be controlled via InTune or Group Policy. BUT, it's not as easy on the users, despite the automated nature.

I still prefer OpenVPN, with some planning the soft spots can be mitigated, and my users have a very easy time working with it, and when problems crop up, they report those issues more clearly. Which in turn makes support easier.

I do recommend all Untangle admins exclude the compression lines from the client and the server, and redistribute their clients. This will save you a future nuke and pave when OpenVPN removes that functionality altogether. It will also remove the mobile client issues that crop up because compression must be manually enabled on those platforms.

And of course this is after any Untangle installs that started with v10 and were upgraded from there, have their OpenVPN modules removed and reset, without a backup restoration. Everyone needs to get off those old MD5 certificates. I should probably make a write up on how to test for these things... buck I've kicked Untangle to make an admin alert on that one, but no traction so far.