Last update: March 17, 2019. This website uses cookies. By using our website, you acknowledge that you have read, understood and agreed to our Privacy Policy, Cookie Policy, Terms of Service, and E-Sign Consent. More information

 Actions

Tunnels/Connecting to a VPN before Tor/Testing

< Tunnels‎ | Connecting to a VPN before Tor

Contents

Note: This Page is for Testing Only![edit]

Please use the stable Connecting to a VPN before Tor Wiki page for VPN configuration.


User -> Vpn -> Tor -> Internet

Introduction[edit]

It is possible to combine Tor with tunnels like VPNs, proxies and SSH. The traffic can be sent through both Tor and the second tunnel, in either order. However, this is an advanced topic and appropriate only for special cases. Adding a second connection does not automatically improve security, but it will add significant complexity. The potential positive or negative effects on anonymity are being controversially debated.

The Whonix project remains technologically neutral in the anonymity discussion. The improper combination of Tor and another service may actually degrade a user's security and anonymity. One such case is using a proxy to hide Tor network traffic from your ISP.

While proxies are a type of tunnel-link they should not be thought of as a replacement for a VPN and SSH in this configuration. This is because connections to proxies are unencrypted and therefore should not be used to hide Tor use. Proxies are ok for circumvention of censorship if that has been shown to work from the users location but are unsuitable for hiding Tor due to lack of encryption.

Combinations of tunnels-links with Tor are difficult to set up and should only be attempted by advanced users. For the vast majority of Whonix users, using Tor in isolation – without a tunnel-link (VPN, proxy or SSH) – is the correct choice.

Tunnel-link before Tor use cases[edit]


User -> tunnel-link -> Tor -> Internet


In this configuration network traffic will (1) enter the tunnel-link and pass through your ISP -> (2) exit your tunnel-link server as encrypted Tor traffic-> (3) enter to the Tor network-> (4) exit the Tor network at a Tor exit node as normal internet traffic (encrypted or unencrypted).

Possible uses:

  • You must connect to your tunnel-link to access the internet.
  • Your ISP blocks Tor and Tor bridges but doesn’t block the tunnel-link.
  • Fear of de-anonymizing attacks against the Tor network; belief that your tunnel-link is able to protect your identity in such case.

Warnings[edit]

Note: The following warnings are not Whonix specific issues. They are general issues associated with combining Tor with tunnel-links.

Trusting Service Providers[edit]


Failed Closed Configurations[edit]


Tunnel-links can Affect Anonymity[edit]


Using the same Tunnel Provider in Multiple VMs at the same Time[edit]


Reusing Tunnel-links[edit]


Qubes-Whonix ™ TemplateVMs[edit]


Hiding Tor Usage from ISPs[edit]


Selecting a Service Provider[edit]

Selecting a provider location presents unique challenges that must be accounted for when chaining tunnel-links with Tor.

  • Tor avoids using more than one relay belonging to the same operator when building circuits. Legitimate Tor relay operators adhere to Tor's relay operator practices of announcing which relays belong to them by declaring this in the Tor relay family setting. Tor also avoids using Tor relays that are within the same network by not using relays within the same /16 subnet. [6] Tor however does not take into account your real external IP nor destination IP addresses. [7] In essence, you must avoid using the same network/operator as your first and last Tor relays since this would open up end-to-end correlation attacks.
  • Many tunnel providers use shared IP addresses which means that many users share the same external IP address. On one hand this is good since that is similar to Tor, where many users share the same Tor exit relays. On the other hand, this can in some situations lead to actually making you less safe.
  • It is possible to host Tor relays [any... bridges, entry, middle or exit] behind VPNs or tunnel-links. For example, there are VPN providers that support VPN port forwarding. This is an interesting way to contribute to Tor while not exposing oneself to too much legal risk. However, in certain situations it is possible a VPN or other tunnel-link and a Tor relay could be hosted by the same operator, in the same network or even on the same IP.
  • In an economy with a deep labor division, there are those that provide the service to host servers (VPS etc.). While others provide VPN and other tunnel-link services and rent such servers. It is common that diverse customers run and/or share the same IP address. This is another situation where a VPN or other tunnel-link and a Tor relays could be hosted by the same operator, in the same network or even on the same IP.
  • By adding arbitrary tunnel-links to your connection chain, you could unknowingly use the same operator/network twice in your connection chain.
    • Scenario 1)
      • a) User uses VPN IP A on the host, thereby using it as it is first relay.
      • b) User's Tor client happens to pick a Tor exit relay running on VPN IP A.
        • Conditions a and b match at the same time. The user is now using the same IP address as first and last proxy.
        • --> By using the VPN the user did not get more, but less secure.
    • Scenario 2)
      • a) User sets up a VPN inside Whonix-Workstation ™. This configuration results in User -> Tor -> VPN -> Internet. Using VPN IP A.
      • b) A Tor entry guard is being hosted on VPN IP A.
        • Conditions a and b match at the same time. The user is now using the same IP as first and last proxy.
        • --> By using the VPN the user did not get more, but less secure.
  • Choose your tunnel providers wisely.
    • Find out in which physical and legal jurisdiction and network their servers are located.
    • Perhaps avoid using VPN or SSH providers that support port forwarding.
    • Perhaps use only tunnel-link providers that are assigning private - as in not shared with others - unique - IP addresses. However, it is not clear if this does more harm than gain as noted above.
    • Perhaps use tunnel-link providers that run their own servers rather than relying on shared infrastructure.
  • Perhaps manually pick your Tor relay[s]. Specifically your entry guard[s] or bridge[s]).
    • Tor documentation generally discourages tampering with Tor's routing algorithm by manually choosing your relays, but since you are trying to be clever by extending your Tor chain despite of all the information regarding the difficulty of this endeavor, perhaps it would make sense to pick your entry guard manually.
    • Using Bridges might be an alternative, but note the following quote. "Bridges are less reliable and tend to have lower performance than other entry points. If you live in a uncensored area, they are not necessarily more secure than entry guards. Source: bridge vs non-bridge users anonymity."

