Never Ending Security

It starts all here

Advanced Privacy and Anonymity Using VMs, VPN’s & Tor

Advanced Privacy and Anonymity Using VMs, VPN’s, Tor, etc

Part 1 – Introduction

By mirimir (gpg key 0x17C2E43E)

If you’re here, you may be using (or considering) a VPN service to provide online privacy and anonymity, and perhaps to circumvent Internet censorship. This series of guides goes far beyond that. It explains how to obtain vastly greater freedom, privacy and anonymity through compartmentalization (aka compartmentation) and isolation, by using multiple virtual machines (VMs) with Internet access through nested chains of VPNs and Tor.

These are advanced guides, and the full setup will require at least a few days of focused work. Before choosing which aspects to implement, it’s best to consider your threat model. Start by reading An Introduction to Privacy & Anonymity and Applying Risk Management to Privacy. What are you protecting? Who are you protecting it from? What might happen if you were compromised?

The key threats, and corresponding defenses, are:

THREAT DEFENSE
Tracking and profiling Compartmentalize and isolate activity using multiple pseudonyms, workspace VMs, VPN services and Tor
Leaks and exploits that circumvent VPNs or Tor Compartmentalize and isolate workspace and networking in separate VMs
VPN compromise via traffic analysis or provider collusion Compartmentalize Internet access and distribute trust using nested chains of VPNs and Tor
Heightened surveillance of Tor users Connect to Tor network through VPN(s)
Heightened surveillance of VPN users Connect to VPN server(s) via secure, private proxies (not yet included in these guides)
Unauthorized local access Use full disk encryption (FDE) on host machines (and VMs)
Forensic detection of encrypted data Use hidden Truecrypt volumes for plausible deniability (not included in these guides)

For example, if you just want to circumvent Internet censorship and data retention by your ISP, you don’t need more than a good VPN service (unless consequences of getting caught are serious). If you just want to circumvent commercial tracking and behavioral marketing, you don’t need the full setup described here. However, if you want better privacy and anonymity than browser extensions can provide, you might consider a basic setup (covered in Part 2) to compartmentalize your activities using VMs and VPN services.

Conversely, if you’re a political dissident who might suffer serious consequences if compromised, using the full setup (covered in Parts 3-8) would be prudent. The approaches described there would probably protect against non-targeted surveillance by national-scale government agencies. For such agencies with limited resources, they might even protect against targeted surveillance.

Although it appears that global-scale intelligence agencies intercept virtually all Internet traffic, the approaches described here might protect against routine non-targeted surveillance, given the need to correlate traffic through multiple VPN tunnels and Tor. While there’s no way to be sure of that, it’s clear that nothing less would suffice.

However, it’s unlikely that even the full setup described here would protect against directed surveillance by global-scale intelligence agencies. That would require far more resources and expertise than most nations (let alone individuals) possess.

Using Tor

As I write this, the Tor network is under extreme stress. Since August 20, the number of Tor clients has increased from about 0.5 million to over 4.0 million. Based on reports from Fox-IT and TrendLabs, it appears that the approximately 3.5 million new Tor clients are part of a Mevade botnet. So far, these Mevade bots are not sending much traffic, and are stressing Tor primarily by querying its directory servers. See this Tor Project blog post for more.

At this point, this has probably not reduced the level of anonymity that Tor can provide. It’s just made Tor slower and less reliable. However, if more than a few thousand of these bots were to become relays, there would be cause for concern, because they could collude to deanonymize other Tor users. A recent paper by Tor researchers, Johnson et al (2013) Users Get Routed: Traffic Correlation on Tor by Realistic Adversaries analyzes the network’s vulnerability to potential adversaries. I recommend periodically checking the Tor Project blog for status updates, and also checking Tor client andrelay counts.

Summary

PART 2 – BASIC SETUP USING VMS, VPNS AND TOR
This guide covers a basic setup to protect online privacy and anonymity. There are multiple workspace VMs to compartmentalize and isolate activity. Each VM has its own Internet connectivity, and firewall rules to prevent leaks. It uses simple nested chains of VPNs and Tor to mitigate risks of tracking and profiling, and to distribute trust among multiple providers. But it does not protect against exploits that circumvent VPNs, Tor and/or firewall rules by isolating workspace and networking in separate VMs.
PART 3 – PLANNING ADVANCED VM AND VPN SETUP
This guide presents relevant considerations for planning an advanced setup to protect online privacy and anonymity. As in the basic setup, there are multiple workspace VMs to compartmentalize and isolate activity, and each VM has its own Internet connectivity. The nested chains of VPNs and Tor are more complex, to better mitigate risks of tracking and profiling, and to distribute trust among more providers. The setup isolates workspace and networking in separate VMs to defeat exploits that circumvent VPNs, Tor and/or firewall rules.
PART 4 – SETTING UP SECURE HOST MACHINES
This guide explains how to set up Linux host machines for securely running numerous VMs. Linux distributions are open-source and free, so there’s less risk of backdoors, and no money trail to one’s true name. With clean installations, there’s little (if any) risk from prior compromise. RAID arrays provide faster disk I/O, greater capacity and better reliability. Using full disk encryption (FDE) prevents forensic analysis, unless the host is accessed while in use.
PART 5 – INSTALLING VIRTUALBOX AND CREATING LINUX VMS
This guide covers installing VirtualBox, and creating Linux workstation VMs and read-only LiveCD VMs.
PART 6 – CREATING PFSENSE VMS AS VPN CLIENTS
This guide covers creating pfSense router/firewall VMs, and configuring them as secure VPN clients, with routing and firewall rules to prevent leaks. It also explains how to test for leaks using Wireshark.
PART 7 – PAYING ANONYMOUSLY WITH CASH AND BITCOINS
This guide explains how to anonymously buy VPN services using cash by mail and anonymized Bitcoins. It also covers how to buy Bitcoins, and how to anonymize them using Multibit clients and mixing services, with all connections via Tor.
PART 8 – CREATING NESTED CHAINS OF VPNS AND TOR
This tutorial explains how to create arbitrarily complex nested chains of VPNs and Tor through virtual networking, with pfSense VPN-client VMs and Tor-client VMs.

Acknowledgement

These guides reflect my participation at Wilders Security Forums for the past few years. I acknowledge the administrators and moderators for the venue, and for their care and guidance. But mostly I acknowledge the Wilders’ user community (especially fellow privacy lovers) for great answers, tough questions, and lively discussions.

I also acknowledge IVPN for invaluable support and encouragement.

Finally, I acknowledge the global open source community, without which none of this would have been possible.

Part 2 – Basic Setup Using VMs, VPNs and Tor

By mirimir (gpg key 0x17C2E43E)

Introduction

This guide covers a basic setup to protect online privacy and anonymity. It’s appropriate for reliably circumventing Internet censorship and data retention by ISPs, and for reliably circumventing commercial tracking and behavioral marketing. It may be adequate for political dissidents in countries that respect human rights. However, it is not adequate for political dissidents who might suffer serious consequences if compromised. For them, using the full setup (covered in Parts 3-8) would be prudent.

In this setup, the host machine reaches the Internet through a VPN service, with firewall rules to prevent leaks. The host runs VirtualBox, and there are multiple Linux workspace VMs to compartmentalize and isolate activity. Each Linux workspace VM initially reaches the Internet through the host machine’s VPN service. It then connects through a different VPN service, or through the Tor network, to reach Internet sites. There are firewall rules to prevent leaks. For Tor connectivity, the guide uses Whonix, which comprises Tor gateway and workstation VMs that are based on Linux (Debian).

VirtualBox by default isolates resources (storage, memory and processing) that each VM is using, both from itself and from other VMs. Although the Linux workspace VMs (and the Whonix gateway VM) all use the host machine’s VPN connection through network address translation (NAT), VirtualBox doesn’t permit VM-to-VM traffic in that arrangement. Linux workspace VMs (and the Whonix workstation VM) are also isolated from each other on the Internet, because they have different IP addresses and network latencies.

Because Whonix isolates workspace and networking in separate VMs, it resists attacks that compromise or circumvent Tor and/or firewall rules. However, the VPN client running in each Linux workspace VM is vulnerable to such attacks. Even so, the VPN client running on the host is isolated, and so damage is limited. In the full setup (covered in Parts 3-8), all workspaces and networking (VPN and Tor clients) are isolated in separate VMs.

Setting Up VPN on Host Machine

If you’re already using a VPN service, you can skip to the next step. If you’re not already using a VPN service, choose one and install the client following the provider’s instructions. For Linux, you can use the instructions below, in “Setting Up VPN on Linux Workstation VM”.

Unless you’ve already set up firewall rules to prevent leaks, it’s prudent to do so. All traffic (including DNS queries) should go through the VPN tunnel, and there should be no Internet connectivity if the VPN connection fails. Also, just in case, DNS queries should use the VPN provider’s DNS server(s), or reliable third-party DNS servers, and not your ISP’s DNS servers.

There are instructions below (in “Installing and Checking VPN-Firewall on Linux Workstation”) for using adrelanos’ firewall setup in Linux. For Windows, you can ask your provider, or use (for example) Comodo. For OS X, you can ask your provider, or use (for example) PF.

It’s also prudent to test for leaks. There are instructions below (in “Installing and Checking VPN-Firewall on Linux Workstation”) for leak testing in Linux. The same approach applies in Windows or OS X, except for installing and configuring Wireshark. For Windows, see (for example) HOW TO : Install Wireshark on Windows 7. For OS X, see (for example)WireShark Install on Mac OS X.

Installing VirtualBox

This step is trivial. Download the version of VirtualBox for your host machine OS fromhttps://www.virtualbox.org/wiki/Downloads. For Windows hosts, install by executing the downloaded file. For OS X hosts, double click the downloaded file, and drag the app to the Applications icon. For Ubuntu hosts, open the downloaded package with Ubuntu Software Center, and install. For Debian hosts, use dpkg in a terminal. After installing VirtualBox, download the Extension Pack, and open it with VirtualBox to install. That’s it. With VirtualBox running, hitting F1 opens the user manual, which is excellent and comprehensive.

Creating Linux Workstation VM

Creating VMs is very easy, and section 1.7 of the VirtualBox manual (hit F1) explains it well. It’s a two-stage process. First, you configure the new VM in VirtualBox. Second, you start the VM, and install the OS, just as you would on a physical machine.

Linux is the best choice for a secure and private workstation VM. It’s open-source and free, so there’s no money trail linking you to a product ID. Ubuntu is a good choice for new Linux users. It’s best to use releases with long-term support (currently 12 .04). For those who dislike the Unity desktop, Xubuntu and Mint (both based on Ubuntu) are good alternatives. Debian is arguably more secure, but not as user-friendly.

First download the 32-bit (aka i386) installer image file for the Linux distro that you’ve chosen. Then open VirtualBox, and click the New icon. Enter your desired VM name, and select the proper OS type (Linux) and version (Ubuntu for Ubuntu, Mint or Xubuntu) or Debian. Specify 1 GB memory to avoid disk swapping. If host RAM is limited, you can reduce it later. Use the defaults for virtual hard disk type (dynamically allocated VDI) and location, but specify at least 100-200 GB maximum size. The initial size of the virtual disk will be at most 5-6 GB. But with large maximum size, it’s very easy to accommodate unplanned growth. After reviewing the final summary screen, hit Create.

Next, tweak the new VM’s settings. In the General/Advanced tab, leave Shared Clipboard and Drag’n’Drop set toDisabled (for security). Under System/Motherboard, change the boot order to Hard Disk, CD/DVD, and deselect Enable absolute pointing device. Under System/Processor, select Enable PAE/NX (if your host supports it). Under Display/Video, increase video memory to 128 MB (unless host RAM is limited). Under USB settings, deselect Enable USB Controller (for security).

Now add the OS installer image. Under Storage, highlight the CD icon (named Empty) under IDE Controller. Then hit the CD icon to the far right of CD/DVD Drive, and select Choose a virtual CD/DVD disk file. Navigate to wherever you put your installer image, and select it. Then click OK to exit the settings screen.

Then double click on the new VM, and go through the install process. It’s OK to accept all defaults. But you can select the encrypted LVM option for disk partitioning , if you like. Although whole-disk encrypted VMs may leave plaintext on host machines, that’s better than nothing if the host is compromised while running. As the VM is rebooting after installation completes, click Devices in the main menu, highlight CD/DVD Devices, and select Remove disk from virtual drive.

To get better VM performance, you may want to install VirtualBox guest additions (customized kernel modules). Guest additions also provide better display and mouse integration, and enable mounting host folders (aka shared folders) in the VM. However, some of the kernel customizations may reduce guest-host isolation, and using shared folders definitely does. It’s a typical convenience vs security trade-off.

Ubuntu or Xubuntu will prompt you to install the guest-additions kernel-module package as additional drivers. If not, use the Settings menu. You can also install guest additions by clicking Devices in the VirtualBox menu, and then Install Guest Additions. But don’t do both. Debian 7.10 automatically installs the guest-additions kernel-module package.

Now reboot, use Update Manager to download and install updates, and let the system reboot again. You’re done.

Setting Up VPN on Linux Workstation VM

These instructions are for OpenVPN-based services. For IPsec-based VPN services, follow your provider’s instructions. Avoid PPTP-based VPN services, because that protocol is extremely insecure.

Start by setting up Network Manager with OpenVPN. Open a Terminal window, and run these commands:

user@ubuntu:~$ sudo apt-get install network-manager-openvpn
user@ubuntu:~$ sudo restart network-manager

Then review your VPN credentials – certificates (.crt) and keys (.key) – and configuration files (*.conf or *.ovpn). Some VPN services provide configuration files with embedded credentials, with each of the credentials bracketed by corresponding [name] and [/name] tags. In that case, copy each of the credentials, and save as an appropriately-named text file. There may be as many as four credentials:

  • ca.crt
  • client.crt
  • client.key
  • ta.key

All of these files should be downloaded via HTTPS, and kept private. You might want to avoid providers that don’t use HTTPS for this. Establishing a VPN connection may also require a username and password, which may differ from the account name and password for the VPN service’s website. Some low-end services email connection username and password. In that case, immediately go to the provider’s website, and change the password.

Virtually all VPN services provide a ca.crt (certificate authority) certificate. These certificates enable clients to verify the authenticity of VPN servers before connecting. Most VPN services also provide a client.crt (client certificate) and client.key (for unlocking and using the client certificate). Client certificates allow VPN servers to verify the authenticity of clients before accepting connections. A few high-end VPN services also provide a ta.key to enable TLS authentication, whichincreases connection security.

You’ll also need other information from the OpenVPN configuration file. First, you’ll need to choose the VPN server that you’ll be connecting to. Avoid the United States, United Kingdom and France. Germany and the Netherlands are OK. It’s probably good to avoid Eastern Europe, Russia, China etc, which might attract attention. You’ll need the IP address of the server, rather than the hostname, in order for VPN-Firewall (see below) to work properly. If you just have hostnames, you can get the IP address by running this command:

user@ubuntu:~$ host hostname.that.you.have

Second, you’ll need to know the server port number and connection type (UDP or TCP). It’s generally best to use UDP (unless you’re routing via Tor). You’ll also need to know the cipher type (from the cipher … line) and whether LZO compression should be enabled (if you see comp-lzo). If cipher type isn’t specified, use the Network Manager default. For VPNs that provide ta.key, you’ll need to know the key direction, which is the number at the end of the tls-auth line (typically 1).

Start the setup by copying all of the VPN certificate and key files to /etc/openvpn. Open a Terminal window, and run these commands:

user@ubuntu:~$ cd /home/user/path-to-the-files
user@ubuntu:~$ sudo cp ca.crt client.crt client.key ta.key /etc/openvpn/

Of course, edit the second command for the files that you actually have.

