Hacker News new | past | comments | ask | show | jobs | submit login
Autovpn – Script to Create an OpenVPN Endpoint on AWS (github.com/ttlequals0)
139 points by ergot on Dec 24, 2016 | hide | past | favorite | 62 comments



Trying to make OpenVPN easy to use is admirable. If you're interested in a public-key (RSA) config then it's currently just a disaster to setup, even with the "easy RSA" helper scripts. In my experience the --up and --down hooks and routing are also terrible. I invested hours trying to get it working with a persistent TUN device (so daemons could bind to the endpoint IP before the VPN was up), but OpenVPN is just too bloated and tries to do too much for you, getting in the way.

I recommend people give tinc a try instead. Specifically version v1.1-pre*. It's an absolute doddle to setup, uses Ed25519 key pairs, and plays much more nicely with traditional network configuration.

https://www.tinc-vpn.org/


If you want a VPN in a script, I recommend Algo:

https://github.com/trailofbits/algo

Algo is IPSEC, not OpenVPN (I'm ambivalent about which one is better, but IPSEC has OS-level support on Macs) and carefully chosen parameters.


Algo is great. It actually provisions the machine for you - you run it, and it creates a AWS or GCP or Azure or DO machine for you, installs everything, and spits out a mobileconfig (etc) at the end.


I want to turn Algo into something that a user can set up from their phone. Technical plumbing aside, do any of those hosting providers provide a billing API that allows users to add payment methods?

It would be pretty sweet if you could download an app, enter billing information and get a super fast private proxy.


OpenVPN, since IPSEC is rumored to have been meddled with by three-letter agencies.


This is the rumor you're referring to:

https://news.ycombinator.com/item?id=13221923#13223326

What's more frustrating about claims like this are the premises that suggest IPSEC is somehow unknowable. IPSEC is far better studied than OpenVPN is, and its underlying protocol is simpler than TLS (which, of course, NSA is also routinely accused of having tampered with). More importantly: these are protocols, not ciphers. Not only can we read and simulate and test them, we can in fact prove things about them computationally.

I don't know how to articulate the succinct and conclusive argument that you're "not even wrong", but that's the territory that claim lands you in.


Actually from this: https://en.m.wikipedia.org/wiki/IPsec#Alleged_NSA_interferen...

Doesn't hurt that OpenVPN is more 'open' (heh) than IPSEC+L2TP or IPSEC+IKEV2.


This isn't a coherent theory of NSA interference with IPSEC, but rather a collection of different theories, many of which pertain both to IPSEC and (via TLS) to OpenVPN.

* Here's a deep dive on that OpenBSD IPSEC backdoor theory (long story short: it wasn't one, though even if it had been, it would have affected only an old version of IPSEC): https://news.ycombinator.com/item?id=2014197

* Virtually everyone I know in cryptography believes BULLRUN to be a code name for Dual EC DRBG, which is a backdoor, and targets TLS.

* The Diffie-Hellman attack referred to here was discovered first in (you guessed it) TLS.

As for zero-day attacks again IPSEC software, that is no doubt a thing! But it's no less a thing for OpenSSL.

I don't understand how you manage to get to "IPSEC is less open than TLS", since they're both equally open.


Not IPSEC in itself, but the full stack (tunnel+encryption) implementation in (for example) macOS is completely closed. You could go for something like StrongSwan, but then you lose the advantage you mentioned, namely OS-integration.


"Completely closed"? Isn't it still raccoon?


OpenVPN uses OpenSSL. You might want to look at that.


It does, however you have the option of compiling it with PolarSSL (now mbedTLS).


Looks like AES-128-CBC and no regeneration of Diffie Hellman params. I'm not sure that's the greatest choice when you have full control over the endpoints.


Seems like an easy enough edit to the scripts. What would you recommend instead?


This has good information - http://docs.hardentheworld.org/Applications/OpenVPN/

I noticed DH params do get generated via easy-rsa (although not audited that code, so can't comment on how rigid it is, nor what keysize is being used so that could be defaulting to 1024 which isn't all that great nowadays)


Looking that the easy-rsa 3 script that now comes bundled with OpenVPN, that value is set to 2048 bits:

set_var EASYRSA_KEY_SIZE 2048

# gen-dh backend: gen_dh() { verify_pki_init