VPN Configuration Options[edit]

Introduction[edit]


What's the difference of installing a VPN on the host versus installing on Whonix-Gateway ™?

VPN Installed on the Host VPN Installed on Whonix-Gateway ™ VPN Installed on both the Host and Whonix-Gateway ™
All Whonix Traffic Routing User -> Host's VPN -> Tor -> Internet User -> Gateway's VPN -> Tor -> Internet User -> Host's VPN -> Gateway's VPN -> Tor -> Internet
All Host Traffic Routing User -> Host's VPN -> Internet User -> Internet User -> Host's VPN -> Internet
Whonix-Gateway ™ Compromise Host's VPN Affords Protection Nil Protection Host's VPN Affords Protection

To decide the best configuration in your circumstances, consider:

  • Is it necessary to hide all traffic from the ISP? [8] Then install the VPN on the host.
  • Should the VPN provider be able to see all traffic? [8] Then install the VPN on the host.
  • Should the VPN provider be limited to seeing Tor traffic, but not clearnet traffic? Then install the VPN on Whonix-Gateway ™.

VPN Client Choice[edit]

  • Use OpenVPN.
  • Using bitmask with Qubes is not yet documented.[9]
  • Other VPN clients are unsupported. We are not aware of any sane VPN client choices besides OpenVPN.

Separate VPN-Gateway[edit]

Qubes-Whonix ™ only! Non-Qubes-Whonix ™ is unsupported!

A separate VPN-Gateway between Whonix-Gateway ™ and sys-firewall, i.e. Whonix-Workstation ™ -> Whonix-Gateway ™ -> sys-vpn -> sys-firewall -> sys-net.

User -> VPN -> Tor -> Internet

These "Separate VPN-Gateway" instructions are new. You might be one of the first users. You might run into minor issues. Please test and report how it went.

1. Clone a TemplateVM for example, debian-9 and name the new template clone debian-9-vpn. [10]

Qube Manager -> debian-9 -> Clone qube -> Enter name for Qube clone: debian-9-vpn -> Press: OK

2. Create a new ProxyVM based on the newly cloned template. Name the VM sys-vpn and set sys-firewall as NetVM. Make sure to check [✔] the box for provides_network.

Qube Manager -> Qube -> Create new qube

  • Name and label: sys-vpn (Set any color)
  • Type: AppVM
  • Template: debian-9-vpn
  • Networking: sys-firewall
  • Advanced: [] Provides network
  • Press: OK

3. Setup the VPN-Gateway as per Qubes VPN documentation. The instructions to configure the VPN gateway using iptables and CLI scripts is preferred to prevent clearnet leaks when the VPN breaks down.

When a failed closed configuration is used and the VPN connection breaks down, all traffic originating from Whonix-Gateway ™ (commonly called sys-whonix) would only be forced through Tor. This is what you want if you are reading this documentation chapter.

User -> Tor -> Internet

If a failed closed configuration is not used, network traffic (such as DNS queries) could leak through the VPN tunnel to the Internet when the tunnel connection breaks down.

User -> VPN(clearnet leaks!) -> Tor -> Internet