Then open Network Manager, select the VPN tab, and click the Add button. Select OpenVPN as type, and click the Createbutton. Enter a short name for the connection, and the IP address of the server that you’ll be accessing. The next steps depend on the configuration of the VPN service.

There are three common VPN-configuration setups. Some VPN services (such as Private Internet Access) provide only ca.key, and require username and password for connection. For them, select Password as authentication type, enter your username and password, and click the CA Certificate button. In the Places window, click File System. Double click etc, and then double click openvpn. Finally, select ca.crt and click Open.

Now click the Advanced button. In the General tab, check Use custom gateway port and enter the appropriate port number. If appropriate, check Use LZO data compression (typical) and Use a TCP connection (rarely appropriate unless you’re routing via Tor). If you know the cipher type, click Cipher in the Security tab, select the appropriate one, and clickOK. Now click Save in the VPN window, and close Network Manager.

Some VPN services (such as AirVPN) provide ca.key, client.crt and client.key, but not ta.key, and don’t require username and password for connection. For them, select Certificates (TLS) as authentication type, and then specify User Certificate(client.crt), CA Certificate (ca.crt) and Private Key (client.key) as described above. Then complete the same steps in theAdvanced window as described above, save the VPN configuration, and close Network Manager.

Some VPN services (such as IVPN) provide ca.key, client.crt, client.key and ta.key, and also require username and password for connection. For them, select Password with Certificates (TLS) as authentication type, and enter your username and password. Then specify User Certificate (client.crt), CA Certificate (ca.crt) and Private Key (client.key) as described above. Complete the same steps in the Advanced window as described above. In the TLS Authentication window, check Use additional TLS authentication, and specify Key File (ta.key) and Key Direction (typically 1). Then save the VPN configuration, and close Network Manager.

Now use Network Manager to establish the new VPN connection. Once it connects, verify that it works by visitinghttp://whatismyipaddress.com. If it doesn’t connect, or doesn’t work, recheck the configuration.

Installing and Checking VPN-Firewall on Linux Workstation

Install adrelanos’ VPN-Firewall scripts as described at https://github.com/adrelanos/VPN-Firewall. You want the firewall (iptables rules) to load at bootup, so install both the firewall and init scripts. Reboot the VM, but don’t reconnect the VPN via Network Manager. Check VPN-Firewall status by running the following in a Terminal window:

user@ubuntu:~$ sudo service vpnfirewall status

It should reply 0. Then verify that the VM has no Internet connectivity by trying to visit http://whatismyipaddress.com. If it connects, there’s something wrong with the VPN-Firewall setup.

Now use Network Manager to establish your VPN connection, and verify that it works by visitinghttp://whatismyipaddress.com. If it doesn’t connect, recheck the configuration. If it does connect, test VPN-Firewall by killing the openvpn process (run sudo killall openvpn in a Terminal window) and verifying that the VM has no Internet connectivity. Then use Network Manager to reestablish the VPN connection, and verify that it works by visitinghttp://whatismyipaddress.com.

Check your DNS servers by running the standard DNS test at https://www.grc.com/dns/. It should report only the DNS servers that your VPN service is pushing. It should not report any DNS servers that are associated with your ISP, or are specified by your LAN router. If it does, there’s something wrong with the VPN setup.

You can also check for leaks using Wireshark. To install Wireshark, open a Terminal window in the VM, and run these commands:

user@ubuntu:~$ sudo apt-get update
user@ubuntu:~$ sudo apt-get install wireshark

Then configure wireshark to allow a non-root user to sniff packets. As described here, run these commands in a Terminal window:

user@ubuntu:~$ sudo dpkg-reconfigure wireshark-common
user@ubuntu:~$ sudo adduser $USER wireshark

Reboot the VM, and establish your VPN connection. Then open Wireshark, and start capturing on eth0. Use Firefox to checkhttp://whatismyipaddress.com, run the DNS test at https://www.grc.com/dns/, etc. Now stop the capture, and run Statistics/Endpoints. You should only see one non-private aka public IP address, that of the VPN server that you’re connected to.

Now kill the openvpn process (run sudo killall openvpn in a Terminal window) and start a fresh capture on eth0. Verify that Firefox can’t see anything. VPN-Firewall blocks pings, by the way. Stop the capture, and run Statistics/Endpoints. You should only see traffic with local private IP addresses, and reconnection attempts from the VPN server that you were connected to.

Finally, reestablish the VPN connection in Network Manager, and verify that it’s working. Then start Update Manager, download and install updates, and let the VM reboot.

Installing Whonix

Whonix comprises a pair of Debian VMs: a gateway VM that connects to the Tor network, and a workstation VM that connects through the gateway VM. Installing Whonix is easy. Start by downloading Whonix-Gateway and Whonix-Workstation to your host machine, using your VPN service. It’s best to verify the downloads as instructed using the OpenPGP signatures and the Whonix signing key. If you can’t be bothered with that, at least download them using BitTorrent (which is more secure, as explained).

Import the gateway and workstation VMs, using File / Import Appliance in VirtualBox (reinitializing MAC addresses). If you’ll be using just one Whonix instance, just start the Whonix gateway, and then the workstation. Download and install updates as instructed. After rebooting both VMs, you’re done. Enjoy!

If you’ll be using multiple Whonix instances, each gateway and workstation VM must have a unique name (which determines the name of its folder). After importing the first pair of gateway and workstation VMs, edit their names in the VirtualBox GUI, adding a unique suffix (or whatever) to distinguish them from others that you’ll be importing (and to facilitate keeping track of them).

Also, the gateway and workstation VMs of each Whonix instance must share a uniquely named internal network. First edit the settings for Adapter 2 of the gateway VM (under Network). Change Whonix to Whonix-1 or whatever. Don’t change the settings for Adapter 1. The default (“NAT”) will have it connect through your host’s VPN service. Then edit the settings for Adapter 1 of the workstation VM, changing Whonix to whatever you just used for Adapter 2 of the gateway VM.

Now start the first Whonix gateway, and then the workstation. Download and install updates as instructed. After rebooting both VMs, you’re done. Enjoy!

Part 3 – Planning Advanced VM and VPN Setup

By mirimir (gpg key 0x17C2E43E)

Introduction

This guide introduces an advanced setup (implemented in Parts 4-8) which provides vastly greater privacy, anonymity and freedom than the basic setup presented in Part 2. Basic Setup Using VMs, VPNs and Tor. It employs compartmentalization(aka compartmentation) and isolation, by using multiple virtual machines (VMs) with Internet access through arbitrarily complex nested and branched chains of VPNs and Tor. The full setup will require at least a few days of focused work. Please review Part 1. Introduction and consider your threat model before choosing which aspects to implement.

This advanced setup broadly resembles the basic setup presented in Part 2. The host machine reaches the Internet through a VPN service, with firewall rules to prevent leaks. There are multiple Linux workspace VMs to compartmentalize and isolate activity, and the various workspace VMs independently reach the Internet through VPN services or the Tor network. It’s easy to deter profiling and tracking by using multiple pseudonyms in multiple workspace VMs, with different Internet IP addresses. Impacts of malware and hacking are limited, as long as the VMs networking services and VPN client are not compromised or circumvented.

However, the advanced setup goes far beyond the basic setup in a few key ways. Rather than using an existing and potentially compromised system (typically Windows or OS X) as VM host, this setup uses a fresh Linux installation. Because Linux is open-source, there is also less risk of backdoors. Furthermore, because most Linux distributions are free, there is no money trail that might link you to a product key, or other unique information in the installation.

In the basic setup, the Linux workspace VMs (except Whonix) contain both applications and networking services (routing, firewall, VPN client, etc). By exploiting vulnerabilities in applications and users, attacks may readily compromise or circumvent the VPN client, and then deanonymize users by contacting a monitoring server directly, rather than through the VPN tunnel. Attacks may also install malware that deanonymizes by “calling home” when the VPN is not connected. Indeed, any document that automatically loads remote resources, such as this IVPN logo IVPN logo, can do the same.

In this advanced setup, all workspaces and networking services (VPN and Tor clients) are isolated in separate workspace and gateway VMs (pfSense VPN-client VMs and Tor-client VMs). Attacks that exploit vulnerabilities in applications and users can’t reach networking services unless they can also compromise or circumvent VM-host barriers. And because workspace VMs can only reach the Internet through their gateway VMs, there’s no access to remote resources when the gateway is down or broken, except through deliberate user error.

Furthermore, in this setup, the arrangement of gateway VMs and VirtualBox internal networks transparently creates layers of encrypted routing instructions, which then direct packets through specified chains of VPN servers and Tor entry relays. That is, packet routing through the Internet reflects local routing of gateway VMs in VirtualBox. Using the VirtualBox GUI, it’s trivial to create and modify arbitrarily complex nested and branched chains of VPN and Tor connections. It’s also possible, using the VBoxManage command-line interface, to automate changes in routing topology (not included in these guides).

Indeed, this is a simple (and static) implementation of onion routing:

Onion routing is a technique for anonymous communication over a computer network. Messages are repeatedly encrypted and then sent through several network nodes called onion routers. Like someone peeling an onion, each onion router removes a layer of encryption to uncover routing instructions, and sends the message to the next router where this is repeated. This prevents these intermediary nodes from knowing the origin, destination, and contents of the message.

Initial Privacy Considerations

If you’re, for example, a political dissident who might suffer serious consequences if compromised, it would be prudent to read these guides, and download required software, using a secure VPN service. Otherwise, your ISP and other local observers can see what you’re doing, and you might be flagged for increased scrutiny. Ideally, local observers should see only that you’re using a VPN service, and nothing else. If you’ll be chaining multiple VPNs, as described below, it’s best to pick one now that you will connect to directly. Consistently using just one direct-connect VPN service arguably attracts less attention than using many VPN services and Tor.

If you’re currently using a VPN service, adopting it as your direct-connect VPN would be best, as long as it’s privacy-friendly and its performance is adequate. Unbiased sources for information about VPN services include discussions at Wilders Security Forums (which uses a self-signed certificate) and annual reviews at TorrentFreak. Connecting indirectly to your current VPN service through a new direct-connect VPN would arguably be pointless, because there are potentially records associating your account there with your ISP-assigned IP address.

If you’re not currently using a VPN service, now is a good time to pick one that you’ll be connecting to directly. For direct-connect VPNs, the key features are speed (high bandwidth and low latency), uncapped usage (throughput) and mainstream popularity (so you stand out less). You’ll typically be using just one direct VPN connection, and so it’s arguably better to reserve services that permit multiple simultaneous connections, and have exit servers in many countries, for use as indirect VPNs (which you will access through your direct-connect VPN).

Unless you’re already using a VPN service and/or Tor, install your chosen direct-connect VPN client on the machine that you’re reading this on, following the provider’s instructions. Also download all required software on this machine, so your ISP etc can’t see what you’re doing.

At the cost of increased complexity, by choosing the high-privacy option in the next tutorial (Part 4. Setting Up Secure Host Machines), you can hide all evidence of your new setup from your ISP and other local observers. They’ll just see downloading through your direct-connect VPN service.

Using Nested Chains of VPNs and Tor to Distribute Trust

It’s crucial to keep in mind that, by using VPN services, we are merely choosing to trust our VPN providers, instead of our ISPs and governments. We can choose VPN providers that use multiple hops, promise not to keep logs, carefully segregate our account data and their VPN servers, and even claim that they will move or shut down before compromising our privacy. But there is no reliable way to know whether our trust has been warranted, unless we discover that it hasn’t.

If privacy and pseudonymity really matter to us, therefore, it’s not prudent to rely merely on a single VPN provider. Instead, we can distribute our trust by routing one VPN tunnel through another, from a different provider. More generally, we can create nested chains of VPN tunnels from multiple providers. In order to compromise our privacy, an adversary would need to compromise or subvert most (if not all) of the VPN services in our chain(s).

This approach is vulnerable in at least two ways. First, there may be money trails to “inner” (in a topological sense) VPN services that we access indirectly through other VPN services. Using free VPN services is an option, but they typically cap bandwidth and throughput. The best option is paying with cash by anonymous snail mail. Another option is paying with Bitcoins that have been thoroughly anonymized using multiple anonymous accounts and mixing services.

Second, some (or all) of the VPN services in our chain(s) may be vulnerable to compromise or subversion by broadly resourceful adversaries. To mitigate this risk, it’s prudent to choose providers that operate from poorly-cooperating geopolitical spheres of influence (SOIs). It’s best to avoid providers in the SOI where you live. For your direct-connect VPN, it’s arguably best to choose a provider in a relatively-neutral SOI, which doesn’t attract too much attention, and yet is at least somewhat hard to subvert. For your terminal/innermost VPN, it’s arguably best to choose a provider in an effectively non-cooperating SOI. If you’re using three or more VPNs overall, it’s arguably best to alternate between distinct poorly-cooperating SOIs for the middle VPNs.

We can also rely on Tor, a highly sophisticated implementation of onion routing, where trust by design is distributed among numerous participants with disparate goals. It provides far greater anonymity than VPNs (even complex nested chains of VPNs) could ever manage. However, configuring applications to use Tor properly (with no leaks) is nontrivial, and it’s best to use packaged setups.

The Tor Browser Bundle comprises Tor and the Tor Project’s version of Firefox, which is optimized for anonymity. Although it’s very easy to install and use, it’s vulnerable to malware exploits and leaks from applications misconfigured by users. The Amnesic Incognito Live System (Tails) is a LiveCD (read-only by default) which can also be run as a VM. It’s preconfigured with many applications. But it’s still vulnerable to malware exploits that circumvent Tor. Both Whonix and Incognito isolate workspace and networking services in separate gateway and workstation VMs. That protects against deanonymization through user error, misconfigured applications or malware exploits.

It’s best to incorporate Tor at or near the end of nested VPN chains. VPN services are popular for P2P file sharing, and using them arguably attracts less unwanted attention than using Tor, except where file sharing and dissent are both forbidden. Indeed, access to the Tor network is blocked in some places. One can circumvent blocks by connecting through bridge relays. However, as bridge relays are identified and blocked, users must switch to new ones. Given the trial and error process of using bridge relays, they do not reliably hide Tor use. It would be safest to use both VPNs and obfuscated bridges, which obfuscate Tor traffic patterns.

Some Internet sites don’t accept connections from Tor exit relays. Some sites block all Tor exits, while others block only those that appear on various blacklists. A simple solution is routing a VPN service through Tor. Tor can carry only TCP traffic, so one must use TCP mode for the VPN connection. But the resulting VPN tunnel carries both TCP and UDP traffic, increasing application compatibility and reducing the chance of leaks.

Preventing VPN Leaks

VPN connections are prone to (at least) two types of leaks. One type involves DNS servers. Normally, after a VPN client requests a connection, the server configures the tunnel, and pushes required information to the client. Included are changes in network routing, so all Internet traffic uses the VPN tunnel, and DNS servers to be queried for translating hostnames to IP addresses.

But if something goes wrong, the client machine may instead query DNS servers provided by the user’s ISP. And that may reveal the ISP’s identity to those observing the VPN exit server. It may also reveal to the ISP what domains are being accessed. If the user’s ISP can see both user traffic to the VPN entry server and queries to its DNS servers, timing analysis could readily reveal what domains the user is accessing. In other words, the VPN would be compromised for that user.

Preventing such DNS leaks may be nontrivial. It may require temporarily hard coding the VPN’s DNS servers in the client machine’s network configuration, and undoing that after the VPN connection is closed. That’s what the VPN client should be doing, by the way, but sometimes it doesn’t work, especially with uncommon operating systems that the VPN configuration doesn’t fully support.

The other type of leak involves traffic bypassing the VPN tunnel to reach the Internet directly. The operating system may not properly implement changes in network routing pushed by the VPN server to direct all Internet traffic through the VPN tunnel. Or the VPN connection may fail in some way. For example, VPN servers may go offline, or VPN client software may hang or die, perhaps after intermittent network outages. Whatever the cause, it’s crucial that there be no Internet connectivity except through the VPN tunnel, even if the VPN connection is improperly configured, or fails in any way.

