Live data from Hacker News

StrongSwan – IPsec VPN for Linux, Android, FreeBSD, Mac OS X, Windows

strongswan.org

71–77 of 77 posts

Re: StrongSwan – IPsec VPN for Linux, Android, FreeBSD, Mac OS X, Windows

#71
post #69
post #50

On the subject of VPNs, if people find *swan or Openvpn difficult to get working, I highly recommend OpenConnect (ocserv); _so_ easy to setup. It's an open source implementation of the Cisco AnyConnect SSL vpn, works great and it's compatible with the AnyConnect clients.

Any good Ansible (or other) recipes for this? One I found is [0] but can you point to any others? [0] https://github.com/ftao/vpn-deploy-playbook/tree/master/role...

No idea, sorry. But doing it manually only takes 5 minutes: http://www.infradead.org/ocserv/recipes-ocserv-configuration...

Re: StrongSwan – IPsec VPN for Linux, Android, FreeBSD, Mac OS X, Windows

#72

We use Strongswan to secure host to host connections using pre-shared key when setting up Kubernetes clusters in simple VPS providers like DigitalOcean. This is important since DO, Linode etc does not provide private network. Flannel works with it transparently to provide a Kubernetes-aware ip network. You can see our work here: https://github.com/appscode/swanc

Containerization is cool, however, if you use policy-based VPN, how do you address the use case with more than 1 strongSwan instance (container) running on the same host, obviously sharing the same host Linux kernel.

Re: StrongSwan – IPsec VPN for Linux, Android, FreeBSD, Mac OS X, Windows

#73

Earlier quoted context omitted.

OpenVPN is SSL VPN, relatively easy to setup, it operates in transport layer. strongSwan (IPsec) works in layer 3. To properly install and configure strongSwan, following the tutorials available over the Nnternet is not enough. One needs to have basic networking knowledge (NAT, iptables in particular), good understanding of IPsec protocol suite (including IKE, AH, ESP), PKI, Linux skills and etc. This is a good refer…

OpenVPN isn't really an SSL VPN. In one of the major modes (preshared key), TLS isn't used at all. In client-server mode, TLS is only used for session negotiation (keys, options, user/pass) and the rest goes over their own protocol and doesn't use TLS at all. And even then it isn't TLS over TCP directly, but TLS over OpenVPN's own protocol. For whatever reason, OpenVPN is way easier to get up and running. Little know…

Thanks for pointing out, good insight. Haven't really done a deep dive for OpenVPN as strongSwan works perfectly fine for pretty much all my use cases.

However, strongSwan (IPsec) is easy to block (e.g. if detected by big brother - GFW in China) as by default is uses UDP ports 500, 4500, while OpenVPN can easily disguise as SSL/TLS or anything. In that sense, OpenVPN can be a backup for IPsec for remote access (fighting censorship).

Re: StrongSwan – IPsec VPN for Linux, Android, FreeBSD, Mac OS X, Windows

#74

Earlier quoted context omitted.

OpenVPN isn't really an SSL VPN. In one of the major modes (preshared key), TLS isn't used at all. In client-server mode, TLS is only used for session negotiation (keys, options, user/pass) and the rest goes over their own protocol and doesn't use TLS at all. And even then it isn't TLS over TCP directly, but TLS over OpenVPN's own protocol. For whatever reason, OpenVPN is way easier to get up and running. Little know…

Thanks for pointing out, good insight. Haven't really done a deep dive for OpenVPN as strongSwan works perfectly fine for pretty much all my use cases. However, strongSwan (IPsec) is easy to block (e.g. if detected by big brother - GFW in China) as by default is uses UDP ports 500, 4500, while OpenVPN can easily disguise as SSL/TLS or anything. In that sense, OpenVPN can be a backup for IPsec for remote access (fight…

OpenVPN cannot disguise as SSL/TLS - every packet has an OpenVPN header, so it won't look like, say, an HTTPS connection. And the data packets do not use TLS at all. It would not take much effort at all to detect that a stream is using OpenVPN. Every data packet will start with the same few bits regardless of encryption options used. And the start of a new session has a recognizable sequence of initial bytes, again, regardless of the options used.

Whether or not firewalls are doing enough DPI to figure this out is another question.

Re: StrongSwan – IPsec VPN for Linux, Android, FreeBSD, Mac OS X, Windows

#75

Earlier quoted context omitted.

That's pretty cool. I've considered doing things like that to set up a secure overlay network to lock down a 'sort of' private l2 network. Any reason you didn't use weave?

I have never tried Weave. But StrongSwan sets up host to host tunnel using Ikev2. So, it should probably work with weave. If you find problems, please let me know in github issues.

Ah.. weave has built in encryption, so you would probably use that by itself.

Re: StrongSwan – IPsec VPN for Linux, Android, FreeBSD, Mac OS X, Windows

#76
post #2

With the 4000 LOC Wireguard https://www.wireguard.io/ what are the incentives to continue using IPsec or Strongswan?

StrongSWAN (and IPSec in general) supports smartcards. WireGuard does not.

I've setup StrongSWAN using smartcards almost 15 years ago, at the time it was the only open source IPSec client that supported it. It was relatively easy to get going (the server was a Cisco VPN appliance, which I managed and it was relatively easy to extract the relevant IKE profiles).

Re: StrongSwan – IPsec VPN for Linux, Android, FreeBSD, Mac OS X, Windows

#77
post #70
post #47

Earlier quoted context omitted.

I have a simple bash script that does something similar, including the Apple profile, and also gets you a Let's Encrypt server cert that auto-renews. https://github.com/jawj/IKEv2-setup

Bash is not idempotent, using a public CA has downsides, and MSCHAP has known weaknesses that make the crypto easier to bruteforce.

Right. On the other hand, a Bash script has a low barrier to entry, it's handy not to have to install certificates on the client, and the highest possible security is not always top priority (if, for example, you're just trying to evade your government's illiberal bulk domain/IP address collection policies). Swings and roundabouts, I'd say.
Post reply on HN