local out_file="$EASYRSA_PKI/dh.pem" "$EASYRSA_OPENSSL" dhparam -out "$out_file" $EASYRSA_KEY_SIZE || \ die "Failed to build DH params" notice "\

https://github.com/OpenVPN/easy-rsa/blob/master/easyrsa3/eas...


OpenVPN is pretty slick for point-to-point connections into a cloud environment. We run the server side in a docker container on kubernetes and push the cluster services network routes as dhcp options to clients, so developers can work locally just as if their services were running in the cluster.


Pritunl - https://pritunl.com/ is an excellent and easy to deploy solution. It has AWS and Digital Ocean provisioning, extremely flexible and endlessly powerful. Free for a single server with unlimited users. The config files work with their client or OpenVPN clients.


"endlessly powerful"?


This is a pretty cool project. FWIW, I have a suggestion for the code.

The right way to do this is to use terraform - which specializes in building production grade scripting templates to spin up clusters on a wide variety of cloud providers.

The Openvpn installation itself could be a docker VM.

That way you eliminate the need to build "will it work on cloud provider X and operating system Y?"


Tangentially: We set up StrongSwan recently to use as a VPN into Google Cloud, to allow developers (who all run macOS) to use the nodes seamlessly and interact with Kubernetes and other internal services over a secure connection.

But we met a roadblock when we tried to get DNS to work automatically -- we wanted the GCP boxes to be resolved to their internal IPs, so we set up a DNS server (dnsmasq) on GCP, but there seemed to be no way to tell the client to use it to resolve .internal. There's a plugin/extension available for IKEv1, apparently, but we couldn't find a way to do it for IKEv2. The only way was to configure each client machine's DNS server list (and default domain list) manually, which is not really acceptable.

For now we've switched to OpenVPN, which is fine but requires installing a third-party VPN client on macOS. I would love to know if we could solve the DNS issue and go back to IKEv2. Anyone done this?


The "typical" practice is to use an "up"/"down" scripts to modify the DNS servers when the VPN link goes up/down.

If you just want to use your GCP dnsmasq instance for the .internal top-level domain (not all DNS queries), then you'd want to run a resolver locally that you can configure to selectively forward queries.

This is pretty easy on Linux but I've never attempted it on MacOS. I realize it's probably not ideal but perhaps you can install dnsmasq or unbound on MacOS via homebrew or Macports?


The idea is to avoid any unnecessary client-side configuration aside from the connection itself. Adding a resolver on macOS is easy enough (just create a file /etc/resolver/internal for .internal, containing the IP of the DNS server), but the nice thing about OpenVPN is that you get the DNS config automatically.


For a simple openVPN set up I've used https://github.com/Nyr/openvpn-install with quite a lot of success. It's handy that it let's you add multiple users if you're using it in a commercial setting too.


I use this as well on DigitalOcean. It's easy to create new certs and put them on my various devices so I can disable if I need to. I'll have to check out some of the other ones listed here but I've been using it for a few years now without any issues.


Imagine something like this, wrapped in a nice and simple GUI and supporting a large and ever changing varienty of cloud providers and VPN protocols. That could strike a decent blow against spying and censorship by being significantly harder to block than any single popular service.


Algo VPN supports DigitalOcean, EC2, Google Cloud Engine, Azure, and your own local server. We'll add support for LightSail soon too: https://github.com/trailofbits/algo

Once the project stabilizes, we want to make a GUI that helps people deploy it but it's not that mature yet.


this is awesome; thanks for posting about it.


https://github.com/hwdsl2/setup-ipsec-vpn has one-click options for DigitalOcean (http://dovpn.carlfriess.com/), Azure, Linode


Except it uses L2TP (not IKEv2), 3DES, SHA1, and probably has more issues.


If you are running this from your own AWS account doesn't it have the problem of not anonymizing the traffic - since it can all be tied to your identity?


A VPN isn't always about anonymity. For instance: encrypting traffic in a coffee shop where any and all of your traffic can be sniffed.

Another popular use-case is streaming (paid-for/ad-supported) content from a different region of the globe that is blacked out in your region (and the rights-holders wonder why people still torrent).


If you work with AWS infrastructure in a VPC, sometimes it makes sense to use a VPN to access/manage VPC instances that don't have a public IP (e.g., app servers behind an ELB). Of course, one could also just tunnel through an exposed SSH server in the VPC, but a VPN server can offer a little more convenience and flexibility.