Unfortunately, OpenVPN was designed to provide secure connectivity to remote networks, but not Internet anonymity. Indeed, Internet traffic exits locally by default in OpenVPN, in order to conserve VPN bandwidth. While it’s easy to configure VPN tunnels to carry all network traffic, it’s difficult to prevent traffic from using the client machine’s physical adapter after the VPN client software terminates. By default, all changes to network routing made during VPN connection are reversed when the VPN disconnects. That’s generally a good thing, because users might otherwise be left without Internet access (even to reconnect the VPN).

Some VPN providers use proprietary clients that reportedly fail closed. But generally, the only reliable protections are network routing and firewall rules that restrict network connectivity to the VPN tunnel. In Windows and OS X, you can use, respectively, Comodo and PF. In Linux, you can use VPN-Firewall. It’s a bash script that creates iptables rules which block all Internet connections except through the designated OpenVPN server, and yet permit transparent VPN reconnection. It’s part of the high-privacy option in the next tutorial, Part 4. Setting Up Secure Host Machines. Whatever method you use, it’s prudent to test for leaks. That’s also covered in the next tutorial.

Using pfSense VMs as VPN Clients

Advanced networking expertise is required to securely route one VPN tunnel through another, with no leaks, on an individual machine. However, doing that is trivial by networking virtual machines (VMs) that serve as gateway routers. Indeed, it’s possible to create arbitrarily complex nested and branched chains of VPNs (and Tor).

pfSense, a hardened router/firewall operating system based on FreeBSD and its stateful packet filter PF, is an excellent choice for VPN-client VMs. pfSense VMs are small and resource-light. Creating VPN connections and preventing leaks is very easy in pfSense. The pfSense WebGUI is highly intuitive, and yet exposes virtually all pfSense capabilities. Using pfSense VMs as VPN clients is covered in Part 6. Creating pfSense VMs as VPN Clients.

Visualizing Nested VPN Tunnels

Chains of nested VPN tunnels provide better privacy and anonymity for accessing content servers, Tor entry relays, peers of P2P networks (such as BitTorrent, Freenet and I2P) and other remote servers. With no VPN, remote servers see your ISP-assigned IP address. Also, your ISP and other local observers see the IP addresses of remote servers. And unless connections are end-to-end encrypted, they can eavesdrop and carry out man-in-the-middle (MITM) attacks.

Connection with no VPN

With one VPN, remote content servers instead see the VPN’s exit IP address. Your ISP and other local observers see the VPN’s entry IP address, and the VPN tunnel is encrypted. However, the VPN provider knows both your ISP-assigned IP address and the IP addresses of remote servers.

Connection with One VPN

With two nested VPNs, remote content servers see the second (inner) VPN’s exit IP address. Your ISP and other local observers see the first (outer) VPN’s entry IP address. Both VPN tunnels are encrypted. Neither VPN provider knows both your ISP-assigned IP address and the IP addresses of remote servers. The first (outer) VPN provider knows your ISP-assigned IP address, and also the second (inner) VPN’s entry IP address. The second (inner) VPN provider knows the IP addresses of remote content servers, and also the first (outer) VPN’s exit IP address.

Connection with Two VPNs

With three or more nested VPNs, information about your Internet activity would be further fragmented, and harder to compromise. However, as VPN tunnels are nested more deeply, two factors limit usability. First, each VPN level adds 50-100 ms latency, and may also restrict bandwidth. Second, overall reliability (being the product of the individual VPN reliabilities) is lower.

Planning Initial Setup

You might want to start by creating a setup such as this.

Cloud showing Chained VPNs and TOR

Each star denotes a VPN exit, with an invariant IP address that’s shared by all users. Two VPN services (VPN1 and VPN2) form the backbone. A third VPN service, routed through VPN2, provides multiple simultaneous exits (VPN3a and VPN3b). A Tor client, also routed through VPN2, provides Internet access through a cloud of frequently changing exit IP addresses that are shared by many other users. Finally, a fourth VPN service (VPN4) is routed through the Tor connection.

Each VPN tunnel in a nested chain provides some degree of separation and anonymity. How much depends on such factors as the number of concurrent users, what the service logs, and the availability of any logs to adversaries. But generally, your risk of association is greatest with the VPN1 exit, less with the VPN2 exit, and even less with the VPN3a and VPN3b exits. Tor connections arguably provide far more separation and anonymity, so your risk of association through the Tor exit cloud is far less than through the VPN3 exits.

Routing VPN4 through the Tor connection, however, weakens anonymity. That’s obviously so if there are email or money trails from you to VPN4. But even free VPN services, with no such linkages, weaken Tor anonymity. Tor clients plan and test numerous circuits, with diverse paths and exit relays. They normally use multiple concurrent circuits to isolate application data streams, and they change circuits frequently. But once a VPN tunnel is established using a particular circuit, the Tor client can’t move it to a new circuit, until the VPN disconnects and reconnects. Even so, the VPN4 exit is still potentially far less associated with the VPN2 exit than the VPN2 exit is with you.

Everyone using a given VPN exit server has the same IP address. That’s good, because crowding increases anonymity. However, using a particular VPN exit for multiple pseudonyms is somewhat counterproductive, given the shared IP address. It’s best, therefore, to use just one primary pseudonym with each pfSense VPN-client VM, and its corresponding VPN exit and position in the overall nested VPN chain.

It’s also best for each pseudonym to consistently use a particular VPN exit. Changes in IP address can trigger account-verification requirements by some providers, such as Facebook and Google, and may even lead to blacklisting. That’s hard to avoid with Tor, because clients use multiple concurrent circuits (including exit relays) to isolate application data streams, and they change circuits frequently. VPNs can be routed through Tor, but that decreases anonymity.

In creating and using these setups, it’s crucial to keep in mind that associations among you and the various elements – exit IP addresses, and the pseudonyms and workstations that use them – can never be decreased, but only increased. For example, consider VPN4 that’s been routed through Tor. If you use that connection with a pseudonym or workstation that’s more closely associated with you, it’s prudent to assume that the association persists. Or consider a pseudonym created using VPN4. Using that pseudonym without Tor, even through nested VPNs, permanently associates it more closely with you.

Multiple pseudonyms should never share a workstation VM, given the risk of cross-correlation through routine tracking, malware and active attacks. It’s also prudent to compartmentalize information for a given pseudonym among multiple workstation VMs. One workstation VM might serve for routine online activity. Using a diskless LiveCD VM would provide some protection for visiting questionable websites or opening questionable files (but not as much as a diskless machine booting from a LiveCD). Another workstation VM might host a Bitcoin client, and hold other financial information. Highly sensitive information might be secured in one or more VMs that are routinely offline, and never share LANs with potentially compromised VMs.

In particular, a workstation should not contain information about the VPN account that it’s connecting through. The identity of the VPN service is obvious. Remote servers see VPN exit IP addresses, and may even reveal them in forum posts or email headers. However, account details such as email address and payment method may reveal true identity (or, at least, a weaker pseudonym). Although information about VPN service(s) purchased for extending the nested VPN chain is less sensitive, it’s prudent to segregate it (with other financial information) from routine online activity.

That’s a problematic issue, because configuration and management of pfSense VMs require workstation VMs for accessing the pfSense webGUI. For VPN-client setup, workstation VMs must have VPN credentials, which may be linked to email address and payment method. To reduce the risk of compromise and cross-correlation, it’s best to administer each pfSense VPN-client VM with a dedicated workstation VM, which contains no information about any pseudonyms that connect through that pfSense VM. Alternatively, you can use a diskless LiveCD VM for administering all of your pfSense VMs, and download VPN configuration files when needed.

Part 4 – Setting Up Secure Host Machines

By mirimir (gpg key 0x17C2E43E)

Introduction

This guide explains how to set up full-disk encrypted host machines for securely running multiple VMs. Using hardened router/firewall VMs (such as pfSense) as VPN clients, it’s easy to route one VPN tunnel through another. With multiple workstation VMs, we can maintain multiple pseudonyms that complicate profiling and tracking, and we can mitigate the impact of malware and hacking. We can easily route Tor through VPNs to avoid attracting unwanted attention. And we can easily route VPNs through Tor to evade Tor exit blocking, increase application compatibility, and reduce the chance of leaks.

As discussed in Part 3. Planning Advanced VM and VPN Setup, it’s prudent to read these guides, and download required software, through a VPN service and/or TOR. That way, your ISP and other local observers can’t see what you’re doing. Furthermore, consistently using a particular VPN service arguably attracts less attention than switching among several. If you haven’t yet chosen a direct-connect VPN service, now is a good time. Please see “Initial Privacy Considerations” in Part 3 for more on this recommendation.

Depending on your risk model, it may also be prudent to restrict your new host machine’s Internet traffic to the direct-connect VPN service, even while you’re setting it up. Using this high-privacy option would prevent your ISP and other local observers from seeing software downloads and other Internet connections that occur during installation of the operating system.

As an example, this guide includes a high-privacy option using Ubuntu as the host operating system. With this option, the new host machine would have no Internet connectivity during Ubuntu installation. Before providing Internet connectivity, you would install your direct-connect VPN service, and then configure iptables to block all non-VPN connections. After providing Internet connectivity, you would establish the VPN connection, and update the system.

With this approach, your ISP and other local observers would see only downloading (albeit increased, perhaps) through your direct-connect VPN service. Because the iptables rules take effect before network configuration during bootup, the new host machine will only have direct non-VPN Internet connectivity if you disable the iptables rules. Unless you did that, your ISP and other local observers would see no specific evidence of the new host machine’s existence.

Hardware

Gaming-class machines or workstations are best for simultaneously running more than a few VMs. Servers are good too, but normally lack audio and high-resolution video. If you’ll be maxing out RAM and hard disks, you may need to upgrade the power supply to at least 600 W.

Midrange quad-core CPUs (such as Intel i5 Quad, Intel Core 2 Quad and AMD Athlon Quad) can simultaneously run at least ten VMs, each configured with one core. CPU cores are only a soft limit for VM capacity, and overloading the CPU(s) just slows everything down. The CPU(s) must support virtualization. It’s typically disabled by default, and must be enabled in the BIOS.

Memory, on the other hand, is a hard limit for VM capacity. VMs can crash without warning if host memory becomes over-committed. However, RAM is currently quite inexpensive, and it’s best to install as much as you can. That’s especially important if you plan to run Windows VMs, which require substantially more memory than Linux or BSD VMs. With a 64-bit host OS, by the way, there’s no 4 GB memory limit.

You also want fast storage, because multiple VMs will be competing for disk access. It’s tempting to use solid state drives (SSDs), given their breathtaking speed, increasing capacity and declining cost. However, it may be problematic to secure SDDs, because their wear-leveling mechanisms may compromise full-disk encryption by leaving plaintext data in the clear after shutdown. While some SDDs may be securable, if you implement full-disk encryption at first use, thorough research and testing would be prudent.

The safest option is still probably RAID with multiple SATA (or SAS, if your budget allows) hard disk drives (HDDs). If you have a SATA optical drive, you can remove it to free up a SATA port, and use an external USB optical drive when needed.

It’s best to avoid consumer HDDs because they do extended error recovery (which doesn’t play well with RAID) and also because they’re not designed to be hammered. Older RAID-ready enterprise 7.2 Krpm SATA HDDs (such as Western Digital RE3s and RE4s) don’t cost much more than consumer HDDs, and they perform well.

If you only have four free SATA ports, RAID10 with four HDDs is the best option. RAID10 with four 1 TB 7.2 Krpm WD RE3 HDDs provides 2 TB capacity. You’d see ~170 MBps disk bandwidth with seek time ~12 ms, and you could lose one disk (or perhaps two, if you’re lucky) without data loss. The use of RAID5 is no longer recommended, by the way.

If you have five free SATA ports, RAID6 with five 1 TB 7.2 Krpm WD RE3 HDDs provides 3 TB capacity. You’d see ~270 MBps disk bandwidth with seek time ~7 ms, and you could lose any two disks without immediate data loss. However, RAID6 arrays rebuild slowly after failed disks have been replaced, and read errors can hose rebuilds.

Using five HDDs for RAID10 with one hot spare would provide less capacity (2 TB) and less speed (~170 MBps with seek time ~12 ms) but substantially better reliability. Although you could lose only one disk (or perhaps two, if you’re lucky) without data loss, RAID10 arrays rebuild far faster than RAID6 arrays do. Once the array had finished rebuilding, you’d have RAID10 with no hot spares. At that point, you could lose another disk (or perhaps two, if you’re lucky) without data loss.

You may want to enable booting with degraded RAID. If you don’t, and one of the disks fails, you might need to boot with a LiveCD and repair the damage before the machine will boot. If you just boot with degraded RAID, on the other hand, you may not realize that the RAID array is degraded until it entirely fails (which is too late). It’s prudent to periodically check HDD SMART and RAID status in Disk Utility.

Effective cooling is essential, especially for RAID with multiple HDDs. With consumer-grade hardware, adding a high-capacity rear case fan is wise. Some models provide little ventilation for drives, and are notorious for baking HDDs. It may be necessary to drill an array of small holes in the case, in front of the HDD cage, making sure not to leave metal fragments inside. You can also add a grill, if appearance matters.

Choosing an Operating System

Linux is the best choice for a secure and private host OS. It’s open-source and free, so there’s no money trail linking you to a product ID. Its software RAID implementation is fast, efficient and reliable. The LUKS package provides native full-disk encryption, with everything encrypted except for the boot partition. And finally, VirtualBox runs very well under it.

Unless carefully configured, all operating systems leave disk caches and logs behind. With Windows or OS X, which are closed-source, it’s very difficult to even know what’s being left behind. Knowledge of Windows shellbags, for example, was until recently largely restricted to the computer forensics community.

Ubuntu is a good choice for new Linux users. The Ubuntu Software Center simplifies package management. And the alternate install ISO provides full access to Debian’s disk partitioning tools, including LUKS full-disk encryption, and LVM for flexible partition management. It’s best to use releases with long-term support (currently 12.04). For those who dislike the Unity desktop, Xubuntu (based on Ubuntu) is the best alternative. Mint (also based on Ubuntu) doesn’t provide an alternate install ISO. Debian is probably the most secure option, and Debian 7.0 was just released. As noted above, there is no 4GB memory limit with a 64-bit OS, so use that if your hardware supports it.

Although the high-privacy option (explained below) is written for Ubuntu 12.04.2, it should work for any Linux distribution, if suitably tweaked. In principle, an analogous approach should work for Windows and OS X, but avoiding compromise through required authentication would be problematic.

VM Security Issues

To protect VM privacy, and limit access to log files and disk-cache residue, it’s prudent to use dedicated host machines with full-disk encryption. However, encrypted disks are decrypted while in use, and keys are stored in memory, so it’s prudent to shut down hosts when idle. Using full-disk encryption for individual VMs would limit access to idle VMs while other VMs are in use, but it won’t prevent access to information that’s been logged or cached on the host machine.

Under most circumstances, it’s safe to assume that VMs are isolated from each other, unless they have direct network connectivity or share disks (including USB and other removable drives) or clipboard. However, the possibility of malware breakout from VM to host can’t be excluded. If that occurred, other VMs would be readily compromised. Other machines with direct network connectivity or shared disks would also be compromised. When isolation is crucial or malware risk is high, it’s prudent to segregate VMs on different host machines, and to avoid direct network connectivity and disk sharing.

Plausible Deniability

Although encrypted data appears random, files, partitions and disks containing random data may engender suspicion, especially when there’s evidence that they’re in use. Also, there may be header information that flags the data as encrypted. In particular, the Linux Unified Key Setup (LUKS) for dm-crypt writes headers that begin with “LUKS”, and that disclose such information as the type of encryption being used.

Conversely, a well-known feature of TrueCrypt is the ability to write hidden partitions, and even to run hidden operating systems. If challenged, one can disclose the passphrase for the decoy partition. Adversaries can mount the decoy partition, and run a decoy OS that’s installed on it, but they can’t detect any hidden partition or OS that may exist. And so it’s arguably plausible to deny that any hidden partition exists.

However, merely having decoy partitions doesn’t make them plausible, unless they contain plausible information, and are used daily. If an adversary knows that you were online yesterday, based on information from your ISP, but your hidden OS hasn’t been used for a week, it seems odd. Also, even if you have disclosed the passphrase for a hidden TrueCrypt partition, or even if you use TrueCrypt without hidden partitions, an adversary may not believe you.

This tutorial uses Linux with LUKS and dm-crypt full-disk encryption. That may be unworkable if your circumstances require plausible deniability. Future tutorials will cover strategies for plausible deniability.

Installing Ubuntu with RAID, LUKS Encryption and LVM

First download the Ubuntu 12.04.2 alternate (64-bit) installer image, using the BitTorrent link or the nearest mirror. Use another machine that’s protected by a VPN service and/or Tor for all of these downloads. If you don’t have them already, download the credentials for your direct-connect VPN service. Also download adrelanos’ “VPN-Firewall” scripts.

If you’ll be going with the high-privacy option, you’ll also need the package files required for setting up Network Manager with OpenVPN. Get them through a VPN service and/or Tor. The installer would normally download them from the Ubuntu repository, but that won’t be possible without Internet connectivity. There are seven files to get:

Those are the package files needed to set up Network Manager with OpenVPN in a fresh Ubuntu 12.04.2 64-bit installation. You could get them from a non-US archive, if you like. It’s possible that this hack won’t work with an updated Ubuntu bug-fix release (e.g., 12.04.3). In that case, error messages from the package installer (which you’ll use near the end of this tutorial) will tell you what’s wrong.

Connect the machine to your LAN router. Otherwise, networking won’t get set up properly. If you’re going with the high-privacy option, just disable Internet connectivity to your LAN. After finishing the installation, you’ll install VPN-Firewall and your direct-connect VPN client, restore Internet connectivity, and establish the VPN connection. Then you’ll download and install updates, reboot and proceed to the next tutorial for VirtualBox setup.

If you’re not going with the high-privacy option, just proceed with normal Internet connectivity via LAN. And don’t bother downloading the package files for Network Manager with OpenVPN.

Installing Ubuntu (or Xubuntu or Debian) is quite easy, even using the old-school Debian wizard on the alternate install ISO. Create an install CD, and then boot your host machine with it. You can also use a USB flash drive, if your machine will boot from it.

Just use defaults until you reach the hostname screen. Although hostname isn’t visible beyond LAN, that will change with IPv6, so it may be prudent to go with the default “ubuntu” (or “xubuntu” or “debian”). Just hit enter after typing the hostname.

The most anonymous username is probably “User”, and it’s probably counterproductive to use something cute like “Anne O. Nymous”. A strong password is always prudent, but it matters less here because full-disk encryption is the primary defense. Don’t encrypt your home directory, because that can conflict with full-disk encryption.

On the clock screen, select No and set the time zone to UTC (the last choice). The host machine will generally be accessing the Internet directly, so there’s no point in picking a non-local time zone. However, picking UTC is not uncommon, and it might prevent information leaks.

On the disk partitioning screen, select Manual and hit enter. While the following may seem complicated, it’s really not. Also, the installer remembers your preferences, so repeating steps on multiple partitions goes quickly. Read it through a few times, so you have a general idea of what you’re doing, and are not just following the steps. Basically, you’ll be creating two partitions on each disk: 1) a small one for the boot RAID array; and, 2) a large one for the RAID array that will be encrypted using dm-crypt with LUKS, and then split into logical volumes (swap, root and home) using the Logical Volume Manager (LVM).

Start with the boot-array partitions. We put them at the beginning of each disk, furthest out where access is faster. Here are the steps for each of the physical disks:

  1. highlight disk, hit enter, select Yes and hit enter to create partition table
  2. highlight FREE SPACE line under disk and hit enter
  3. highlight Create a new partition (default) and hit enter
  4. you want 300 MB total boot space, so use these partition sizes:
    • 300MB for RAID1 with two disks
    • 150MB for RAID10 with four disks
    • 100MB for RAID5 with four disks
    • 100MB for RAID6 with five disks
  5. hit enter after typing desired partition size
  6. select Primary as partition type (default) and hit enter
  7. select Beginning as location (default) and hit enter
  8. select Use as line, hit enter, select physical volume for RAID and hit enter
  9. highlight Bootable flag and hit enter to set on
  10. highlight Done setting up the partition and hit enter

Repeat the above steps for each of the other physical disks.

Now create a second partition on each physical disk, using the remaining space. We will use them for a RAID array that will hold everything else except boot. Here are the steps for each disk:

  1. highlight FREE SPACE line under disk and hit enter
  2. highlight Create a new partition (default) and hit enter
  3. accept default size (because you’re using all remaining free space) and hit enter
  4. select Logical as partition type (default) and hit enter
  5. select Use as line, hit enter, select physical volume for RAID and hit enter
  6. highlight Done setting up the partition and hit enter

Repeat the above steps for each of the other physical disks.

You should be back at the main disk partitioning screen. Configuring software RAID is next. Here are the steps for the boot RAID array:

  1. select Configure software RAID and hit enter
  2. select Yes to Write changes to the storage devices and configure RAID and hit enter
  3. select Create MD device (default) and hit enter (this will be md0, by the way)
  4. select desired RAID type and hit enter
  5. enter number of active devices (total disks, less any hot spares that you decide to use) and hit enter
  6. enter number of hot spares (typically zero unless you have five HDDs, and are going with RAID10) and hit enter
  7. check (using space bar) which partitions to use (the small ones, sda1 etc)
  8. hit enter to get back to the RAID configuration screen

Now repeat that process to create md1 from the set of large partitions (sda5 etc). We will encrypt that using dm-crypt with LUKS, and then use it for LVM.

Select Finish and hit enter to get back to the main disk partitioning screen.

At this point, you should see two RAID devices on the main disk partitioning screen: “RAID… device #0″ (aka md0) being the boot array, and “RAID… device #1″ (aka md1) being the array for encryption and LVM. Let’s do RAID device md1 first.

  1. select #1 line below main “RAID… device #1″ partition line, and hit enter
  2. select Use as line, hit enter, choose use as physical volume for encryption, and hit enter
  3. select Done setting up the partition and hit enter
  4. you should be back at main disk partitioning screen
  5. select Configure encrypted volumes and hit enter
  6. select Yes to Keep current partition layout and configure encrypted volumes and hit enter
  7. select Create encrypted volumes and hit enter
  8. check /dev/md1 (using space bar) and hit enter
  9. select Finish and hit enter

Now you’ll be asked for your passphrase. Use a complex one, at least 25 characters long with lowercase and uppercase letters, numbers and other printable characters. Record it in a private and secure place, because there is truly no way to recover it if it’s lost.

You should be back at the main disk partitioning screen, and should now see the encrypted volume md1_crypt at the top of the list. Now we configure logical volumes in that partition, as follows:

  1. select #1 line below main md1_crypt partition line, and hit enter
  2. select Use as line, hit enter, choose use as physical volume for LVM, and hit enter
  3. select Done setting up the partition and hit enter
  4. you should be back at main disk partitioning screen
  5. select Configure the Logical Volume Manager and hit enter
  6. select Yes to Keep current partition layout and configure LVM, and hit enter
  7. select Create volume group and hit enter
  8. name it (e.g., cryptovg) and hit enter
  9. check /dev/mapper/md1_crypt (using space bar) and hit enter

Now you create your logical volumes. Although you can get fancy, swap, root (“/”) and home are enough. We do swap first to put it at the beginning of the logical volume, further out on the disk where access is faster. The steps for swap are:

  1. select Create logical volume and hit enter
  2. hit enter to accept default volume group cryptovg
  3. name it swap and hit enter
  4. set size as twice your installed memory and hit enter

The steps for root are:

  1. select Create logical volume and hit enter
  2. hit enter to accept default volume group cryptovg
  3. name it root and hit enter
  4. set size as 20 GB and hit enter

The steps for home are:

  1. select Create logical volume and hit enter
  2. hit enter to accept default volume group cryptovg
  3. name it home and hit enter
  4. accept default size (remaining space) and hit enter
  5. select Finish and hit enter
  6. you should be back at main disk partitioning screen

Now you finish configuring your home volume, as follows:

  1. select #1 line below main home partition line, and hit enter
  2. select Use as line, hit enter, choose use as Ext4 journaling file system, and hit enter
  3. select Mount point line, hit enter, choose /home and hit enter
  4. select Done setting up the partition and hit enter

Now you finish configuring your root (aka /) volume, as follows:

  1. select #1 line below main ‘root” partition line, and hit enter
  2. select Use as line, hit enter, choose use as Ext4 journaling file system, and hit enter
  3. select Mount point line, hit enter, choose / and hit enter
  4. select Done setting up the partition and hit enter

Now you finish configuring your swap volume, as follows:

  1. select #1 line below main swap partition line, and hit enter
  2. select Use as line, hit enter, choose use as swap area, and hit enter
  3. select Done setting up the partition and hit enter

Then, page down the main disk partitioning screen to your boot RAID array (“RAID… device #0″ aka md0), and finish configuring it:

  1. select #1 line below main “RAID… device #0″ partition line, and hit enter
  2. select Use as line, hit enter, choose use as Ext4 journaling file system, and hit enter
  3. select Mount point line, hit enter, choose /boot and hit enter
  4. select Done setting up the partition

Finally, go to the bottom of the main disk partitioning screen, select Finish partitioning and write changes to disk, and hit enter. After rechecking the partition configuration, select Yes to write changes to the disks, and hit enter.

The rest of the install process should complete with little input. If you need an HTTP proxy, you’ll probably know what it is. You do want to install the GRUB bootloader, unless you’re doing a dual-boot system (and know what you’re doing). The system clock is set for UTC.

Now remove the installation CD, and let the machine reboot.

Setting Up Network Manager with OpenVPN

It’s convenient to configure your direct-connect VPN on the host machine before installing drivers and updates, and setting up VirtualBox. If you’ve chosen the high-privacy option, doing that is essential, and it’s somewhat more complicated. In that case, your new host machine (and its LAN) shouldn’t have Internet connectivity now .

First you’ll need to set up Network Manager with OpenVPN. If you have not chosen the high-privacy option, just open a Terminal window, and run these commands:

user@ubuntu:~$ sudo apt-get install network-manager-openvpn
user@ubuntu:~$ sudo restart network-manager

That’s all.

If you have chosen the high-privacy option, open a Terminal window, and run these commands:

user@ubuntu:~$ cd /home/user
user@ubuntu:~$ mkdir nmo

Then copy the seven Network Manager and OpenVPN package files (which you’ve downloaded previously via a VPN service or Tor) to /home/user/nmo/ using your preferred method. Then run these commands in a Terminal window:

user@ubuntu:~$ sudo dpkg -R -i /home/user/nmo
user@ubuntu:~$ sudo apt-get install -f
user@ubuntu:~$ sudo restart network-manager

The first command installs the packages, and the second command corrects errors caused by not installing them in the proper sequence. If the second and third commands complete without errors, you’re good to go.

If the second command fails, the errors should tell you what package files are missing. Just get them through a private channel, add them to /home/user/nmo/ and rerun the previous three commands.

Installing Direct-Connect VPN

First review your VPN credentials – certificates (.crt) and keys (.key) – and configuration files (*.conf or *.ovpn). Some VPN services provide configuration files with embedded credentials, with each of the credentials bracketed by corresponding [name] and [/name] tags. In that case, copy each of the credentials, and save as an appropriately-named text file. There may be as many as four credentials:

  • ca.crt
  • client.crt
  • client.key
  • ta.key

All of these files should be downloaded via HTTPS, and kept private. You might want to avoid providers that don’t use HTTPS for this. Establishing a VPN connection may also require a username and password, which may differ from the account name and password for the VPN service’s website. Some low-end services email connection username and password. In that case, immediately go to the provider’s website, and change the password.

Virtually all VPN services provide a ca.crt (certificate authority) certificate. These certificates enable clients to verify the authenticity of VPN servers before connecting. Most VPN services also provide a client.crt (client certificate) and client.key (for unlocking and using the client certificate). Client certificates allow VPN servers to verify the authenticity of clients before accepting connections. A few high-end VPN services also provide a ta.key to enable TLS authentication, whichincreases connection security.

You’ll also need other information from the OpenVPN configuration file. First, you’ll need to choose the VPN server that you’ll be connecting to. Avoid the United States, United Kingdom and France. Germany and the Netherlands are OK. It’s probably good to avoid Eastern Europe, Russia, China etc, which might attract attention. You’ll need the IP address of the server, rather than the hostname, in order for VPN-Firewall (see below) to work properly. If you just have hostnames, you can get the IP address by running this command:

user@ubuntu:~$ host hostname.that.you.have

Second, you’ll need to know the server port number and connection type (UDP or TCP). It’s generally best to use UDP (unless you’re routing via Tor). You’ll also need to know the cipher type (from the cipher … line) and whether LZO compression should be enabled (if you see comp-lzo). If cipher type isn’t specified, use the Network Manager default. For VPNs that provide ta.key, you’ll need to know the key direction, which is the number at the end of the tls-auth line (typically 1).

Start the setup by copying all of the VPN credential files to /etc/openvpn. Open a Terminal window, and run these commands:

user@ubuntu:~$ cd /home/user/path-to-the-files
user@ubuntu:~$ sudo cp ca.crt client.crt client.key ta.key /etc/openvpn/

Of course, edit the second command for the files that you actually have.

Then open Network Manager, select the VPN tab, and click the Add button. Select OpenVPN as type, and click the Createbutton. Enter a short name for the connection, and the IP address of the server that you’ll be accessing. The next steps depend on the configuration of the VPN service.

There are three common VPN-configuration setups. Some VPN services (such as Private Internet Access) provide only ca.key, and require username and password for connection. For them, select Password as authentication type, enter your username and password, and click the CA Certificate button. In the Places window, click File System. Double click etc, and then double click openvpn. Finally, select ca.crt and click Open.

Now click the Advanced button”. In the General tab, check Use custom gateway port and enter the appropriate port number. If appropriate, check Use LZO data compression (typical) and Use a TCP connection (rarely appropriate unless you’re routing via Tor). If you know the cipher type, click Cipher in the Security tab, select the appropriate one, and clickOK. Now click Save in the VPN window, and close Network Manager.

Some VPN services (such as AirVPN) provide ca.key, client.crt and client.key, but not ta.key, and don’t require username and password for connection. For them, select Certificates (TLS) as authentication type, and then specify User Certificate(client.crt), CA Certificate (ca.crt) and Private Key (client.key) as described above. Then complete the same steps in theAdvanced window as described above, save the VPN configuration, and close Network Manager.

Some VPN services (such as IVPN) provide ca.key, client.crt, client.key and ta.key, and also require username and password for connection. For them, select Password with Certificates (TLS) as authentication type, and enter your username and password. Then specify User Certificate (client.crt), CA Certificate (ca.crt) and Private Key (client.key) as described above. Complete the same steps in the Advanced window as described above. In the TLS Authentication window, check Use additional TLS authentication, and specify Key File (ta.key) and Key Direction (typically 1). Then save the VPN configuration, and close Network Manager.

Installing and Checking VPN-Firewall

Install adrelanos’ VPN-Firewall scripts as described at https://github.com/adrelanos/VPN-Firewall. You want the firewall (iptables rules) to load at bootup, so install both the firewall and init scripts. Reboot the machine, and check VPN-Firewall status by running sudo service vpnfirewall status in a Terminal window. It should reply 0.

If you’ve chosen the high-privacy option, now restore Internet connectivity to your new VM host. Then verify that your new machine has no Internet connectivity by trying to visit https://duckduckgo.com/. If it connects, there’s something wrong with the VPN-Firewall setup.

Now use Network Manager to establish your direct-connect VPN connection, and verify that it works by visitinghttp://whatismyipaddress.com. If it doesn’t connect, recheck the configuration. If it does connect, test VPN-Firewall by killing the openvpn process (run sudo killall openvpn in a Terminal window) and verifying that the machine has no Internet connectivity. Then use Network Manager to reestablish the VPN connection, and verify that it works again by visiting http://whatismyipaddress.com.

Check your DNS servers by running the standard DNS leak test at https://www.grc.com/dns/. It should report only the DNS servers that your direct-connect VPN service specified. And it should not report any DNS servers associated with your ISP, or specified by your LAN router. If it does, there’s something wrong with the VPN setup.

You can also check for leaks using Wireshark. To install Wireshark, open a Terminal window, and run these commands:

user@ubuntu:~$ sudo apt-get update
user@ubuntu:~$ sudo apt-get install wireshark

Then configure wireshark to allow a non-root user to sniff packets. As described here, just run these commands in a Terminal window:

user@ubuntu:~$ sudo dpkg-reconfigure wireshark-common
user@ubuntu:~$ sudo adduser $USER wireshark

Reboot the machine, and establish your direct-connect VPN connection. Then open Wireshark, and start capturing on eth0. Use Firefox to check http://whatismyipaddress.com, run the DNS test at https://www.grc.com/dns/, etc. Now stop the capture, and run Statistics/Endpoints. You should only see only local non-public IPs and the VPN server that you’re connected to.

Now kill the openvpn process (run sudo killall openvpn in a Terminal window) and start a fresh capture on eth0. Verify that Firefox can’t see anything. The iptables setup blocks pings, by the way. Stop the capture after about 10 minutes, and run Statistics/Endpoints. You should only see traffic with local non-public IPs, and reconnection attempts from the VPN server that you were connected to.

Finally, reestablish your direct-connect VPN connection, and verify that it’s working again.

Viewing Network Manager OpenVPN Logs

If there are problems with the OpenVPN connection, it may help to have debugging information from Network Manager. Getting that takes a little work, however. First, you must edit its configuration file to maximize logging. Run the following command in a terminal window:

user@ubuntu:~$ sudo nano /etc/NetworkManager/NetworkManager.conf

Add these two lines at the end of the file, after a blank line:

[logging]
level=DEBUG

Save the altered file by typing Ctrl-O, and exit nano by typing Ctrl-X. Then restart Network Manager by running the following command in a terminal window:

user@ubuntu:~$ sudo service network-manager restart

Finally, connect the VPN using the Network Manager icon in the top panel bar. Wait until it either connects, or gives up. In order to see the openvpn connection log, run the following command in a terminal window:

user@ubuntu:~$ grep nm-openvpn /var/log/syslog

Completing the Installation

You’re almost done. If desired, activate proprietary drivers and reboot. Then start Update Manager, download and install updates, and let the machine reboot.

Your VM host machine will have no Internet connectivity whenever it boots, given that VPN-Firewall is active and no VPN is running. That’s arguably the best default, because you must actively choose how to proceed.

Now you are done, and can proceed to the next guide,

Part 5 – Installing VirtualBox and Creating Linux VMs

By mirimir (gpg key 0x17C2E43E)

Introduction

This tutorial covers installing VirtualBox, and creating Linux (Ubuntu, Xubuntu or Debian) workstation and LiveCD VMs. Installing VirtualBox is trivial. Download the version of VirtualBox for your host machine OS fromhttps://www.virtualbox.org/wiki/Downloads. Then open the downloaded package with the Ubuntu Software Center, and install. For Debian hosts, use dpkg in a terminal. Finally, download the Extension Pack, and open it with VirtualBox to install. That’s it. With VirtualBox running, hitting F1 opens the user manual, which is excellent and comprehensive.

VirtualBox Networking Basics

By default, VM network adapters are attached to <span “NAT”. That is, they use the host machine’s active network gateway (wired, wireless, VPN, etc) with network address translation (NAT) and VirtualBox’s built-in DHCP server. Multiple VMs using VirtualBox NAT are isolated from each other. VM network adapters can also be attached to VirtualBox internal networks, and multiple VMs can communicate through shared internal networks. But there is no network connectivity with the host machine for VMs that are attached to either NAT or internal networks.

Router/firewall VMs (such as pfSense and OpenWRT) have at least two network adapters, WAN and LAN, and typically run a DHCP server on LAN. For example, you can attach the WAN adapter to the host via NAT, and the LAN adapter to an internal network. You can also use router/firewall VMs to establish connections with remote VPN servers or Tor through WAN, and route those connections to LAN. That’s the basis of the setup that we’re creating.

VM network adapters can be attached to the host machine in two other ways. First, through selecting “Bridged Adapter”, they can be bridged to the host’s physical network adapters. For example, VMs with WAN bridged to the host’s LAN adapter behave just like other machines on the host’s LAN, perhaps with IP addresses from the LAN router. Conversely, by bridging the LAN adapter of a router/firewall VM to another host network adapter, you can provide routed resources (such as a VPN or Tor tunnel) to other physical machines or networks.

Second, through selecting “Host-only Adapter”, VM network adapters can be bridged to virtual network adapters on the host. The two bridging modes work well together. In particular, it’s possible to route traffic from the host machine’s LAN (with “Bridged Adapter”) to a VM (or even a network of VMs) and then back to the host (with “Host-only Adapter”) through a virtual network adapter. For example, you could have the host machine access the Internet through an intrusion prevention system (IPS) and/or a nested chain of VPNs and Tor. Although that’s not part of this series of guides, it’s discussed here in some detail.

Creating Linux Workstation VM

Creating VMs is very easy, and section 1.7 of the VirtualBox manual (hit F1) explains it well. It’s a two-stage process. First, you configure the new VM in VirtualBox. Second, you start the VM, and install the OS, just as you would on a physical machine.

Linux is the best choice for a secure and private workstation VM. It’s open-source and free, so there’s no money trail linking you to a product ID. Ubuntu is a good choice for new Linux users. It’s best to use releases with long-term support (currently 12.04). For those who dislike the Unity desktop, Xubuntu and Mint (both based on Ubuntu) are good alternatives. Debian is arguably more secure, but not as user-friendly.

You can use the same 64-bit alternative installer image file (Ubuntu, Xubuntu or Debian) that you used for the host machine. Or you can download a 32-bit (aka i386) regular desktop installer image file for the Linux distro that you’ve chosen. In any case, you’ll need the standard desktop installer image file for creating LiveCD VMs (explained below).

First open VirtualBox, and click the New icon. Enter your desired VM name, and select the proper OS type (Linux) and version (Ubuntu for Ubuntu, Mint or Xubuntu) or Debian, choosing 32-bit or 64-bit as appropriate. Specify 1 GB memory to avoid disk swapping. If host RAM is limited, you can reduce it later. Use the defaults for virtual hard disk type (dynamically allocated VDI) and location, but specify at least 100-200 GB maximum size. The initial size of the virtual disk will be at most 5-6 GB. But with large maximum size, it’s very easy to accommodate unplanned growth. After reviewing the final summary screen, hit Create.

Next, tweak the new VM’s settings. In the General/Advanced tab, leave Shared Clipboard and Drag’n’Drop set toDisabled (for security). Under System/Motherboard, change the boot order to Hard Disk, CD/DVD, and deselect Enable absolute pointing device. Under System/Processor, select Enable PAE/NX (if your host supports it). Under Display/Video, increase video memory to 128 MB (unless host RAM is limited). Under USB settings, deselect Enable USB Controller (for security).

Now add the OS installer image. Under Storage, highlight the CD icon (named Empty) under IDE Controller. Then hit the CD icon to the far right of CD/DVD Drive, and select Choose a virtual CD/DVD disk file. Navigate to wherever you put your installer image, and select it. Then click OK to exit the settings screen.

Then double click on the new VM, and go through the install process. It’s OK to accept all defaults. But you can select the encrypted LVM option for disk partitioning , if you like. Although whole-disk encrypted VMs may leave plaintext on host machines, that’s better than nothing if the host is compromised while running. As the VM is rebooting after installation completes, click Devices in the main menu, highlight CD/DVD Devices, and select Remove disk from virtual drive.

To get better VM performance, you may want to install VirtualBox guest additions (customized kernel modules). Guest additions also provide better display and mouse integration, and enable mounting host folders (aka shared folders) in the VM. However, some of the kernel customizations may reduce guest-host isolation, and using shared folders definitely does. It’s a typical convenience vs security trade-off.

Ubuntu or Xubuntu will prompt you to install the guest-additions kernel-module package as additional drivers. If not, use the Settings menu. You can also install guest additions by clicking Devices in the VirtualBox menu, and then Install Guest Additions. But don’t do both. Debian 7.10 automatically installs the guest-additions kernel-module package.

Now reboot, use Update Manager to download and install updates, and let the system reboot again. You’re done.

Creating Diskless Linux LiveCD VM

Diskless LiveCD VMs are useful whenever isolation matters, because VM storage in ramdisk doesn’t survive rebooting (although traces may remain in host memory cache). Using them may be prudent for some online work, and they’re definitely useful for administering multiple pfSense VPN-client VMs. For example, you could download configuration files for a new VPN service through the appropriate nested VPN chain, and then configure and test the new pfSense VM. After rebooting the LiveCD VM, you could safely get configuration files for another new VPN service (even from a shared host folder) and then configure and test its new pfSense VM.

Although you might want a few diskless LiveCD VMs for convenience, you’ll still need less workstation VMs overall. Also, they don’t require updating, and upgrading them to a new release is simple. The LiveCD image is read-only, and loads to ramdisks during boot, so at least two or three VMs can typically share an image.

You must use a regular Ubuntu (or Xubuntu or Debian) desktop installer image, which works as a LiveCD. As described above, select the proper OS type and version, and specify 1 GB memory to avoid disk swapping. Then specify Do not add a virtual hard drive, and hit Create. Tweak the new VM’s settings as described above, except for the Storage tab.

Under Storage, delete the IDE controller and attached CD/DVD drive. Under the SATA controller, create two CD/DVD drives. For the SATA port 0 drive, add the installer image, and enable Live CD/DVD. For the SATA port 1 drive, add VBoxGuestAdditions.iso (located in /usr/share/virtualbox/). Then click OK to exit the settings screen.

Start the new VM, and choose the option to try without installing. That’s it.

Installing VirtualBox guest additions will improve performance, and is necessary for using shared host folders. But you’ll need to repeat the installation after each reboot, because the VM intentionally has no persistent storage. Once the VM has finished booting, open a terminal and run these commands:

ubuntu@ubuntu:~$ sudo mkdir /media/cdrom1
ubuntu@ubuntu:~$ sudo mount /dev/sr1 /media/cdrom1
ubuntu@ubuntu:~$ cd /media/cdrom1
ubuntu@ubuntu:~$ sudo ./VBoxLinuxAdditions.run

The installer will complain about missing headers for the running kernel, but will succeed anyway. Installation worked if the mouse pointer is no longer captured.

If you want a shared folder, start by creating a new folder on the host, for example /home/user/LiveCD. Then click Devicesin the top menu bar, and select Shared Folders. Click the + icon (upper right) and navigate to the host folder that you just created. Note the folder name, here LiveCD, and OK out.

Now open a terminal in the VM, and run these commands, replacing LiveCD with the name of your shared folder:

ubuntu@ubuntu:~$ sudo mkdir /home/ubuntu/host
ubuntu@ubuntu:~$ sudo mount -t vboxsf LiveCD /home/ubuntu/host

The VM folder /home/ubuntu/host is now linked to the host folder /home/user/LiveCD. The link (and its configuration) will be gone after rebooting. To unmount before rebooting, open a terminal in the VM and run this command:

ubuntu@ubuntu:~$ sudo umount /home/ubuntu/host

Part 6 – Creating pfSense® 2.1.5 VMs as VPN Clients

By mirimir (gpg key 0x17C2E43E)

Introduction

At this point, if you’ve followed Setting Up Secure Host Machines, your new VM host machine can only access the Internet through your chosen direct-connect VPN service. If you’ve followed Installing VirtualBox and Creating Linux VMs, you’ve created Linux workspace and LiveCD VMs. By default, their network adapters are NATed to the host machine, and they reach the Internet through your chosen direct-connect VPN service.

This tutorial covers creating pfSense® 2.1.5 (hereinafter “pfSense”) router/firewall VMs, configuring them as VPN clients, and testing for leaks using Wireshark. Your Linux workspace and LiveCD VMs will access the Internet through nested chains of these VPN gateway VMs and Tor gateway VMs, as discussed in Planning Advanced VM and VPN Setup. Using Tor gateway VMs is covered in Paying Anonymously with Cash and Bitcoins and Creating Nested Chains of VPNs and Tor.

If you want the host machine to routinely access the Internet directly, you can create a pfSense VM client for your chosen direct-connect VPN service. You can use that in your nested VPN chains, instead of the VPN client on the host machine, and connect via the VPN client on the host machine only when you want to hide software downloads or whatever. However, if you’ve chosen the high-privacy option, it’s crucial to continue using the host machine client for your direct-connect VPN.

Create New VPN Account

Your VM host machine is still using your direct-connect VPN service. The first pfSense VPN-client VM that you create can use either that VPN service, or another that will connect through it. It’s best to use a second VPN service for your first pfSense VM, in order to avoid leaks during the host-client to VM-client transition.

You’ll need an account with another VPN provider. It’s best to start with a free VPN service, because there’s no money trail. There are bandwidth and usage limits, however. Paying Anonymously with Cash and Bitcoins covers methods for anonymously buying VPN services.

Although SecurityKISS has a good free option, it does require an email address. But you can use free webmail accounts. The fastest (and perhaps most anonymous) option is AnonBox from the Chaos Computer Club. But accounts last at most one day, and are deleted after messages have been read. For persistent accounts, VFEmail is a good choice, because it only asks for a name.

It’s OK to use the host machine (running the direct-connect VPN) for this. For better isolation, you could dedicate a Linux VM (possibly full-disk encrypted) for this and other sensitive work on the host machine. Once you have a client ID and password from SecurityKISS, download the OpenVPN configuration files for Linux.

Creating & Configuring pfSense VM

Download “pfSense-LiveCD-2.1.5-RELEASE-amd64.iso.gz” from pfSense’s Coltex (Amsterdam, NL) mirror to the host machine (using the direct-connect VPN) and extract the installer image.

Create a pfSense VM, basically as described for Linux VMs in Installing VirtualBox and Creating Linux VMs.

  1. Select BSD as the OS, and FreeBSD (64 bit) as the version.
  2. Specify 512MB memory.
  3. Create a new hard disk using the defaults (VDI, dynamically allocated, 2GB) and finish.
  4. Then tweak the settings. Change the boot order to Hard Disk, CD/DVD and enable PAE/NX.
  5. Add the installer image to the virtual CD/DVD drive.
  6. Disable audio and USB support.
  7. Leave the default network adapter «Adapter 1» attached to NAT (host) and don’t change advanced settings. If this VM will connect through another pfSense VPN-gateway VM, however, attach this adapter to its internal network.
  8. Add a second network adapter «Adapter 2» and attach it to an internal network named, for example, pfS-SK (but don’t change advanced settings).
  9. Start the pfSense VM. In the console window, hit 1 to boot, and then hit i to start the installer.
  10. On the Configure Console screen, select Accept these Settings.
  11. On the Select Task screen, select Quick/Easy Install.
  12. Under Are you SURE?, select OK. Wait a while.
  13. On the Install Kernel(s) screen, select Standard kernel.
  14. On the Reboot screen, select Reboot.
  15. While it’s rebooting, using the Devices | CD/DVD Devices menu at the top, select Remove disk from virtual drive. To speed booting, you can hit F1 and then 1 in the console.
  16. Enter n to decline setting up vLANs.
  17. Type em0 as the WAN interface, and hit enter.
  18. Type em1 as the LAN interface, and hit enter.
  19. Hit enter to pass on OPT interface setup. Enter y to accept choices, and wait for pfSense to finish booting.

Edit the settings for the LiveCD VM, attaching the network adapter «Adapter 1» to the same internal network as the new pfSense VM (for example, pfS-SK). Then start the LiveCD VM, and download your OpenVPN configuration files for Linux from SecurityKISS. Don’t visit any other websites, to mitigate tracking risk. If necessary, you could also access your initial download (above) via shared folders, but that would require installing VirtualBox Guest Additions.

Freshly installed, pfSense routes all outbound connections (from computers on its LAN) through its WAN. But it blocks all new inbound connections from WAN, allowing only those that were established from LAN. If the LiveCD VM can’t see the Internet, recheck your host and the pfSense VM settings.

Configuring pfSense and Creating VPN Client

Now browse to the WebGUI at https://192.168.1.1 and create a server certificate exception. Login as admin with passwordpfsense, and complete the setup wizard. Decline the Gold support option, unless you have an anonymous credit/debit card. The next screen asks for DNS servers that pfSense should use internally, and whether to “[a]llow DNS servers to be overridden by DHCP/PPP on WAN”. I prefer to hard code DNS servers. Using DNS servers pushed by WAN can also be OK, but there are two risks. First, it may not work for some VPN combinations in nested VPN chains. Second, there is the risk that pfSense will end up using your ISP’s DNS servers (if they’ve been passed along to pfSense WAN). Even so, as long as you specify DNS servers in “Services: DHCP server”, the DNS servers that pfSense uses internally will not be pushed to DHCP clients (that is, your workspace VM, and other gateway VMs that connect through this one).

I recommend specifying reliable third-party DNS servers, such as those listed by WikiLeaks or JonDoNYM. If you’ve chosen the high-privacy option, you could specify DNS server(s) pushed by your direct-connect VPN service, or allow DNS servers to be overridden by DHCP on WAN. The key points are: 1) avoid using DNS servers pushed by your ISP; and 2) avoid using the same DNS servers at multiple levels of your VPN chain.