4. Check, that your sys-vpn is fully functional. Test connectivity from inside the sys-vpn as per: Qubes VPN Documentation

Note: Both TCP and UDP VPN connections should work. System DNS should work out of the box so no DNS configuration is required for Whonix-Gateway ™.[11]

Done!

For troubleshooting, see footnote. [12]

On the Host[edit]

Non-Qubes-Whonix ™ only! (Because in Qubes, the host is non-networked by default. Qubes-Whonix ™ users have the option to use a #Separate VPN-Gateway but could also install the VPN software #Inside Whonix-Gateway ™.)

User -> VPN -> Tor -> Internet

When using a Whonix-Gateway ™ virtual machine, connect to a VPN using software on the host operating system (and not on the Whonix-Workstation ™ nor Whonix-Gateway ™).

Using software inside the host operating system may be more convenient if your more familiar with the host operating system than Whonix. Additionally, your VPN provider might provide custom software with tools for connecting to their servers. However, there are issues that you must consider:

  • A VPN on the host operating system will route all traffic originating from the host through the VPN, as well as Whonix ™ traffic. It is up to your preferences, if you like this or not.
  • Your VPN software may not be designed or configured to "fail closed". That is, if your VPN session suddenly disconnects, your Tor connection will be automatically sent through your ISP without going through your VPN service.

How to add the VPN in Host OS[edit]

Use the host operating system's built-in tools to connect to your VPN or use the software provided by your VPN service.

Use a Fail Closed Mechanism[edit]

A general problem with VPNs is that connections often fail to remain open. This means the VPN connection suddenly closes, leaving the user directly connected to the Internet (without first tunneling through the VPN). This is not a Whonix-specific problem. VPN servers and software can occasionally fail without prior notice. Therefore, if the VPN is unreachable or the connection breaks down for whatever reason, in most cases the user will continue to connect to the Internet without the VPN.

One of the key benefits of Whonix is that when a VPN connection fails, protection is still provided by the Tor process. In this instance, the Whonix-Workstation ™ will seamlessly continue to make "direct" connections through Tor. Failure of the VPN tunnel may be inconsequential if a VPN is only used to circumvent Tor censorship. On the other hand, if VPN use is intended to improve security, then it must be configured so that if/when the VPN connection fails, all connections between the outside world and the computer are halted.

If you want to ensure that all network traffic is forced through the VPN, try VPN-Firewall.

(Or if you prefer, install the VPN in Whonix-Gateway ™ instead since it comes with an integrated TUNNEL_FIREWALL feature. However, if you choose this configuration be sure to stay away from the standalone VPN-Firewall when you set up the VPN. This is because the standalone VPN-FIREWALL is not compatible with Whonix-Gateway ™)


Inside Whonix-Gateway ™[edit]

Whonix-Gateway ™ can be configured to connect to a VPN server before Tor with a "fail closed" mechanism. This will block all Tor traffic if the VPN disconnects.

User -> VPN -> Tor -> Internet

VPN Client Choice[edit]

Use OpenVPN.

Using bitmask inside Whonix-Gateway ™ for this use case is unsupported and discouraged. This is because bitmask modifies the firewall. While it might be possible to configure bitmask in Whonix-Gateway ™ safely, documenting the steps needed to reach that point is a TODO. help welcome!

Other VPN clients are unsupported. We are not aware of any sane VPN client choices besides OpenVPN.

Whonix TUNNEL_FIREWALL vs standalone VPN-Firewall[edit]

When applying VPN instructions inside Whonix VMs, do not use the standalone VPN-Firewall. It is not required and is incompatible with the integrated Whonix TUNNEL_FIREWALL feature which is documented below.

VPN Setup[edit]

If you are interested in Hide Tor and Whonix from your ISP (read that page first)... After installing Whonix-Gateway ™, do the following steps before activating Tor in Whonix Setup Wizard.

Preparation[edit]

It is challenging to set up OpenVPN on Whonix with a secure, leak preventing Fail Closed Mechanism. For this reason, it is strongly recommended that users to learn how to set up OpenVPN on Debian stable (currently stretch). The following steps are a simple overview of the process:

  1. Prepare a Debian stable VM.
  2. Install the Debian OpenVPN package: sudo apt-get install openvpn
  3. Research how to set up a VPN using OpenVPN on the command line. [13]
  4. Search for help with general VPN setup in the #VPN Setup chapter or on the TestVPN page. Help is available from various sources, and the VPN provider may also be of assistance.
Firewall Settings[edit]

Modify Whonix User Firewall Settings

Note: If no changes have yet been made to Whonix Firewall Settings, then the Whonix User Firewall Settings File /etc/whonix_firewall.d/50_user.conf appears empty (because it does not exist). This is expected.

If using Qubes-Whonix ™, complete these steps.

Qubes App Launcher (blue/grey "Q") -> Template: whonix-gw-14 -> Whonix User Firewall Settings

If using a graphical Whonix-Gateway ™, complete these steps.

Start Menu -> Applications -> Settings -> User Firewall Settings

If using a terminal-only Whonix-Gateway ™, complete these steps.

sudo nano /etc/whonix_firewall.d/50_user.conf

For more help, press on Expand on the right.

Note: The Whonix Global Firewall Settings File /etc/whonix_firewall.d/30_default.conf contains default settings and explanatory comments about their purpose. By default, the file is opened read-only and is not meant to be directly edited. Below, it is recommended to open the file without root rights. The file contains an explanatory comment on how to change firewall settings.

## Please use "/etc/whonix_firewall.d/50_user.conf" for your custom configuration,
## which will override the defaults found here. When Whonix is updated, this
## file may be overwritten.

See also Whonix modular flexible .d style configuration folders.

To view the file, follow these instructions.

If using Qubes-Whonix ™, complete these steps.

Qubes App Launcher (blue/grey "Q") -> Template: whonix-gw-14 -> Whonix Global Firewall Settings

If using a graphical Whonix-Gateway ™, complete these steps.

Start Menu -> Applications -> Settings -> Global Firewall Settings

If using a terminal-only Whonix-Gateway ™, complete these steps.

nano /etc/whonix_firewall.d/30_default.conf

Add the following settings. You can skip lines that are commented "#" out. Don't use ";" for comments.[14] It is unlikely that you will be required to uncomment or modify either VPN_INTERFACE or LOCAL_NET.[15]

## Make sure Tor always connects through the VPN.
## Enable: 1
## Disable: 0
## DISABELD BY DEFAULT, because it requires a VPN provider.
VPN_FIREWALL=1

## For OpenVPN.
#VPN_INTERFACE=tun0

## Destinations you don not want routed through the VPN.
## 10.0.2.2-10.0.2.24: VirtualBox DHCP
#      LOCAL_NET="\
#         127.0.0.0-127.0.0.24 \
#         192.168.0.0-192.168.0.24 \
#         192.168.1.0-192.168.1.24 \
#         10.152.152.0-10.152.152.24 \
#         10.0.2.2-10.0.2.24 \
#      "

Save.

Reload Firewall[edit]

Reload Whonix-Gateway ™ Firewall.

If you are using Qubes-Whonix ™, complete the following steps.

Qubes App Launcher (blue/grey "Q") -> Whonix-Gateway ™ ProxyVM (commonly named sys-whonix) -> Reload Whonix Firewall

If you are using a graphical Whonix-Gateway ™, complete the following steps.

Start Menu -> Applications -> System -> Reload Whonix Firewall

If you are using a terminal-only Whonix-Gateway ™, run.

sudo whonix_firewall

sudoers configuration[edit]

Open /etc/sudoers.d/tunnel_unpriv in an editor with root rights.

If you are using a graphical Whonix or Qubes-Whonix ™ with KDE, run.

kdesudo kwrite /etc/sudoers.d/tunnel_unpriv

If you are using a graphical Whonix or Qubes-Whonix ™ with XFCE, run.

kdesudo mousepad /etc/sudoers.d/tunnel_unpriv

If you are using a terminal-only Whonix, run.

sudo nano /etc/sudoers.d/tunnel_unpriv

Comment in the following and remove the single hashes (#) in front of all lines, but do not remove the double hashes (##). The edited file should look like this.

tunnel ALL=(ALL) NOPASSWD: /bin/ip
tunnel ALL=(ALL) NOPASSWD: /usr/sbin/openvpn *
Defaults:tunnel !requiretty

Save and exit.

VPN Setup[edit]
Introduction[edit]

The following example uses the free Riseup VPN, because it is known to support TCP, UDP and SSL. However, any preferred VPN can be used.

Update: The Riseup "legacy" VPN may have been discontinued, as it no longer works for the author of these instructions. The Riseup replacement service (Bitmask) has not been tested.

Get VPN Certificate[edit]

TODO: Documentation bug fix required. Won't work without Tor being enabled. You need to get the certificate elsewhere and then File Transfer it into Whonix-Gateway ™.

Look at the riseup VPN help page for RiseupCA.pem and (right-click) download it. Store the certificate in /etc/openvpn/RiseupCA.pem

curl --tlsv1.2 --proto =https https://help.riseup.net/security/network-security/riseup-ca/RiseupCA.pem | sudo tee /etc/openvpn/RiseupCA.pem

VPN Credentials[edit]

For this step, a riseup.net account and Riseup account name is required. Go to https://user.riseup.net/users/riseupusername/vpn to obtain a VPN secret (VPN password). Below, replace "riseupusername" with the actual riseup user name, or just go to https://user.riseup.net, login and click on "VPN".

Open /etc/openvpn/auth.txt in an editor with root rights.

If you are using a graphical Whonix or Qubes-Whonix ™ with KDE, run.

kdesudo kwrite /etc/openvpn/auth.txt

If you are using a graphical Whonix or Qubes-Whonix ™ with XFCE, run.

kdesudo mousepad /etc/openvpn/auth.txt

If you are using a terminal-only Whonix, run.

sudo nano /etc/openvpn/auth.txt

Add the actual user name and password.

riseupusername
vpnsecret

Save and exit.

VPN Credentials[edit]

For this step, a riseup.net account and Riseup account name is required. Go to https://user.riseup.net/users/riseupusername/vpn to obtain a VPN secret (VPN password). Below, replace "riseupusername" with the actual riseup user name, or just go to https://user.riseup.net, login and click on "VPN".

Open /etc/openvpn/auth.txt in an editor with root rights.

If you are using a graphical Whonix or Qubes-Whonix ™ with KDE, run.

kdesudo kwrite /etc/openvpn/auth.txt

If you are using a graphical Whonix or Qubes-Whonix ™ with XFCE, run.

kdesudo mousepad /etc/openvpn/auth.txt

If you are using a terminal-only Whonix, run.

sudo nano /etc/openvpn/auth.txt

Add the actual user name and password.

riseupusername
vpnsecret

Save and exit.

VPN IP Address[edit]

When editing the VPN configuration file the use of DNS hostnames is not supported. This means IP address(s) of the VPN must be used.[16] Therefore, vpn.riseup.net cannot be used, but an IP address such as 198.252.153.226 should be used instead. To discover the IP address, check with the provider or use nslookup on the host. For example, to verify the actual IP address of the vpn.riseup.net DNS server, run.

nslookup vpn.riseup.net

VPN Configuration File[edit]

Open /etc/openvpn/openvpn.conf in an editor with root rights.

If you are using a graphical Whonix or Qubes-Whonix ™ with KDE, run.

kdesudo kwrite /etc/openvpn/openvpn.conf

If you are using a graphical Whonix or Qubes-Whonix ™ with XFCE, run.

kdesudo mousepad /etc/openvpn/openvpn.conf

If you are using a terminal-only Whonix, run.

sudo nano /etc/openvpn/openvpn.conf

Add.

Note: make sure to adjust the remote 198.252.153.226 80 variable in your config (unless you are using nyc.vpn.riseup.net as your VPN service). Replace the IP (198.252.153.226) and port (80) to match your VPN service.

##############################
## VPN provider specific settings ##
##############################
auth-user-pass auth.txt

## using nyc.vpn.riseup.net 80
remote 198.252.153.226 80

ca RiseupCA.pem

remote-cert-tls server

####################################
## TUNNEL_FIREWALL specific settings ##
####################################
client
dev tun0
persist-tun
persist-key

script-security 2
#up "/etc/openvpn/update-resolv-conf script_type=up dev=tun0"
#down "/etc/openvpn/update-resolv-conf script_type=down dev=tun0"

user tunnel
iproute /usr/bin/ip_unpriv

Do not worry about TCP mode on Whonix-Gateway ™. Using the VPN in TCP mode may be possible depending the services provides by your VPN provider, but is not required on Whonix-Gateway ™. The VPN in UDP mode should work just fine. [17] Your pick.

[18] [19]

Save.

DNS Configuration[edit]

DNS configuration, resolvconf, update-resolv-conf or similar is not required for Whonix-Gateway ™. [20]

Configuration Folder Permissions[edit]

Since OpenVPN will be run under user tunnel, that user requires read access to the folder /etc/openvpn.

sudo chown -R tunnel:tunnel /etc/openvpn

sudo chown -R tunnel:tunnel /var/run/openvpn

systemd setup[edit]

Create the OpenVPN systemd service file.

sudo cp /lib/systemd/system/openvpn@.service /lib/systemd/system/openvpn@openvpn.service

Enable the OpenVPN systemd service file.

sudo systemctl enable openvpn@openvpn

Start the OpenVPN systemd service.

sudo systemctl start openvpn@openvpn

Check the OpenVPN systemd service status.

sudo systemctl status openvpn@openvpn

Enable Tor[edit]

Enable Tor using Whonix Setup Wizard.

If you are using Qubes-Whonix ™, complete the following steps.

Qubes App Launcher (blue/grey "Q") -> Whonix-Gateway ™ ProxyVM (commonly named 'sys-whonix') -> Whonix Setup

If you are using a graphical Whonix-Gateway ™, complete the following steps.

Start Menu -> Applications -> System -> Whonix Setup Wizard

If you are using a terminal-only Whonix-Gateway ™, complete the following steps.

sudo whonixsetup

Troubleshooting[edit]

You can skip this troubleshooting chapter unless any difficulties are encountered.

ip_unpriv vs ip-unpriv[edit]

There are two similar, yet distinct projects: standalone VPN-FIREWALL and Whonix TUNNEL_FIREWALL. Although both are alike, there is one difference that might be encountered. For instance, in chapter #VPN Configuration File:

  • Whonix TUNNEL_FIREWALL uses ip_unpriv (underscore)
  • Standalone VPN-FIREWALL uses ip-unpriv (hyphen)


Be sure to use the right version of ip unpriv according to whether the VPN-FIREWALL or Whonix TUNNEL_FIREWALL project is being used.

50_openvpn_unpriv.conf vs 50_openvpn-unpriv.conf[edit]

Like the example above:

  • Whonix TUNNEL_FIREWALL uses /usr/lib/tmpfiles.d/50_openvpn_unpriv.conf ip_unpriv (underscore)
  • Standalone VPN-FIREWALL uses /usr/lib/tmpfiles.d/50_openvpn-unpriv.conf ip-unpriv (hyphen)
Cannot ioctl TUNSETIFF[edit]
 ERROR: Cannot ioctl TUNSETIFF tun: Operation not permitted (errno=1)

In openvpn.conf do not use.

dev tun

Use.

dev tun0
Dev tun Mismatch[edit]

In openvpn.conf do not use.

dev tun

Use.

dev tun0
/run/openvpn/openvpn.status Permission denied[edit]
 Options error: --status fails with '/run/openvpn/openvpn.status': Permission denied

Do not start OpenVPN as root. Do not use sudo openvpn, because this will lead to permission issues. Files in the /run/openvpn folder are owned by root, so they cannot be overwritten by the user tunnel.

debug start[edit]

To start debug, run the following commands concurrently.

sudo /usr/sbin/openvpn --rmtun --dev tun0
sudo /usr/sbin/openvpn --mktun --dev tun0 --dev-type tun --user tunnel --group tunnel
cd /etc/openvpn/
sudo -u tunnel openvpn /etc/openvpn/openvpn.conf

Linux ip link set failed[edit]
 Linux ip link set failed: external program exited with error status: 2

Use ip_unpriv as documented above.

DNS Configuration[edit]

This only applies if resolvconf is used.

Permissions on two directories may need to be manually changed if they are not automatically applied. Check if changes are necessary via the following command.

ls -la /run/resolvconf

If the output lists tunnel as having read / write / execute permissions for both /run/resolvconf and /run/resolvconf/interface, then nothing needs modification. If tunnel is not listed as a group for one or both of these directories, then permissions need to be changed. In that case, run.

sudo chown --recursive root:tunnel /run/resolvconf

Then set the necessary permissions.

sudo chmod --recursive 775 /run/resolvconf

In /run/resolvconf, resolv.conf may or may not be owned by tunnel, depending on whether the systemd service has already started. There is no need to modify permissions on this file, as the permissions will change when the service starts.

Terminology for Support Requests[edit]

Phrases such as "over Tor" are ambiguous. Please do not coin idiosyncratic words or phrases, otherwise this leads to confusion. Please use the same terms that are consistently referenced in documentation, such as:

  • How to Connect to a VPN Before Tor (User -> VPN -> Tor -> Internet).
  • How to Connect to Tor Before a VPN (User -> Tor -> VPN -> Internet).
  • And so on.


Always refer to the connection scheme when requesting support: User -> VPN -> Tor -> Internet or User -> Tor -> VPN -> Internet and so on.

How to Submit a Support Request[edit]

Before submitting a support request for VPN related issues users are encouraged to follow the Free Support Principle when working towards a solution. Whonix developers will use the information provided by the user to determine if the issue is a technical problem (aka bug) and/or configuration error which is a common reason for VPN connectivity issue.

Before Whonix developers will review the support request, the following information must be provided.

  • Steps to reproduce the behavior. For example, list all command that were run up to this point.[21]
  • Actual behavior. (Detailed explanation. Reports stating "VPN does not work" will be rejected.)
  • Expected behavior. (Reports stating "VPN works" will be rejected.)

The following information is also required.

  • All error messages.
  • VPN logs from debug start section. This can be found under Troubleshooting on this page. Make sure to redact all sensitive information.
  • Please answer: Has the VPN configuration been modified aside from the instructions on this page?

Note: Users are encouraged to troubleshoot their VPN issues in an effort to find a solutions. However, if the VPN has been modified with custom configuration options, a favorable outcome is less likely if Whonix developers are not made aware of the modification.

  • Please answer: Is Whonix currently configured to use a second tunnel-link/proxy or bridge?
  • (If applicable) Links to similar issues found on the Whonix forums and/or other offsite forums/resources.

Additional Tweaks / Recommendations / Troubleshooting[edit]

If having problems with the connection / Tor is not fully bootstrapped, please press on expand on the right.

You have may have to manually restart Tor. This is because the VPN may not be ready when Tor is attempting to connect, because the VPN connection initialization takes too long. Due to a bug in Tor, it won't keep trying to connect. To fix this, you may have to manually restart Tor after boot, if whonixcheck reports that Tor is not fully bootstrapped. The same may be necessary if your VPN software or connection temporarily broke down.

To Manually restart Tor:

Reload Tor.

After editing /usr/local/etc/torrc.d/50_user.conf, Tor must be reloaded for changes to take effect.

Note: If Tor does not connect after completing all these steps, then a user mistake is the most likely explanation. Recheck /usr/local/etc/torrc.d/50_user.conf and repeat the steps outlined in the sections above. If Tor then connects successfully, all the necessary changes have been made.

If you are using Qubes-Whonix ™, complete the following steps.

Qubes App Launcher (blue/grey "Q") -> Whonix-Gateway ™ ProxyVM (commonly named 'sys-whonix') -> Reload Tor

If you are using a graphical Whonix-Gateway ™, complete the following steps.

Start Menu -> Applications -> Settings -> Reload Tor

If you are using a terminal-only Whonix-Gateway ™, press on Expand on the right.

Complete the following steps.

Reload Tor.

sudo service tor@default reload

Check Tor's daemon status.

sudo service tor@default status

It should include a a message saying.

Active: active (running) since ...

In case of issues, try the following debugging steps.

Check Tor's config.

sudo -u debian-tor tor --verify-config

The output should be similar to the following.

Sep 17 17:40:41.416 [notice] Read configuration file "/usr/local/etc/torrc.d/50_user.conf".
Configuration was valid

Leak Tests

When you shut down the VPN, neither Tor, nor Whonix-Gateway ™ whonixcheck/apt-get/etc. nor Whonix-Workstation ™ should be able to connect anywhere anymore.

Force Tor to wait for OpenVPN

Create a folder /etc/systemd/system/tor.service.d.

sudo mkdir /etc/systemd/system/tor.service.d

Create a file /etc/systemd/system/tor.service.d/50_user.conf.

Open /etc/systemd/system/tor.service.d/50_user.conf in an editor with root rights.

If you are using a graphical Whonix or Qubes-Whonix ™ with KDE, run.

kdesudo kwrite /etc/systemd/system/tor.service.d/50_user.conf

If you are using a graphical Whonix or Qubes-Whonix ™ with XFCE, run.

kdesudo mousepad /etc/systemd/system/tor.service.d/50_user.conf

If you are using a terminal-only Whonix, run.

sudo nano /etc/systemd/system/tor.service.d/50_user.conf

Add the following content.

[Unit] After=openvpn.service

Save.

At next boot, the Tor daemon will be started after the OpenVPN daemon.

Debugging: [22]

Limitations

  • Only tested with OpenVPN. Most other VPN's have deficiencies anyway.
  • DNS (IP address) of VPN server has to be manually resolved. There is technically no way to automatically resolve DNS without making the setup much more complex. The VPN server's IP address should not be resolved over Tor, because that's what you wanted to hide in the first place. Since outside observers will know, that you are connecting to the VPN IP anyway, it is probably safe to resolve the DNS over clearnet or by asking the VPN provider if they don't already document their IPs on their website anyway.
  • No support for IPv6 yet.

Troubleshooting VPN -> Tor

  • If not connecting, see above to manually restart Tor
  • Check your VPN software's logs.
  • Test if you are able to connect using your VPN

1. Login as user clearnet.

sudo su clearnet

2. Try connecting to check.tpo. Note, at time of writing, it looked like usaip free trial is probably blocking SSL, therefore it might not work.

UWT_DEV_PASSTHROUGH=1 curl --silent --tlsv1.2 --proto =https -H 'Host: check.torproject.org' -k https://138.201.14.212 | grep IP

Should show something along: Your IP address appears to be: xxx.xxx.xxx.xxx

3. Get back to normal user.

exit


Footnotes[edit]

  1. Users in China are unlikely to circumvent government censorship with vanilla bridges, as they are uniformly blocked. That said, anon-connection-wizard configured with the meek-amazon or meek-azure pluggable transport is reported to bypass Chinese censorship in late 2017.
  2. For example, VPNs require a failed closed configuration to prevent DNS leaks.
  3. https://lists.torproject.org/pipermail/tor-talk/2016-July/041757.html
  4. research / document impact for tunnel users if Tor relays hosted at the same tunnel provider
  5. This is because file /lib/systemd/system/openvpn@openvpn.service.d/50_unpriv.conf checks the following condition
    ConditionPathExists=!/var/run/qubes-service/whonix-template
    

    Which means, if file /var/run/qubes-service/whonix-template exists, which is the case in Whonix TemplateVMs, the openvpn@openvpn service will not be started.

  6. http://tor.stackexchange.com/a/114/80
  7. https://lists.torproject.org/pipermail/tor-talk/2016-July/041753.html
  8. 8.0 8.1 All traffic generated by the host and all applications running on the host. For example, Firefox, NTP, and anything else. This also includes traffic generated by Whonix.
  9. https://github.com/leapcode/bitmask_client/issues/1009
  10. At the time of writing Debian 9 stretch was the stable release version.
  11. Because Whonix-Gateway ™ does not require any clearnet DNS anyhow.
    • Check, that your VPN-Gateway is fully functional. Test connectivity from inside the VPN-Gateway.
    • Add a non-Whonix VM behind your VPN-Gateway. For example, add a debian based AppVM behind your VPN-Gateway. Figure out if the VPN-Gateway works at all before involving Whonix.
  12. Only proceed if this is successful. Do not post support requests regarding these instructions before completing this basic exercise.
  13. That config file is a bash fragment.
  14. If the term "comment" is unfamilar to you, See: How to comment/uncomments lines in a configuration file.
  15. Many VPN service providers include DNS hostnames in their configuration files. The hostnames typically include the providers name followed by (.net, .com, .ch, .pw).
  16. The Tor software cannot transport UDP yet, but it does not have to in this case. (Reference: Tor#UDP.) Since the VPN connects over clearnet, UDP should just work as usual. Once the VPN is functional, Tor will have no issue to connect using it (without "knowing" it is over a VPN).
  17. The /usr/bin/ip_unpriv wrapper script is being provided by the usabilty-misc package. The /etc/sudoers.d/tunnel_unpriv wrapper script is being provided by the usabilty-misc package. The /lib/systemd/system/openvpn@openvpn.service.d/50_unpriv.conf wrapper script is being provided by the usabilty-misc package.
  18. We must run OpenVPN as user 'tunnel', because that is the only user besides user clearnet that will be allowed to establish external connections when using Whonix Firewall setting VPN_FIREWALL=1.
  19. Because Whonix-Gateway ™ by default has no and needs no system DNS for its own traffic. See Whonix-Gateway System DNS if you would like to read an explanation why that is so.
  20. To list previous commands, run.
    history
  21. Reload systemd. sudo systemctl daemon-reload Check Tor service status. sudo systemctl status tor sudo systemctl status tor@default It should list the drop-in file /etc/systemd/system/tor.service.d/50_user.conf.

No user support in comments. See Support.

Comments will be deleted after some time. Specifically after comments have been addressed in form of wiki enhancements. See Wiki Comments Policy.


Add your comment
Whonix welcomes all comments. If you do not want to be anonymous, register or log in. It is free.


Random News:

Are you proficient with iptables? Want to contribute? Check out possible improvements to iptables. Please come and introduce yourself in the development forum.


https | (forcing) onion

Share: Twitter | Facebook

This is a wiki. Want to improve this page? Help is welcome and volunteer contributions are happily considered! Read, understand and agree to Conditions for Contributions to Whonix ™, then Edit! Edits are held for moderation.

Copyright (C) 2012 - 2019 ENCRYPTED SUPPORT LP. Whonix ™ is a trademark. Whonix ™ is a licensee of the Open Invention Network. Unless otherwise noted, the content of this page is copyrighted and licensed under the same Freedom Software license as Whonix ™ itself. (Why?)

By using our website, you acknowledge that you have read, understood and agreed to our Privacy Policy, Cookie Policy, Terms of Service, and E-Sign Consent. Whonix ™ is provided by ENCRYPTED SUPPORT LP. See Imprint.