Comment by terrywang | Hacker News Reader

Comment by terrywang | Hacker News Reader

strongSwan is the best free and open source IPsec implementation available on Linux, (much better than libreswan...), good documentation, use cases and examples etc, good quality of code (less bugs - that's what we've found running it in production for 2+ years with 500+ instances deployed) actively developed and maintained by a group of passionate developers that knows the stuff well.

Personally I've been using strongSwan since its 5.0.x for remote access - protect privacy and fight censorship (yes, originally from China where the infamous GFW is deployed...). The native strongSwan client for Android is also a killer feature worth mentioning, RSA authentication with X509 certificates works flawlessly with 1 click ;-)

My company (pre-IPO startup) has been using strongSwan for 2+ years as site-to-site solution from AWS VPC to on-premises data centres (or other cloud virtual network), with 500+ instances deployed, track record has proved it reliable as long as it's properly configured (most outages were caused by AWS maintenance ;-) The only drawback is that strongSwan currently does NOT have a mature HA solution but it's shaping up (5.4.0 introduced IKEv2 redirect). We are currently building a custom HA solution (designed to work in VPC - provide similar redundancy to AWS VPN but a lot more flexible and controllable) using strongSwan (have to use route-based as syncing 2 policy based instances are too hard or impossible).

NOTE: I've seen people mentioned L2TP, it is obsolete. L2TP does NOT provide encryption or confidentiality to traffic passes through it. L2TP/IPsec encapsulates data twice at layer 2, it has pros and cons. See this (may be out-dated) -> https://www.bestvpn.com/blog/4147/pptp-vs-l2tp-vs-openvpn-vs...

IKEv{1,2} + IPsec (ESP) (tunnel mode) with PFS for both ike and esp is recommended configuration.

As mentioned in another comment: To properly install and configure strongSwan, following the tutorials available over the Internet is not enough, it requires good networking knowledge (NAT, iptables in particular), understanding of IPsec protocol suite (including IKE, AH, ESP), PKI, Linux skills and etc.

A good reference to start with: https://raymii.org/s/tutorials/IPSEC_vpn_with_Ubuntu_16.04.h...

> NOTE: I've seen people mentioned L2TP, it is obsolete. L2TP does NOT provide encryption or confidentiality to traffic passes through it.

Would you clarify how it's obsolete, because it's doesn't follow from "L2TP does NOT provide encryption or confidentiality..."? AFAIK no one uses L2TP by itself, as there's no shortage of encapsulation protocols (GRE, AYIYA, vxlan, etc.) for other purposes. In practice L2TP/IPsec are always paired akin to TCP/IP, even though in theory you could do things like TCP/IPX or TCP/AppleTalk, or whatever. In the context of VPNs, L2TP/IPsec is "the protocol" even though they are two distinct pieces.

> L2TP/IPsec encapsulates data twice at layer 2, it has pros and cons. See this (may be out-dated) -> https://www.bestvpn.com/blog/4147/pptp-vs-l2tp-vs-openvpn-vs....

Sure it's not optimal, but for its intended purpose, establishing VPNs from roaming devices to intranets, the overhead hardly matters. IMO, what does matter is client device and network[0] compatibility, and L2TP/IPsec is hard to beat here. I wouldn't say that OpenVPN or other VPN solutions obsolete L2TP/IPsec in this aspect, either.

For (semi-)permanent site-to-site VPNs I agree just use IPsec.

[0] IIRC last time I chimed in on L2TP/IPsec you or someone else in the thread disputed that firewalls were generally not an issue for IPsec, contrary to my personal experience. Maybe I've just been extremely lucky, so I'll conceded this point.

Yup, it's the most actively maintained branch of all the XXXswan projects.

My experience has been that it's trivial to setup for site-to-site IPSec tunnels using PSK. It's literally install the package, copy a config file from the docs, start the service, done. I've been using it in scenarios like this for a while, works great even when the remote ends of the tunnel are something else (Cisco appliances, AWS VPN endpoints, etc).

I'm a little less sure how to implement it as a VPN endpoint for employees. There are two main issues here:

1. Having to support a variety of clients (Android, iOS, Mac OS X - perhaps also Windows and Linux)

2. Doing multifactor authentication in a way that works well

Especially when considering #1 and #2 together, it seems difficult to meet all demands. How to do multifactor in a way that works with many different clients? I don't much care what the "factors" are as long as they are "multi". E.g. certificate + individual password.

If I only had to support, say, user/pass authentication, I think that would be somewhat easily doable.

Any clues?

No idea for #1, but regarding multifactor, I've used Strongswan with Feitian PKI smartcards. Basically, I have one card that I set up as a CA and use to sign CSRs for "user" smartcards as well as for the VPN servers. You need to have your card and PIN to connect. The private keys are stored on the cards - no PSKs. This is something cool to do if you are cheap. You may be able to do this with Yubikeys, though I haven't tried this.

https://wiki.strongswan.org/projects/strongswan/wiki/SmartCa... https://github.com/OpenSC/OpenSC/wiki/Feitian-PKI-card

edit:

Some quick and dirty instructions to generate keys/certs that you can use with a Linux or Android client:

git clone https://github.com/ramann/smartcard-pki

cd smartcard-pki

git checkout vpn-phone

# Edit etc/vpn_server.conf to use your server's IP address

bash -x <(cat README.md | grep '`' | tr -d '`') # You really should generate the VPN server's key & request on the VPN server, but this is just to get something working

# Move vpn_server_key.pem, ca/signing-ca.crt, certs/vpn_server.crt, certs/phone.pem to your VPN server's /etc/ipsec.d/

# Edit your VPN server's /etc/ipsec.conf so that leftcert=vpn_server.crt and rightcert=phone.crt

# To set up your Android phone, just import the phone-and-ca.pfx file

# To set up your Linux client (Ubuntu 16.04 in my case), move phone_key.pem, ca/signing-ca.crt, certs/vpn_server.crt, and certs/phone.crt to /etc/ipsec.d

# Edit your client's /etc/ipsec.conf so that leftcert=phone.crt and rightcert=vpn_server.crt

# To start server: sudo ipsec start

# How to start the Android client should be obvious.

# To start linux client: sudo ipsec start; sudo ipsec up connection_name

Reply on news.ycombinator.com