Accept the default timeserver and timezone, and hit Next. On the WAN screen, accept defaults, except for unchecking “Block private networks” and “Block bogon networks”, and hit Next. Accept all defaults on the LAN screen, and hit Next. Set a strong password on the next screen, and let pfSense reload. Now you’re at the pfSense WebGUI Dashboard. It’s best to reboot pfSense before proceeding. In the pfSense VM console window, reboot by entering 5 and then y to confirm.

You may find that the pfSense menu wraps “Help” under “System”, and prevents selecting submenu items for “System”. In that case, browse https://192.168.1.1/system.php, change “Theme” (at the bottom) to “pfsense-dropdown”, and save changes. Some of the other themes also work.

Before creating an iVPN client, tweak pfSense settings. In “System: General Setup”, check “Do not use the DNS Forwarder as a DNS server for the firewall”, and save. In “Services: DNS forwarder”, uncheck “Enable DNS forwarder”, and save. Those help prevent propagation of DNS server specifications through pfSense. In the webGUI in “System: Advanced: Networking”, uncheck “Allow IPv6″ and save. In “System: Advanced: Miscellaneous”, check “Skip rules when gateway is down”. That provides backup protection against leaks to WAN if the iVPN connection goes down. Now reboot pfSense again, from the console, by entering 5 and then y to confirm.

Although I have never seen outbound traffic use the WAN interface when a VPN is down, pfSense documentation does say this: “By default, when a rule has a specific gateway set and this gateway is down, a rule is created and traffic is sent to the default gateway. This option overrides that behavior and the rule is not created when gateway is down, so instead of flowing via the default gateway, the traffic will continue to attempt to use the gateway that is in a down state, and it will most likely not proceed. This is useful if you have traffic that should only ever use one specific WAN and never flow over any other WAN, regardless of how the firewall’s routing table has for the default route.”

For “normal” network setups, it’s important to specify good DNS servers, and to minimize the need for hard coding. In such cases, it’s best to allow system DNS servers to be overridden by DHCP/PPP on WAN, and to enable DNS forwarding. That allows DNS server specifications to transparently propagate through complex networks of pfSense routers. However, in nesting VPNs using pfSense VMs, it’s crucial to use different DNS servers at each level. Using the same DNS servers across levels would be a serious information leak.

Review the Setting Up VPN on Linux Workstation VM section of Basic Setup Using VMs, VPNs and Tor. Then, in the pfSense WebGUI Dashboard, go to System: Certificate Authority Manager. Add ca.crt in the CAs tab. If you haveclient.crt and client.key, add them in the Certificates tab.

For services (such as iVPN) that require username-password authentication, go to Diagnostics: Edit file. Browse to/usr/local/share/misc/, type your username and password in the text box (on separate lines) and save as user-pass. Now go to VPN: OpenVPN: Client and hit the + icon to create a client. The specifics depend on what the OpenVPN server supports, and what it expects from its clients. Use an OpenVPN configuration file (with extension .conf or .ovpn) from the service as a guide. In particular, note the server address and port, and the encryption algorithm. In chaining VPNs, it’s simpler to use IP addresses, rather than hostnames, although reliability may be lower (because you’ve broken failover for the VPN service).

For SecurityKISS, accept the defaults in VPN: OpenVPN: Client setup, except as noted:

Server host or address: 46.165.197.1 or 46.165.221.230 or 62.75.181.139 (Germany)
Server port: 123
Server host name resolution: enable (check) Infinitely resolve server
TLS Authentication: disable (uncheck) Enable authentication of TLS packets.
Client Certificate: client
Encryption algorithm: BF-CBC (128-bit)
Compression: enable (check) Compress tunnel packets using the LZO algorithm.
Advanced: remote-cert-tls server;verb 5

For services that don’t provide client.crt and client.key, use webConfigurator default.

Some services (such as IVPN) use TLS authentication. Under TLS Authentication, leave Enable authentication of TLS packets. checked, but disable (uncheck) Automatically generate a shared TLS authentication key. Then paste ta.key in the text box.

To automate username-password authentication for services (such as IVPN) that require it, enter the following in theAdvanced box:

ns-cert-type server;auth-user-pass /var/etc/openvpn/user-pass;verb 5

Save the client configuration, and check Status: OpenVPN. The status should be up. Then check Status: System logs: OpenVPN. You should see Initialization Sequence Completed near the bottom. A few lines above, you should see a line that starts (after the timestamp) with PUSH: Received control message …. If you don’t see redirect-gateway def1 in that line, edit the VPN: OpenVPN: Client setup, and add redirect-gateway def1; to the Advanced text box. If the VPN isn’t connecting, look for errors in Status: System logs: OpenVPN. You may need to tweak the Advanced string by adding other options from the service’s configuration file. If you see it complain about cipher mismatch, use the one it wants in your client configuration.

Once the VPN is connecting, check Status: System logs: OpenVPN again, find the PUSH: Received control message … line, and look for dhcp-option DNS server followed by an IP address. Then go to Services: DHCP server, and specify that IP address as DNS server. That works for most VPN services. But if it doesn’t, which you’ll discover soon, you’ll need to instead use third-party DNS servers, such as those from WikiLeaks or JonDoNYM. However, do not use any of the ones that you used above in the setup wizard (which appear in System: General Setup) because you don’t want to short-circuit VPN anonymity by using the same DNS server(s) for both entry and exit traffic.

At this point, pfSense is not routing anything through iVPN, and your LiveCD VM has no Internet connectivity. That’s normal. Don’t worry. Go to Interfaces: Assign network ports, hit the + icon, and hit Save to add OPT1. Then go toInterfaces: OPT1, enable it, rename it as SKISS or whatever, save and apply changes. In Firewall: NAT: Outbound, selectManual Outbound NAT rule generation, save, and then apply changes. In the same tab, edit each of the three rules (for ISAKMP, LAN and localhost). For each rule, click the e icon at the right, and use the toggle to change the Interface from “WAN” to SKISS (or whatever you’ve named it). Then hit the Apply Changes button.

If you’re using an older pfSense release, there will be six rules after changing outbound NAT from automatic to manual. In that case, just check (select) the three with WAN as interface, delete them using the x button at the lower right, and then apply changes. You don’t need to modify the rules with SKISS (or whatever you called it) as interface.

In Firewall: Rules: LAN, edit the existing rule Default allow LAN to any rule. Using the Gateway toggle in the lowerAdvanced features section, select SKISS as gateway. Rename the rule as Allow LAN to any rule via SKISS and save. In the rule list, it should look like * LAN net * * * SKISS_VPNV4 none. Also edit the existing rule for IPv6 traffic. At the top, toggle Action from Pass to Block. Then apply changes.

Back in the pfSense VM console window, reboot by entering 5 and then y to confirm. After bootup, there should be an IP address after ovpnc1. If it shows NONE, hit enter once or twice. If it still shows NONE, recheck the pfSense configuration using the WebGUI. Start by looking for errors in Status: System logs: OpenVPN. It’s also possible that the direct-connect VPN connection has gone MIA. Check for that, and reconnect if necessary.

At this point, all outbound traffic from LAN will use the VPN gateway (SKISS or whatever) rather than the WAN gateway. Browse http://whatismyipaddress.com or another such site. The IP address should match the iVPN exit server for the route that you’re using.

There are two straightforward tweaks that help prevent leaks. First, in System: Routing: Gateways, edit the VPN gateway. Check Default Gateway to set, save, and then apply changes. Second, in System: General Setup, set the gateway for all DNS servers listed there as WAN. This is necessary because the VPN is now the default gateway. You might think that this setup would prevent the VPN link from coming up, but it doesn’t.

By default in pfSense, all outbound traffic is allowed on WAN. However, it is more secure to specify the hosts that pfSense can connect to via WAN, and to block everything else. This is rather more complicated, because one must use aliases. Using aliases in restricting outbound traffic on WAN is necessary because there can be multiple values, and because hosts may be specified by hostname, rather than by IP address. If this is your first pfSense setup, it’s best to verify that pfSense is working properly before attempting these steps.

Aliases are needed for four types of outbound traffic: 1) the DNS server IPs specified in “System: General Setup”; 2) the pfSense NTP server hostname specified in “System: General Setup”; 3) the OpenVPN server hostname or IP specified in “OpenVPN: Client”; and 4) the pfSense servers needed for updating. In Firewall: Aliases: IP, create four aliases, using the +button to add the values:

NAME VALUES DESCRIPTION
dnssvr 1.2.3.4 5.6.7.8 … DNS server IP addresses
ntpsvr 0.pfsense.pool.ntp.org default pfSense NTP server
vpnsvr vpn.entry.server.net OpenVPN server hostnames or IP addresses
update http://www.pfsense.org updates.pfsense.org pfSense update server

Using these aliases, you then add rules for the WAN interface to pass necessary outbound traffic, and then a final rule to block everything else. In Firewall: Rules: WAN, create these rules, specifying “Single host or address” for the pass rules:

ACTION TCP/IP VERSION PROTOCOL SOURCE PORT DESTINATION PORT GATEWAY QUEUE DESCRIPTION
pass IPv4 TCP/UDP WAN address * dnssvr * * none Allow to DNS server(s)
pass IPv4 UDP WAN address * ntpsvr * * none Allow to NTP server
pass IPv4 TCP/UDP WAN address * vpnsvr * * none Allow to OpenVPN server
pass IPv4 TCP/UDP WAN address * update * * none Allow to pfSense update server
block IPv4 * WAN address * * * * none Block all other IPv4
block IPv6 * WAN address * * * * none Block all IPv6

Then reboot from the console window, by entering 5 and then y to confirm.

Once the pfSense VPN-client VM is working properly, edit the settings for the workstation VM that will be using it. Attach its network adapter (“Adapter 1″) to the internal network that’s attached to the pfSense VM’s LAN adapter. Then start the workstation VM, and browse http://whatismyipaddress.com. The IP address should match the OpenVPN server that you’re using.

If the site doesn’t load, open a terminal and run ping 4.2.2.2. If you get no responses, recheck the VPN connection using the pfSense WebGUI. If Status: OpenVPN shows that it’s up, it’s probably DNS resolution that’s not working. Edit Services: DHCP server and specify reliable third-party DNS servers. But make sure not to use any of the DNS servers that you’re already using for the host machine, the direct-connect VPN, or pfSense itself (as specified in System: General Setup).

Next, check your DNS servers by running the standard DNS spoofability test at https://www.grc.com/dns/ in the workstation VM. It should report only the DNS server(s) that you have specified in pfSense under Services: DHCP server. If it reports others, there’s something wrong with the pfSense setup.

Leak Testing with Wireshark

After reviewing the section on installing and using Wireshark at the end of Basic Setup Using VMs, VPNs and Tor, install Wireshark and configure it on the workstation VM that you’re using. Then reboot the workstation VM. Also start the LiveCD VM. Both should be attached to the internal network that’s attached to the pfSense VM’s LAN adapter.

In testing for leaks, you’ll be capturing on the WAN interface in pfSense (using the WebGUI via the LiveCD VM), and also on eth0 in both the host machine and the workstation VM. If everything is working properly, you should see only traffic with the direct-connect VPN server on host eth0, and only traffic with the indirect-connect VPN server on pfSense WAN. On workstation eth0, you should see traffic with whatever websites that you use while testing.

In order to analyze the pfSense WAN capture with Wireshark, you’ll need to copy the capture file from the LiveCD VM to the host. And, in order to do that, you’ll need to (temporarily) install guest additions in the LiveCD VM, and create a temporary shared folder for the LiveCD VM, as explained in the Creating Diskless Linux LiveCD VM section of Installing VirtualBox and Creating Linux VMs. Alternatively, you can (temporarily) install and configure Wireshark in the LiveCD VM.

To begin the leak test, first go to Diagnostics: Packet Capture in the WebGUI for the pfSense VPN-client VM, which you’re accessing on the LiveCD VM. Accept the defaults for capturing on WAN, but specify 0 for Count (to set no limit). Then open Wireshark on both the host machine and workstation VM. You’ll be capturing on eth0 in both. Now start all three captures.

On the workstation VM, use Firefox to check http://whatismyipaddress.com, run the DNS test athttps://www.grc.com/dns/, and browse for a while. After 10-20 minutes, stop all three captures, and save the pfSense capture on the LiveCD VM to the temporary shared folder on the host (unless you’re also running Wireshark in the LiveCD VM).

Run Statistics/Endpoints on all three captures, using Wireshark in the host (or LiveCD VM) for the pfSense capture. You should see only local IPs and the direct-connect VPN server on host eth0, only local IPs and the indirect-connect VPN server on pfSense WAN, and both local IPs and remote IPs used in testing on workstation eth0.

Now go to Diagnostics: Command prompt in the pfSense WebGUI that you’re accessing on the LiveCD VM. In the box under Execute Shell command, enter killall openvpn and hit Execute. Then start all three captures as explained above. Verify that Firefox on the workstation VM can’t see anything, and that pinging the IP address of your VPN server etc fails. After 10-20 minutes, stop all three captures, and save the pfSense capture on the LiveCD VM to the shared folder as above.

Run Statistics/Endpoints on all three captures. You should see only local IPs and the direct-connect VPN server on host eth0. On pfSense WAN, you should only see traffic with local IPs, and perhaps reconnection attempts from the indirect-connect VPN server that you were connected to. On workstation eth0, you should see only local IPs and connection attempts for whatever sites that you use while testing.

Finally, go to the pfSense console window, and reboot by hitting 5 and y. On the workstation VM, checkhttp://whatismyipaddress.com to verify that it’s all working again.

That’s it.

Part 7 – Paying Anonymously with Cash and Bitcoins

By mirimir (gpg key 0x17C2E43E)

Introduction

In using nested chains of VPN services and Tor for anonymity, the weakest links are arguably the money trails to VPN services that are routed through other VPN services. That’s especially problematic for VPN services to be routed through Tor. Using free VPN services is an option, but they typically cap bandwidth and throughput. The best option for anonymously buying VPN services is sending cash by mail. Using Bitcoins that have been well anonymized through multiple accounts and mixing services is another option. This tutorial covers both.

Cash by Mail

Several VPN providers accept cash payments by mail. Check their payment options, or email support. It’s the most anonymous option, as long as you’re not under active surveillance. However, there are two disadvantages: 1) time (especially for international surface mail); and 2) risk of loss or theft in transit.

Take care to avoid attracting attention. Include a valid return address that’s not associated with you in any way. Use a computer printer, rather than printing by hand. However, do not use a color laser printer, because the printer serial number and a timestamp may be encoded in a pattern of faint yellow dots. Add enough postage, but not way too much. Use large denominations (no coins) and wrap the cash in a sheet of paper, with your account username printed on it. Also, use cash given anonymously as change, rather than from an ATM or bank withdrawal.

Use a public drop box located at least 200 Km away. Go in the evening, and avoid bright lighting. Before approaching, look for security cameras, and avoid looking directly at them. Look downward as much as possible, and wear something seasonably appropriate to conceal your face (such as a hooded shirt or jacket, or a wide-brimmed hat). If driving, park at a reasonable distance to avoid sharing your license tag, but not implausibly far.

Use disposable gloves to avoid fingerprints. Although it’s probably overkill, you can also take steps to confound DNA analysis. Accumulate dust from public places, containing the DNA of many people. Using toilet paper and wearing disposable gloves, lightly rub the dust into each component (cash, cover sheet and envelope).

Bitcoins

Many VPN providers now accept Bitcoin payments. However, contrary to what you might have read, Bitcoins are not at all anonymous, unless you use them prudently. First, to comply with laws against money laundering, mainstream exchanges and purchasing channels now typically require documented identification. Second, the Bitcoin network by design records every transaction in a public accounting log, called the blockchain.

Another risk in using Bitcoins is price volatility. While that has been profitable for some speculators, it discourages routine use. For now, it’s safest to limit Bitcoin holdings to current requirements.

Buying Bitcoins

In order to use Bitcoins, you’ll need a wallet. Although convenient, online wallets are not very safe, because they’re far too likely to disappear, get hacked, or be shut down. The Blockchain wallet is probably the safest online wallet. The Bitcoin Project now recommends the standalone MultiBit client for new users. The original Bitcoin client (Bitcoin-Qt) has become too resource intensive for casual use. It synchronizes the full blockchain, which is currently over 9 GB, and growing at ~630 MB per month. That’s especially problematic when running multiple clients via Tor for Bitcoin anonymization (as discussed below). Although MultiBit is a Java app, that’s secure as long as the Java browser plug-in is not installed.

There are many ways to buy Bitcoins. Although cash deposits are still possible in some places, transactions generally involve bank wires or commercial money-transfer services. Most services don’t accept credit and debit cards, and those that do charge very large transaction fees to cover chargeback risk.

The most anonymous option is buying with cash from private sellers by mail. One reputable option is Nanaimo Gold. Paying cash to private sellers in person is less anonymous. But it’s easy to find sellers using LocalBitcoins, and there’s an escrow service to reduce the risk of fraud. Other (riskier) options for finding private sellers include Bitcoin Forum /…/ Currency exchange and #bitcoin-otc.

Before buying your Bitcoins, set up an initial wallet. The best place for it depends on how anonymously you’re purchasing your Bitcoins. Anonymity levels should be comparable, so your Bitcoins don’t compromise the location, and vice versa. If you must identify yourself to buy Bitcoins, it’s OK to just use the Blockchain browser plug-in wallet, without any VPN. If you’re paying with cash in person, but without identifying yourself, it’s best to run a Multibit client through your direct-connect VPN, either on the host machine or on a workstation VM that’s dedicated to that VPN exit. If you’re paying with cash through the mail, it’s best to use a Multibit client in Whonix (a pair of Linux VMs that connects via Tor) as your initial wallet. Using Whonix is explained below.

Installing the Multibit client in Linux is easy. Download MultiBit for Linux. Then open a terminal window, and run these commands:

sudo apt-get update
sudo apt-get install openjdk-7-jdk
cd ~/Downloads
chmod +x multibit-0.5.12-linux.jar
java -jar multibit-0.5.12-linux.jar

Complete the installation, and run MultiBit. It should report being Online (at bottom left). That’s it.

Anonymizing Bitcoins

Once you have your Bitcoins, it’s prudent to anonymize them appropriately before use. All Bitcoin transactions are recorded in the blockchain, and there’s no way to prevent that (without totally breaking the system). However, there are several Bitcoin mixing services. Deposits go into a pool, and payments come randomly from the pool. You transfer Bitcoins through a chain of anonymous Bitcoin wallets, using different mixing services for successive transfers. If the wallets aren’t otherwise associated, your Bitcoins become less and less associated with you as they move through the chain, and no meaningful association remains after a few mixing transfers.

Using multiple anonymous MultiBit clients via Tor is the best option. Multibit clients are fast, because they don’t download the Bitcoin blockchain. And they are secure, because they’re not hosted by a third party. For better anonymity, each Multibit client should have a wallet with several several sending and receiving addresses, or even several wallets. For each transfer from one client to another through a mixing service, you randomly spread the Bitcoins among several address combinations. That increases the anonymity that each transfer provides, by reducing correlation based on quantities transferred.

Using Multibit via Tor is easy using Whonix. Reputable mixing services include BitLaundry and Bitcoin Fog (a hidden service that’s reachable only via Tor). It’s no longer possible to send via shared wallets on Blockchain. Also, OnionBC has either broken, or become a scam. It accepts deposits, but won’t execute withdrawals.

After each mixing step, it’s crucial to check the receiving address for taint from the sending address. On the Blockchain explorer page, enter your receiving address in the “Search” field, and hit enter. Then click “Taint Analysis”, and search for your sending address in the results page. If it appears, you need to remix.

A Bitcoin mixing setup might look like this:

  • initial wallet
    • Blockchain wallet for Bitcoins purchased non-anonymously
    • MultiBit client via direct-connect VPN for Bitcoins purchased in-person with cash
    • MultiBit client in Whonix via Tor for Bitcoins purchased with cash by mail
  • first Whonix/MultiBit mixing client: don’t use for purchases
  • second Whonix/MultiBit mixing client: use for first indirect-connect VPN (e.g., to replace SecurityKISS)
  • third Whonix/MultiBit mixing client: use for second indirect-connect VPN
  • fourth Whonix/MultiBit mixing client: don’t use for purchases
  • fifth Whonix/MultiBit mixing client: use for VPN to route through Tor

You can spend Bitcoins from anywhere in the wallet chain. In doing so, it’s important to match the anonymity levels of Bitcoins and purchases. Your Bitcoins embody a money trail back to you, which becomes increasingly tenuous along the wallet chain. However, your purchases may independently create associations. That’s obvious for items that are shipped to you. But VPN services are also more or less associated with you, depending on their location in the nested chain. You don’t want your Bitcoins to compromise the anonymity of your purchases. And you don’t want your purchases to compromise the anonymity of your Bitcoin wallet, and in turn other purchases that you make from it.

MultiBit Clients in Whonix

Whonix comprises a pair of Debian VMs: a gateway VM that connects to the Tor network, and a workstation VM that connects through the gateway VM. Installing Whonix and setting up MultiBit wallets is easy. Start by downloading Whonix-Gateway and Whonix-Workstation to your host machine, via the direct-connect VPN service. It’s best to verify the downloads as instructed using the OpenPGP signatures and the Whonix signing key. If you can’t be bothered with that, at least download them using BitTorrent (which is more secure, as explained).

Each Whonix gateway and workstation VM must have a unique name (which determines the name of its folder). Also, the gateway and workstation VMs of each Whonix instance must share a uniquely named internal network. For example, import the first Whonix pair, using File / Import Appliance in VirtualBox (reinitializing MAC addresses). Then edit the names of both VMs, adding a unique suffix to distinguish that pair from the rest that you’ll be importing, and to facilitate keeping track of them.

You want these Whonix instances to connect through your terminal indirect-connect VPN service. Initially, that’s SecurityKISS. Change Adapter 1 of the gateway VM from NAT to, for example, the internal network pfS-SK. In both Adapter 2 of the gateway VM and Adapter 1 of the workstation VM, rename internal network Whonix to match the edited VM names.

Start the first Whonix gateway, and then the workstation. Download and install updates as instructed. After rebooting both VMs, download and install MultiBit as described above, and start MultiBit. It should report being Online (at bottom left). There’s no need for MultiBit clients to be running except when you’re actively using them, because they synchronize very quickly.

Then repeat the process – importing Whonix, renaming the VMs and their shared internal networks, and installing MultiBit – as needed for your mixing chain. However, start the first transfer (see below) before updating the rest of your Whonix instances and installing MultiBit. With the free option, SecurityKISS allows just 300 MB per day, and that’s barely enough for downloading updates on two Whonix instances.

Bitcoin Anonymization Specifics

The best place for setting up the first transfer depends on the location of the initial Bitcoin wallet. For the Blockchain browser plug-in wallet, it’s best use BitLaundry on a LiveCD VM connecting through your direct-connect VPN. That way, your ISP at least doesn’t see that you’re using BitLaundry, even though the wallet itself is funded non-anonymously and therefore always accessed without any VPN. Otherwise, and for subsequent transfers in the mixing chain, use the workstation VM (or Whonix instance) that’s running the Multibit client which is sending the Bitcoins.

As noted above, it’s best to use multiple sending and receiving addresses (or even multiple wallets) for transfers via mixing services. For each transfer from one client to another through a mixing service, you randomly spread the Bitcoins among several address combinations. That increases the anonymity that each transfer provides, by reducing correlation based on quantities transferred.

There’s no need to create a wallet at BitLaundry. Create a separate mixing scheme for Bitcoins from each of the appropriate Send addresses in your wallet(s). For destination addresses, use the Request (receiving) addresses of the next wallet(s) in your mixing chain. Specify the desired number of days, and transactions per recipient per day. After reviewing and confirming the scheme, send your Bitcoins to the funding address provided by BitLaundry. Repeat for each sending address.

Bitcoin Fog requires an account, but not an email address. Blockchain requires both. You send your Bitcoins from MultiBit to the deposit address for your mixing-service account. After (at least) several hours, send your Bitcoins to the Request (receiving) addresses for the next client in your mixing chain. With Bitcoin Fog, transfers are split over time (by at least six hours) and you can delay them. For increased anonymity, you can use multiple Bitcoin Fog accounts, one for each of your sending addresses.

To avoid associating Bitcoin wallets with purchases, you can pay through BitLaundry or Blockchain, rather than directly from the wallet. However, a recipient might blacklist mixing services, so there’s some risk of payments being lost. With BitLaundry, don’t split transfers over time, because receiving addresses are sometimes deleted after receiving just one payment. And don not use Bitcoin Fog, because all transfers are split over time by at least six hours.

As you extend your nested VPN chain, it’s arguably best to reconfigure your Whonix instances to connect through the new terminal indirect-connect VPN service. However, if you’re using 3-4 VPN services in your nested chain, especially if it’s a branched chain, having your Whonix instances connect at different nodes would isolate them better from each other. But I don’t recommend using Whonix with less than a two-VPN nested chain.

In any case, there is a risk (albeit small) in moving Whonix instances to longer nested VPN chains. To help protect against attacks involving evil relays, Tor uses persistent entry guards. And so a client’s entry-guard selection might serve as a fingerprint for correlating activity from multiple VPN-exit IP addresses.

On the other hand, changing entry guards more frequently increases vulnerability to adversaries that run relays (in particular, entry guard relays). In light of a recent paper from the Tor research community, Johnson et al (2013) Users Get Routed: Traffic Correlation on Tor by Realistic Adversaries, there’s been talk of rotating entry guards even less frequently.

If you decide to force Tor to choose new entry guards, it’s easily accomplished. Before switching one of your Whonix gateway VMs to a different VPN exit, run these commands:

sudo su
cd /var/lib/tor
cat state | more

Note the names of the entry guards (typically three). Then run these commands:

service tor stop
rm *

It’s important to stop Tor before clearing /var/lib/tor. Otherwise, it may all get rebuilt during normal shutdown. After rebooting the gateway, give it a few minutes to connect to the Tor network and fix itself, and then run these commands:

sudo su
cd /var/lib/tor
cat state | more

You should now see a different set of entry guards.

Part 8 – Creating Nested Chains of VPNs and Tor

By mirimir (gpg key 0x17C2E43E)

Introduction

Cloud showing Nested chained VPNs and TOR

This tutorial covers using multiple pfSense VPN-client VMs and Tor-client VMs to create arbitrarily complex nested and branched chains of VPNs and Tor, such as the setup (reproduced above) suggested in the Planning Initial Setup section ofPlanning Advanced VM and VPN Setup. Doing that is relatively easy, once you have planned your setup, set up a secure host machine, and created pfSense VMs as clients for multiple anonymously-purchased VPN services, Tor-client VMs (more on that below) and Linux workstation VMs that access the Internet through them. The various VirtualBox VMs that you create are relatively-independent modules. Setting up nested and branched chains of nested VPN tunnels and Tor connections, and workstation VMs that use them, requires little more than changing how these VMs are networked in VirtualBox.

Basic Nested VPN Chains

This section is written for the case where you’re using your direct-connect VPN service in the first pfSense VPN-client VM, and no VPN service on the VM host machine. If you continue using your direct-connect VPN service on the VM host, and use another anonymously-purchased, indirect-connect VPN service in the first pfSense VPN-client VM, you will have a nested chain of two VPNs.

Connection with One VPN

Connection with Two VPNs

In that case, you can just apply the above difference (one VPN vs two VPNs) to the other diagrams and discussion that follow.

Setup for one pfSense VPN-client VM and workstation VM

The first pfSense VPN-client VM typically has its WAN adapter NATed to the host via the VirtualBox router, and its LAN adapter attached to a VirtualBox internal network. The pfSense VM runs a DHCP server for that internal network, just as gateway routers typically do for physical LANs. When the OpenVPN client in pfSense establishes a VPN connection, it creates a virtual network adapter (aka tun for tunnel). There are routing and firewall rules that restrict all LAN (and attached VirtualBox internal network) traffic to this VPN tun adapter (instead of WAN) for Internet access, and also block incoming connections, just as gateway routers typically do for physical LANs.

Anything running in workstation VMs attached to this VirtualBox internal network can only access the Internet through the pfSense VM and its VPN tunnel. Applications and VPN networking are isolated in separate VMs (workstation and pfSense VMs, respectively). Exploits that manage to compromise workstation VMs can’t get at VPN networking unless they break out to the host or compromise pfSense. While either is possible, neither is arguably likely, unless you’ve attracted a highly-skilled adversary.

Setup for two pfSense VPN-client VMs and workstation VMs

To add another VPN tunnel (VPN2) to the nested chain, you just create another pfSense VPN-client VM, which connects to another anonymously-purchased VPN service. You attach its WAN adapter to the internal network attached to the LAN adapter of the first pfSense VPN-client VM (VPN1). The VPN tunnel from the second pfSense VPN-client VM (VPN2) reaches the Internet through the first pfSense VPN-client VM and its VPN tunnel (VPN1). You attach the LAN adapter of the second pfSense VPN-client VM (VPN2) to another VirtualBox internal network, for which it is the DHCP server. Its VPN tunnel (VPN2) is routed through its LAN adapter to its internal network (and firewalled). Workstation VMs attached to this second VirtualBox internal network access the Internet through the nested VPN chain, as shown above (VPN2 routed through VPN1).

You can add additional VPN tunnels to your nested chain in the same way, either at the end, or further in to create branches. In choosing additional VPN services, there are two key and potentially-conflicting criteria. First, as discussed in the sectionUsing Nested Chains of VPNs and Tor to Distribute Trust of Part 3. Planning Advanced VM and VPN Setup, choosing providers in poorly-cooperating spheres of influence arguably mitigates the risk of joint compromise or subversion.

Second, network latency increases as you add VPNs to the nested chain. As long as you have a broadband Internet connection, and are using VPN services that have fast Internet connections, network latency will be the limiting factor for overall throughput. Even with careful design, latency for nested chains with more than four VPNs will likely make them unusable. Conversely, terminal nodes in branched VPN chains don’t compete very much with each other for bandwidth, unless you push it too far and saturate the shared proximal VPN tunnel.

Also, in chaining multiple pfSense VPN-client VMs, it’s crucial that adjacent pfSense VMs have different LAN IP address ranges. Otherwise, no traffic will flow, because pfSense is a NAT router, not a switch. The simplest approach is using 192.168.1.0/24 for the first pfSense VPN-client VM, 192.168.2.0/24 for the second, 192.168.3.0/24 for the third, and so on. It’s true that routing local resources through VirtualBox internal networks with distinct IP ranges would be difficult, but that’s less important than ensuring security through full isolation.

First review the Creating pfSense VM and Configuring VPN Client section of Part 6. Creating pfSense VMs as VPN Clients. As described, you start by creating the new pfSense VM, installing pfSense, and configuring em0 as the WAN interface andem1 as the LAN interface. However, after pfSense finishes rebooting, and before configuring and setting up a VPN client, you need to change pfSense’s LAN IP address range.

In the pfSense console window (not the webGUI), start by typing 2 in order to Set interface(s) IP address and hit enter. Then type 2 for LAN, and hit enter. Now type the new LAN IPv4 address (e.g., 192.168.2.1) and hit enter. Type 24 as the subnet bit count, and hit enter. Answer y for Do you want to enable the DHCP server on LAN?, and hit enter. Type the start address (e.g., 192.168.2.100) and hit enter. Then type the end address (e.g., 192.168.2.199) and hit enter. Answer n for Do you want to revert to HTTP as the webConfigurator protocol? and hit enter. Finally, reboot pfSense by typing 5, hitting enter, typing y, and hitting enter. Finally, configure a LiveCD VM to access the new pfSense’s webGUI, and use it to finish configuring the new pfSense VM with a client for your new VPN service, as described in Part 6.

In bringing up a nested VPN chain, you must start with the direct-connect VPN client, because it provides Internet connectivity for the rest of the VPN clients. After the direct-connect VPN has connected, start the pfSense client for the VPN that connects through it, and wait for it to finish booting. For pfSense VPN clients, you’ll see an IP address to the right ofovpnc1 if the VPN connection has been established. If you don’t see that, you can hit return once or twice to refresh the display. Once each pfSense VPN-client VM has connected, start the next one, and so on.

Once all of the pfSense VPN-client VMs are up, you can start whatever workstation VMs that will connect through them. If any of the pfSense VPN-client VMs are not connecting properly, you can use your Linux LiveCD VM to login to its webGUI and figure out what’s broken, as described in Part 6. Generally, you can leave all of the pfSense VMs running while you’re working/playing, and even whatever associated workstation VMs you’ll be using. However, it may be prudent (depending on your risk model) to shut down all VMs and the host machine when you’re done (and thereby deny access by adversaries to unencrypted data).

Nested VPN chains occasionally stop working, especially on weekends (when maintenance is typically scheduled). First try restarting each of the VPN clients in order, from direct to increasingly indirect. If you find that one of the VPNs isn’t connecting, review its connection log for errors. There may be interactions among VPN connections. For example, if the DNS server used by a VPN client dies or gets overloaded, VPN(s) tunneled through that VPN won’t connect if you’ve specified servers by hostname, rather than by IP address (because DNS lookups will fail ). You may need to switch servers and/or ports for one of your VPNs.

Tor Gateway VMs

There are two easy ways to add Tor connections to nested chains. One is ra’s Tor gateway VM. It’s an OpenWRT-based router VM that provides Tor connections using transproxy, and it’s very easy to network with pfSense VPN-client VMs. The other is Whonix. It’s an integrated pair of Debian-based VMs, comprising a gateway and a workstation. The Whonix gateway VM isn’t a router, however, so networking with pfSense VPN-client VMs is nontrivial. But it’s easy to run VPN clients in the Whonix workstation. And by the way, in case you’re wondering, it’s probably unworkable to route Tor through a VPN that’s routed through Tor.

Whonix

Using Whonix is covered in the MultiBit Clients in Whonix section of Part 7. Paying Anonymously with Cash and Bitcoins. Start by downloading Whonix-Gateway and Whonix-Workstation to your host machine, via your current best VPN chain. It’s best to verify the downloads as instructed using the OpenPGP signatures and the Whonix signing key. If you can’t be bothered with that, at least download them using BitTorrent (which is more secure, as explained).

Then import both of the Whonix VMs, using File / Import Appliance in VirtualBox (reinitializing MAC addresses). If you’ll be using multiple Whonix instances, each Whonix gateway and workstation VM must have a unique name (which determines the name of its folder). It’s good practice to edit the names of both Whonix VMs right after importing them, adding a unique suffix (or whatever) to distinguish them from others that you may import later.

Before running a Whonix gateway VM, it’s crucial to change its first (WAN) adapter from NAT to a VirtualBox internal network sourced by one of your pfSense VPN-gateway VMs, using the Network tab in the VirtualBox GUI. Otherwise, the Whonix gateway would reveal to your ISP that you’re using Tor. It would also provide your ISP-assigned IP address to Tor’s directory authorities, and as well to the entry guards that it chooses. Also, each Whonix gateway VM must have a uniquely-named internal network attached to its second (LAN) adapter. In order for the workstation VM to connect via the gateway VM, the workstation VM’s network adapter and the gateway VM’s second (LAN) adapter must share a uniquely named internal network. It’s helpful to name the gateway VM, workstation VM and internal network for each Whonix instance in a logical and memorable way, to avoid confusion and mistakes.

Adding Whonix instances to VPN chains is trivial. Using the VirtualBox GUI, edit the first (WAN) adapter in the Whonix gateway VM, and specify the internal network sourced by the desired pfSense VPN-gateway VM. In order to further isolate multiple Whonix instances from each other, you may want the gateway VMs to connect at different points in your nested VPN chain. That reduces the chance that adversaries controlling parts of the Tor network will associate the two Whonix instances.

Installing VPN clients in Whonix workstation VMs is also trivial, as described in the Setting Up VPN on Linux Workstation VM section of Part 2. Basic Setup Using VMs, VPNs and Tor. Whonix workstations are based on Debian, customized to securely use Tor. However, given that Tor only routes TCP traffic, the Network Manager settings are different. In theGeneral tab of the Advanced window, check Use a TCP connection and Use custom gateway port, and specify the appropriate TCP port number from your VPN provider. It’s crucial to use a VPN service that’s not associated with you. SeePart 7. Paying Anonymously with Cash and Bitcoins.

As everything else does, VPN connections will probably take longer to establish through Tor. Also, given that all applications in the Whonix workstation VM are configured to use Tor through the gateway VM, you’ll need to modify their preferences in order to connect through the VPN tunnel. In Firefox, for example, you navigate Edit / Properties / Advanced / Network / Connection..Settings, and select No proxy. And you’ll need to reverse the change if you later want to browse through Tor without the VPN connected.

OpenWRT Tor gateway

To use ra’s OpenWRT Tor gateway VM, first download the latest version, currently Tor gateway 0.5.4.ova. Import it usingFile / Import Appliance in VirtualBox (reinitializing MAC addresses). As with the Whonix gateway VM, edit its first (WAN) adapter from NAT to a internal network sourced by one of your pfSense VPN-gateway VMs, and uniquely rename the internal network attached to its second (LAN) adapter. That’s it.

Because ra’s Tor gateway VM is (like pfSense) a router running a DHCP server, you can attach any workstation VM to the internal network attached to its second (LAN) adapter, and so reach the Internet through Tor. As with the Whonix workstation, workstation VMs can only reach the Internet through the Tor gateway, so there’s negligible risk that improperly configured applications will bypass Tor. However, given that Tor only routes TCP traffic, applications that depend on UDP traffic will not work properly. Also, browsing with stock Firefox is far less anonymous than with the Tor-optimized version in the Tor Browser Bundle, Tails and Whonix.

You can also attach a pfSense VPN-gateway VM to the internal network attached to the Tor gateway’s second (LAN) adapter. As with the OpenVPN client in the Whonix workstation VM, you’ll need to configure the pfSense OpenVPN client with the proper server address and port number for connecting in TCP mode. See Part 6. Creating pfSense VMs as VPN Clients. As with the OpenVPN client in the Whonix workstation VM, the OpenVPN client in pfSense will probably take longer to connect through Tor. As noted above, it’s crucial to use a VPN service that’s not associated with you.

When routed through Tor, pfSense VMs can’t resolve hostnames to IP addresses. That prevents pfSense from getting the correct time from <0.pfsense.pool.ntp.org>. However, given that the Tor exit IP address changes frequently, it is unwise to specify specific NTP servers by their IP addresses, because that would reduce anonymity.

Testing and Optimization

The various VirtualBox VMs that you create – pfSense VPN-client, OpenWRT Tor gateway, Linux workstation and LiveCD, and Whonix VMs – are relatively-independent modules. Setting up arbitrarily complex nested and branched chains of nested VPN tunnels and Tor connections, and workspaces that access the Internet through them, requires little more than changing how they’re networked in VirtualBox. However, creating setups that are usable and reliable requires testing and optimization. With complex setups, that can be quite challenging, because there are so many different ways to fail.

It’s best to start with a simple setup. Once it’s usable and reliable, you’ll have a reliable core that you can build on, and you will also have acquired requisite experience and skills. For the setup suggested in the section Planning Initial Setup ofPlanning Advanced VM and VPN Setup, which is pictured at the top of this page, it’s best to start with just two VPNs: VPN1and VPN2. If you’re running the direct-connect VPN (VPN1) in the host machine, start with just one pfSense VPN-client VM (VPN2).

To provide context for testing your nested VPN chain(s), periodically check the latency (ping) and speed of your native ISP connection at Speedtest. If at all possible, don’t use your VM host machine for that. Also, avoid checking your ISP connection while actively testing nested VPN chain(s), because that would associate their IP addresses in Speedtest’s logs. For the same reason, don’t check multiple VPN-chain nodes simultaneously. Wait at least several minutes between tests from different IP addresses.

If you’re running the direct-connect VPN in the host machine, and have gotten this far, it’s probably working well enough. If there are connection problems, review the Network Manager connection log, as described in the section Viewing Network Manager OpenVPN Logs of Part 4. Setting Up Secure Host Machines. You’ll need a Linux LiveCD VM for testing each VPN that you’re running in a pfSense VM, which you attach to that pfSense VM’s internal network. I recommend using multiple LiveCD VMs here for two reasons: 1) to avoid leaking VPN account information from pfSense to workspace VMs; and 2) to limit access to pfSense from potentially-compromised workspace VMs. If you have added verb 5 in the Advanced box in OpenVPN client setup at VPN: OpenVPN: Client, a detailed connection log is available at Status: System logs: OpenVPN.

To optimize your nested VPN chain, start with the direct-connect VPN, and work methodically through the rest of the VPNs. For each VPN connection in the chain, check latency (ping) and speed at Speedtest. If you can’t connect, review the connection log at Status: System logs: OpenVPN in the pfSense webGUI (or Network Manager OpenVPN Logs, on the host machine) for errors. It’s normal for latency (ping) to increase as you add more VPNs to the nested chain. That primarily reflects additional processing delay in networking hardware, and not simply longer path length. Although speed typically decreases as you add more VPNs, due to both increased latency and network throttling, you may occasionally see it increase. As noted, wait at least several minutes between tests from different IP addresses. Once you’re satisfied with each VPN connection, repeat the process with the next one in the nested chain.

If you have a typical broadband Internet connection, reasonable targets for VPN1, VPN2 and VPN3 are as follows:

VPN LEVEL LATENCY (MSEC) SPEED (MBPS)
VPN1 150-200 5-10
VPN2 200-250 2-5
VPN3 250-350 1-3

If you’re seeing lower speeds, especially for downloading, try using different VPN servers, different port numbers, TCP mode vs UDP mode, etc. Some ISPs throttle traffic on nonstandard ports. Also, in order to meet your design goals, as discussed in section Using Nested Chains of VPNs and Tor to Distribute Trust of Part 3: Planning Advanced VM and VPN Setup, it may be necessary to accept slower connections.

If nothing seems to help, get support as anonymously as possible. Anonymity is especially important for your indirect-connect VPNs. Seek support while connecting through the VPN that the problematic VPN connects through. It’s best to use online forums that support HTTPS. Start with your provider’s support forum. You can also post in the privacy problems section of Wilders Security Forums. If you must submit a support ticket to the VPN provider, be sure to use an anonymous email address. And keep in mind that support tickets typically generate unencrypted replies, which may quote the support request.

Leak Testing with Wireshark

The section Installing and Checking VPN-Firewall in Part 4. Setting Up Secure Host Machines explains how to test the host machine’s VPN connection and firewall setup using Wireshark. The section Leak Testing with Wireshark in Part 6. Creating pfSense VMs as VPN Clients does the same for the first pfSense VPN-client VM (in that case, running an indirect-connect VPN). It’s crucial to verify that no traffic bypasses the VPN tunnel, even after the VPN connection is killed.

You can apply the same approach to each of the gateway VMs (pfSense VPN-client, Whonix Tor-gateway or OpenWRT Tor-gateway) in a nested chain. Using Wireshark instances, you capture traffic at three points:

  1. eth0 adapter of a workstation VM that accesses the Internet through the gateway VM being tested
  2. WAN adapter of the gateway VM being tested
  3. LAN adapter of the gateway VM through which the gateway VM being tested connects

The first capture shows you what Internet sites the workstation is accessing (or trying to access). The second and third captures show you what traffic is leaving the gateway VM for the Internet. They should be identical, and it’s only necessary to use one of them, if the other is hard to get at (e.g., the WAN adapter on an OpenWRT Tor-gateway VM). When the gateway VM is working properly, the second and third captures should show only local IPs and the servers (OpenVPN or Tor) that the gateway is using, and they should not show any of the remote IPs seen in the first capture.

When the gateway VM is broken, the second and third captures should show only local IPs and reconnection attempts from servers that the gateway was using. They should definitely not show any of the remote IPs seen in the first capture. If the second or third captures show any of the remote IPs seen in the first capture, whether the gateway VM is functional or not, there are leaks that must be fixed.

There are instructions for killing the openvpn process in the sections of Part 4 (for the host machine) and Part 6 (for pfSense) cited above. Basically, you run killall openvpn at a command prompt. To re-establish the VPN, use Network Manager in the host machine, and just restart the pfSense VM. To kill the tor process in the OpenWRT Tor-gateway VM, you run killall torat the command prompt. For the Whonix Tor-gateway VM, it’s sudo killall tor. To restart Tor, it’s best to just reboot the gateway VM.

Guide from: https://www.ivpn.net/privacy-guides

Advertisements

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s