# Virtual private networks

### On browsing the internet confidentially

Usefulness: 🔧 🔧
Novelty: 💡
Uncertainty: 🤪 🤪
Incompleteness: 🚧 🚧

You don’t want ISPs and governments to annotate the data they already have on you with a list of which sites you visit and when? VPNs, Tor, SSH tunnels can keep what you are doing on the internet quiet.

The EFF tells Americans it is time to get a VPN. This applies also in my jurisdiction, Australia. Probably it is time everywhere, except places like China where may be too late.

VPNs do of course degrade the bandwidth of your internet, but Australians are used to awful internet anyway, so this is not a major issue.

OK, you need a VPN to maintain privacy. Which one? How? Serverwise, do you want to DIY, or pay someone else to provide it? Which VPN software should you use?

(Or should we bypass the internet with a sneakernet or DIY internet? That’s another story.)

## Client-end

Now you want to install the right client software; this is usually fairly straightforward. Just get an account with some VPN provider, and follow their instructions. Two I see mentioned often are Blackvpn and NordVPN. (Disclaimer: I get a cut if you sign up using that latter link.) See below for more on that choice.

This works great for my phone or laptop in some arbitrary cafe hotspot, but it is not ideal for my home devices on the home intranet. See below for VPN access points.

Having set up the VPN there are still data leakages per default. Vpn.ac has a nice basic list of basic privacy steps disabling unsafe behaviour from the web browser end etc, and one should still enable the usual browser safety steps.

### Linux

So you followed the recommended setup for your VPN provider. Good.

Gotcha: OpenVPN is broken for DNS on Linux by default, in the sense that switching to a VPN connection maintains the same old DNS servers. In the absence of further effort, OpenVPN on Linux will use your ISP’s DNS, informing them which site you want and will believe their potentially lying responses. This seems to defeat the purpose.

I think this is not a pure Linux problem per se but because VPN providers tend to provide wrapper scripts for macOS and Windows, one only notices this monstrous oversight on Linux where you are going bareback. Not 100% sure on that, don’t care quite enough to find out.

Lazy detection of this problem via DNSLeaktest who report

As of OpenVPN version 2.3.9 you can now prevent DNS leaks by specifying a new OpenVPN option. Simply open the .conf (or .ovpn) file for the server that you are connecting to and add the following on a new line.

block-outside-dns

For Openvpn before 2.3.9 there is a laborious workaround that no normal person will realistically ever use to automatically change DNS.

One can always use the DNS config to override the DNS to never use your ISPs DNS, which you probably should do. On GNOME/Ubuntu using a large VPN provider with hundreds of servers the default way of doing this will be messy and require hundreds of custom DNS configurations which is no fun at all. 🚧 workaround.

Another problem is that VPN occasionally disconnects and then you are not protected and you don’t notice.

Auto-reconnect is not available in e.g. modern GNOME desktops, but you can access this setting using the command:

nm-connection-editor

To make sure your computer does not leak information during a vpn disconnect, perhaps vpnfailsafe would be a good idea, or other iptables-based hardening.

## VPN access points

Per default, our household devices should not have to route communications between one another via Amsterdam. This is terrible for sharing files from the network files server or copying photos, or streaming from the household media server etc. Instead, our network should be a normal wifi network, but the wire that connects us to the outside world, everything that goes over that wire should be encrypted.

To do that, one sets up a VPN router/access point.

### Make my router do VPN

Tedious. You need a fancy router, and the crappy free one you got from your ISP isn’t fancy. So no one does this. For now, here’s a link to a setup guide from a major commercial provider. Also you can buy a pre-configured one, which you might actually get around to, although it is surprisingly expensive.

### Make a computer into a VPN access point

Any linux machine with wifi can be a wireless access point—even, or especially, a crappy old spare laptop too slow for anything else. This is much cheaper than a fancy router, although with worse antennae. If you want to understand what you are doing here without doing a whole IT degree, the smoothest theoretical intro I have found is Carla Schroder’s Linux Networking cookbook, and there are various explanations on the theory of netfilter. Also Jim Salter’s rant that routers are terrible computers for the price, in the form of a HOWTO, is kinda interesting. Indeed, my former AUD200 router was awful and upon inspection turned out to be very minimally provisioned with only 64MB RAM etc. I suppose there was a good antenna on the box, but also the debuggin/upgrading experience was bad and the thing would lose network connections all the time, so it seems taht a minimally decent computer with a very good antenna would be a better value proposition and also easier for idiots like me who want to plug in a keyboard or such.

Nitty-gritty-I-don’t-care-why-tell-me-how intros? See this grumpy but simple and acclaimed stackoverflow answer. There are some wrinkles.

### SBC VPN access points

One can do this especially economically using a single board computer such as the raspberry pi, which even out-of-the-box has respectable wireless performance. Basic WAP (Wireless access point) setup is supported by the rasppi folks themselves. Here is their recommended setup that worked fine for me as a vanilla AP. I did run into problems with the iptables-restore not running after an VPN reconnect. Mustafa Çalap’s setup is even simpler but AFAICT handles VPN disconnection with even less grace.. The Zentralwerkstatt howto uses a slightly different software profile (adding in isc-dhcp-server and iptables-persistent) than the others, which means you can avoid some of the manual iptables configuration but I’m less familiar with what is going on. I will try this next in the hope it is more reliable. AFAICS the necessary bits of the classic dovyez universal firewall are

#hostAP stuff
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i eth0 -o wlan0 -m state \
--state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i wlan0 -o eth0 -j ACCEPT

# HostAP requires the lines below to both be ACCEPT to function
iptables -A INPUT -j ACCEPT >> /dev/null 2>&1
iptables -A OUTPUT -j ACCEPT >> /dev/null 2>&1

The ZadenRB one includes a hand-rolled web interface, which looks convenient but also flakey. 🤷‍♂ I ignored the bits about web interfaces with this howto. I had the problem that the dnsmasq configuration would never update after openvpn launched on restart, which seemed to be about setup of the /etc/dnsmasq.conf being fragile when things booted up in the wrong order. Also it made lots of rules to enable VPN access TO the pi externally, which is not an extra attack surface I need right now.

So far, even though it looks very long, the two part pimylifeup write-up seems to have worked best. It’s only long because it overexplains; there are not in fact many steps and the very simple setup seems to be robust.

For any of these, one should also secure the pi.

Bonus tip: he wifi might crash for issues related to the brcmfmac driver. Possibly a firmware updates helps. I have experienced this bug on the Raspberry pi 3B+ but it is not clear to me how widespread it is, and I have not reproduced in on recent raspbian builds.

To make sure your intranet does not leak information during a vpn disconnect, perhaps vpnfailsafe would be a good idea.

In practice, this is all stupidly complex, even though it should be a ubiquitous default. Realistically, what I do is usually: try to configure an access point, then discover that there is some weird kernel error/bug specific to the particular device I am using, which has never been seen on the internet, which requires a specialist network nerd, and which I don’t have time to fix. The latest version of the pi and its OS work fine, mind you, but this kind of challenge is very much typical of trying to cobble together security for non-spooks.

I am somewhere in the topmost single-digit percentiles of the population in terms of fluency in stupid geeky shit like this and it is at best marginally feasible for me to work this stuff out and set it up. Realistically most of my friends who have a worse ROI on time spent doing this are not using VPNs and therefore too much data is being leaked to unaccountable surveillance programs. The world is awful.

## Server end

(which provides you this service of confidentiality)

Note, that server virtual machines on someone else’s cloud can never be especially secure from determined nasty persons or state actors. But they do at least prevent concerted profiling by commercial interests, and casual ambient profiling by the state, which is good enough for me.

A commercial VPN provider can probably do that better, with greater expertise, if their intentions are pure. On the other hand, a commercial VPN might be selling your data to evil bastards for their own profit, so… make your own risk assessment.

Two I see mentioned often are Blackvpn and NordVPN (Disclaimer: I get a cut if you sign up using that latter link.).

### Commercial VPN services

That one privacy guy’s big overview is a great list VPN providers by e.g. bandwidth, jurisdiction, and privacy advocacy.

#### Nordvpn

Seem fast and cheap. Their record with disclosing security breaches could be better.

Server configs may be downloaded en masse, as a zip or individually. They have client software. I think it is supposed to sidestep the DNS leak problem amongst other things. It does not for me.

sudo apt install {/path/to/}nordvpn-release_1.0.0_all.deb
sudo apt install nordvpn
mkdir -p ~/.config/nordvpn

You also need to enable some services:

sudo systemctl enable --now nordvpnsd
systemctl --user enable --now nordvpnud

There are quirks in this software.

Firstly it is so insanely aggressive in enforcing VPN that it redirects localhost. You have to whitelist localhost ports individually, using

nordvpn whitelist 12345

(UPDATE: seems to be fixed now.)

The second quirk is that it is closed-source software, and therefore inscrutable..

### DIY OpenVPN server

Running your own VPN/proxy/anonymizing/p2p etc servers can be less convenient for the panopticon in its ceaseless attempts to get up in your business, if you do not trust the VPN providers (but, if it is hosted in a cloud, you do trust the cloud providers.) The tradeoff here is that you want to share a VPN server with other people so that you are collectively anonymized. If it is just me always using the same VPN server then it is not very hard to deanonymise me; I’m the guy who is always using that server. Once again, make your own risk assessment here.

Even easier than real VPN, try turning your SSH login into a quasi-VPN via sshuttle.

sshuttle --dns -r [email protected] 0/0

## Stealth mode

Hiding that you are hiding. obfsproxy and other tor pluggable transports attempt this. It is not so simple and if we really want normal people to go through these tedious steps people will die of boredom before they ever get around to overthrowing their repressive regimes.

You can get pre-rolled scripts from help sites such as scramblevpn which tells you how to make a cheap Raspberry Pi router.

## Tor

Is already its own proxy/privacy thingy.

## Other

How does tcpcrypt fit in?

tcpcrypt is a protocol that attempts to encrypt (almost) all of your network traffic. Unlike other security mechanisms, Tcpcrypt works out of the box: it requires no configuration, no changes to applications, and your network connections will continue to work even if the remote end does not support Tcpcrypt, in which case connections will gracefully fall back to standard clear-text TCP. Install Tcpcrypt and you’ll feel no difference in your every day user experience, but yet your traffic will be more secure and you’ll have made life much harder for hackers.