> where any and all of your traffic can be sniffed

*all non-SSL traffic, no?


It's more like all non-HSTS traffic, unless you're paying extremely close attention. Otherwise a man in the middle attacker can just pretend the server doesn't support HTTPS and serve the page via HTTP.

And even when you're using HTTPS you're still leaking DNS queries etc.


Even when you're using SSL/TLS the traffic can still be seen on the network. The difference is that a sniffer will see cipher text rather than plain text.


Wont pretty much all VPNs have this same problem? If you need anonymity, you want something like tor.


Does anyone knows something similar but for DigitalOcean?



Here's a DigitalOcean user-script that can be pasted in to the user-data field on Droplet Creation to create an OpenVPN server:

https://github.com/digitalocean/do_user_scripts/tree/master/...


TrailOfBits' Algo: https://github.com/trailofbits/algo

Also on EC2, Google and Azure. Also not OpenVPN (native IPSec).


What are the differences/tradeoffs between OpenVPN and IPSec?

EDIT: I asked further up on the thread; kindly answer there instead. My apologies for the double-ask.



Try pritunl.


Curious why you would run a VPN on a platform with metered and pricey egress.

Edit: maybe adminstration tasks for AWS? But then, isn't SSH okay for that?


Being able to directly connect to internal addresses from your local dev machine can have it's advantages. Consider the situation where you need to connect to services across a multitude of hosts in an internal network. Using static SSH tunnelling, mapping out each local port to remote host could be a challenge. You can run a SOCKS proxy through an SSH tunnel for dynamic port forwarding, but not everything supports SOCKS.

Another reason could be to bypass censorship / filtering for low volume web traffic websites. You may not trust a paid VPN service.


I've got two "jump boxes" running SSH accessible to 0/0. You can only SSH into any other hosts from one of those two and I do that dozens of times a day without even thinking about it.

It was a quick one-time set-it-up-and-forget-it (to configure "ProxyCommand" in ~/.ssh/config) kind of thing that just works.


You can also one-click install OpenVPN server from AWS marketplace.

https://aws.amazon.com/marketplace/pp/B00MI40CAE/


Others on this thread have mentioned Algo VPN, which uses IPSec instead of OpenVPN.

Googling for IPSec leaves me a bit befuddled; can anyone explain the differences / tradeoffs?

If I felt like setting my personal laptop to always use an IPSec VPN for day-to-day computing, what downsides would I experience?


There's an FAQ entry in the Algo readme about OpenVPN. The biggest tradeoff is that OpenVPN is a little bit easier to setup at the detriment of inheriting all the insecurities of SSL and the requirement to maintain 3rd party software (security updates etc).

https://github.com/trailofbits/algo#why-arent-you-using-open...


I've always been a fan of the 'OpenVPN Access Server'. You literally can't fuck it up and it's basically a one-command install and has a nice web-UI.

Shame it limits you to two concurrent connections but hey, it's free.


I saw there are other images which labeled as "OpenVPN Access Server (N Connected Devices)".

Is the "OpenVPN Access Server" AMI has any limitation?


Best of all, it is offered as a 1-click-install on Vultr.com VPS.


For what it's worth, I used PiVPN (http://www.pivpn.io/) for a quick setup of OpenVPN on a RasPi3 earlier this year - can recommend for convenience, with no comment on security. My main goal was place-shifting...


...takes ~3 minutes

Power of the cloud! Shouldn't this be ~instant? Maybe upload a very minimalist AMI or static overlay to a default AMI instead of whatever route is being used here (I didn't check)?


Would you trust an entirely custom AMI from someone else, or a script with instructions you can read and follow?


Well I haven't tried it so I'm not sure how big the AMI is or what the 3-minute process is, but for sure a script could (optionally) (re-)generate the (repeat build capable) minimal AMI, or the current process could be otherwise streamlined.


What's the advantage to this over ssh tunneling?


TCP over TCP?

https://news.ycombinator.com/item?id=2409090 (6 years ago) - first comment mentions OpenVPN

https://news.ycombinator.com/item?id=9281954 (2 years ago)


Thanks.


It's a network route, so it's invisible to applications.


You can tunnel all of your network traffic over ssh with tools like sshuttle, though.




Applications are open for YC Winter 2023

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: