Posts Tagged openvpn

Improving my OpenVPN Ansible Playbook

I had a working OpenVPN configuration. But it wasn’t the best it could be. The manpage for OpenVPN 2.3 (community.openvpn.net/openvpn/wiki/Openvpn23ManPage) was used to find particularly interesting options.

For most of the changes I had to find examples and more information through Googling, though blog.g3rt.nl/openvpn-security-tips.html is of particular note for popping up very often.

Improving TLS Security

  1. Added auth SHA256 so MACs on the individual packets are done with SHA256 instead of SHA1.

  2. Added tls-version-min 1.2 to drop SSL3 + TLS v1.0 support. This breaks older clients (2.3.2+), but those updated versions have been out for a while.

  3. Restricted the tls-ciphers allowed to a subset of Mozilla’s modern cipher list + DHE for older clients. ECDSA support is included for when ECDSA keys can be used. I’m uncertain of the usefulness of the ECDHE ciphers, as both my client and server support it, but the RSA cipher that’s 3rd in the list is still used. Continuing to investigate this.

The last 2 changes are gated by the openvpn_use_modern_tls variable, which defaults to true.

  1. New keys are 2048 bit by default, downgraded from 4096 bit. This is based on Mozilla’s SSL guidance, combined with the expectation of being able to use ECDSA keys in a later revision of this playbook.

  2. As part of the move to 2048 bit keys, the 4096 bit DH parameters are no longer distributed. It was originally distributed since generating it took ~75 minutes, but the new 2048 bit parameters take considerably less time.

Adding Cert Validations

OpenVPN has at least two kinds of certification validation available: (Extended) Key Usage checks, and certificate content validation.

EKU

Previously only the client was verifying that the server cert had the correct usage, now the verification is bi-directional.
OpenVPN, more about EKU checks: 1 & 2

Certificate content

Added the ability to verify the common name that is part of each certificate. This required changing the common names that each certificate is generated with, which means that the ability to wipe out the existing keys was added as well.

The server verifies client names by looking at the common name prefix using verify-x509-name ... name-prefix, while the client checks the exact name provided by the server.

Again, both these changes are gated by a variable (openvpn_verify_cn). Because this requires rather large client changes, it is off by default.

Wiping out & reinstalling

Added the ability to wipe out & reinstall OpenVPN. Currently it leaves firewall rules behind, but other than that everything is removed.

Use ansible-playbook -v openvpn.yml --extra-vars="openvpn_uninstall=true" --tags uninstall to just run the uninstall portion.

Connect over IPv6

Previously, you had to explicitly use udp6 or tcp6 to use IPv6. OpenVPN isn’t dual stacked if you use plain udp/tcp, which results in being unable to connect to the OpenVPN server if it has an AAAA record, on your device has a functional IPv6 connection, since the client will choose which stack to use if you just use plain udp/tcp.

Since this playbook is only on Linux, which supports IPv4 connections on IPv6 sockets, the server config is now IPv6 by default (github.com/OpenVPN/openvpn/blob/master/README.IPv6#L50), by means of using {{openvpn_proto}}6.

Hat tip to T-Mobile for revealing this problem with my setup.

To-do

  1. Add revoked cert check

  2. Generate ellptic curve keys instead of RSA keys However, as noted above, ECDHE ciphers don’t appear to be supported, so I’m not sure of OpenVPN will support EC keys.

  3. Add IPv6 within tunnel support (Possibly waiting for OpenVPN 2.4.0, since major changes are happening there)

This SO question seems to be my exact situation.

Both this SO question and another source are possibly related as well.

Tried splitting the assigned /64 subnet with:

ip -6 addr del 2607:5600:ae:ae::42/64 dev venet0
ip -6 addr add 2607:5600:ae:ae::42/65 dev venet0
  1. Investigate using openssl ca instead of openssl x509next version of easyrsa uses ca

, ,

No Comments

OpenVPN & China’s Firewall

Ended up choosing an SSH SOCKS proxy + Tunnelblick because it had the fewest moving parts.

Combined with a passwordless SSH key, I saw this status on Facebook today:

Kyle is truly a computer wizard! as in, his Tunnelblick thingy is working!

Location? China.

Success.

8 Comments

Now that I’m actually looking for it

I’m seeing stuff about China’s blocking VPNs everywhere:

New York Times, the BBC, and of course, Slashdot.

Interesting tidbit: OpenVPN over TCP on port 53 apparently works. Not sure why it’d be like that, but maybe it’s something unexpected from infrastructure put in place for DNS poisoning. Possibly unrestricted, but mirrored to the DNS servers, which drop the connection when it’s discovered to be TCP instead?

, ,

No Comments

Tunneling OpenVPN through SSH

Having a bit of time, and remembering that OpenVPN had an option for SOCKS proxies, I decided to take a stab at getting OpenVPN to work through a SOCKS proxy.

It was far easier than expected. Read the rest of this entry »

2 Comments

Tunneling OpenVPN through stunnel

Continuing my string of posts on trying to get OpenVPN working through China’s Great Firewall… and a recent (and unexpected but much appreciated) report that TCP & UDP ports are blocked quickly, I’m now looking at getting OpenVPN to work with stunnel.

My assumption is that the GFW is detecting the OpenVPN packets, since they’re not pure SSL, and then blocking the IP & port combination. (Yay for packet inspection.) So, right now, I’m thinking use stunnel to wrap the OpenVPN packets in a pure SSL connection. Of course, performance is going to suffer, since we’re now triple layering TCP (first layer: stunnel, second layer: OpenVPN, third layer: the actual web browsing).

But that’s enough theory, onwards to the setup: Read the rest of this entry »

,

8 Comments

Getting OpenVPN to run on random ports

As I mentioned in a previous post, I have a friend who’s heading to China. I have an OpenVPN server. I thought the two would match together well, but then China went and started to filter & kill OpenVPN connections, and block those IP/port combinations. People are reporting that using a random port (as supported by their VPN provider) seems to work, and so I looked into randomizing what port OpenVPN ran on. Read the rest of this entry »

5 Comments

OpenVPN and China’s Great Firewall

Slashdot linked to an article on China restricting VPN access, in particular OpenVPN clients. (Also: OpenVPN’s forums has a similar report) The problem seems to be they’ve implemented some sort of protocol detection that’ll flag and block OpenVPN connections after a while. Unfortunately, this is no longer an academic problem for me, since I’ve got a good friend who’s going to be spending a few months in China on a university exchange program; and Facebook/Skype/possibly FaceTime are all blocked.  Read the rest of this entry »

, ,

10 Comments

Getting OpenVPN to work on an OpenVZ VPS

Note: This is a personal VPN, so I just used static keys. A general guide to getting OpenVPN set up is available on the OpenVPN website, but this guide is targeted at CentOS 5 on an OpenVZ VPS.

This guide should be usable in other RH derivatives without much (any?) modification; and with slight modifications for debian-style distros, especially in installing packages and folder paths.

If you’re not running OpenVZ, I’d recommend following the site where the vast majority of this guide comes from, but I had problems with it – I had to mess around with the config files, and the iptables commands *will* kill your SSH session if you run it. Read the rest of this entry »

, ,

7 Comments