Connecting to Tor before a VPN
From Whonix
< Tunnels
User
→ Tor
→ VPN
→ Internet
Introduction[edit]
Before combining Tor with other tunnels, be sure to read and understand the risks!
Advertisement:
Too difficult to set up? Provider specific automation can be created for you by the lead developer of Whonix ™. Send reasonable price suggestions. Get in contact.
By design, a VPN routes all your applications -- those without any proxy settings -- through the VPN. This may be undesirable as explained below; for example, it increases the threat of identity correlation. To circumvent this possibility, only use this Whonix-Workstation ™ for particular applications that should be routed through the tunnel-link. Refer to the Multiple Whonix-Workstation ™ wiki chapter for further instructions.
Security Precautions[edit]
Prevent Bypassing of the Tunnel-Link[edit]
- Apply the following steps to avoid unexpected results such as broken connectivity and/or traffic bypassing the tunnel-link and only going through Tor.
- Qubes-Whonix ™ exception: There is one tunnel configuration where Qubes-Whonix ™ users are better placed. When a separate tunnel-link VM is used between
anon-whonix
andsys-whonix
(anon-whonix
→Tunnel-link
→sys-whonix
), these connections will fail without the following modifications.
Introduction
Disabling stream isolation will prevent bypassing of the tunnel-link. By default, many pre-installed applications are configured for Stream Isolation in Whonix ™. These specific applications are configured to use Tor SocksPorts, instead of Tor's TransPort.
All applications which are configured to use Tor SocksPorts are not tunneled through the tunnel-link, but instead they are only tunneled through Tor. The reason is the following configuration does not touch local connections to 10.152.152.10, which is the Whonix-Gateway ™. Therefore, all Tor Browser proxy settings must be removed if attempting to tunnel Tor Browser via the route User
→ Tor
→ Tunnel-link
→ Internet
(or similar); see below for instructions.
Deactivate uwt Wrappers
The following instructions permanently deactivate all uwt wrappers and remove stream isolation for uwt-wrapped applications system-wide. Consequently, all uwt-wrapped applications revert to the default system networking configuration.
For more granular control of uwt wrapper deactivation, see: Deactivate uwt Stream Isolation Wrapper.
Open file /etc/uwt.d/50_user.conf
in an editor with root rights.
This box uses sudoedit
for better security [archive]. This is an example and other tools can also achieve the same goal. If this example does not work for you or if you are not using Whonix ™, please refer to this link.
sudoedit /etc/uwt.d/50_user.conf
Add.
uwtwrapper_global="0"
Save and exit.
Tor Browser Remove Proxy Settings
Introduction
This configuration results in Tor Browser no longer using proxy settings. With no proxy set, Tor Browser uses the (VM) system's default networking. This is identical to any other application inside Whonix-Workstation ™ that has not been explicitly configured to use Tor via socks proxy settings or a socksifier. This setting is also called transparent torification. [1] [2]
Note: This action will break both Stream Isolation for Tor Browser and Tor Browser's tab isolation by socks user name [archive]. This worsens the web fingerprint and leads to pseudonymous (not anonymous) connections. To mitigate these risks, consider using More than one Tor Browser in Whonix ™, or preferably Multiple Whonix-Workstation ™.
To enable transparent torification (no proxy setting), set the TOR_TRANSPROXY=1
environment variable. There are several methods, but the simplest is the /etc/environment Method.
Note: Choose only one method to enable transparent torification.
For other methods with finer granulated settings, please press on Expand on the right.
Command Line Method
Navigate to the Tor Browser folder.
cd ~/tor-browser_en-US
Every time Tor Browser is started, run the following command to set the TOR_TRANSPROXY=1
environment variable.
TOR_TRANSPROXY=1 ./start-tor-browser.desktop
start-tor-browser Method
This only applies to a single instance of the Tor Browser folder that is configured. This method may not persist when Tor Browser is updated.
Find and open start-tor-browser in the Tor Browser folder with an editor.
This is most likely found in ~/tor-browser_en-US/Browser/start-tor-browser below #!/usr/bin/env bash.
Set.
export TOR_TRANSPROXY=1
/etc/environment Method
This will apply to the whole environment, including any possible custom locations of Tor Browser installation folders. [3]
Open file /etc/environment
in an editor with root rights.
This box uses sudoedit
for better security [archive]. This is an example and other tools can also achieve the same goal. If this example does not work for you or if you are not using Whonix ™, please refer to this link.
sudoedit /etc/environment
Add the following line.
TOR_TRANSPROXY=1 ## newline at the end
Save and reboot.
Tor Browser Settings Changes
This step is required since Tor Browser 10. [4]
1. Tor Browser → URL bar → Type: about:config
→ Press Enter
key. → search for and modify
2. network.dns.disabled
→ set to false
3. extensions.torbutton.launch_warning
→ set to false
Undo
Reverting this change is undocumented. Simply unsetting that environment variable will not work due to Tor Browser limitations. The easiest way to undo this setting is to install a fresh instance of Tor Browser (please contribute to these instructions)!
Ignore Tor Button's Open Network Settings
Whonix ™ has disabled the Open Network Settings...
menu option in Tor Button. Read the footnote for further information. [5]
Deactivate Miscellaneous Proxy Settings
On the Stream Isolation page, there is a list of applications that are pre-configured to use socks proxy settings via application configuration files. To disable this the Whonix ™ system default must be removed from the application's settings.
TODO: document and expand.
Remove proxy settings for APT repository files.
1. If you previously onionized any repositories, that has to be undone; see Onionizing Repositories.
2. Remove any mention of tor+
in file /etc/apt/sources.list
(if it was previously configured; that file is empty by default in Whonix ™ / Kicksecure) or any file in folder /etc/apt/sources.list.d
.
3. Open file /etc/apt/sources.list /etc/apt/sources.list.d/*
in an editor with root rights.
This box uses sudoedit
for better security [archive]. This is an example and other tools can also achieve the same goal. If this example does not work for you or if you are not using Whonix ™, please refer to this link.
sudoedit /etc/apt/sources.list /etc/apt/sources.list.d/*
4. Remove any mention of tor+
.
The process of removing proxy settings from APT repository files is now complete.
Remove proxy settings for Tor Browser Downloader by Whonix ™.
Open file /etc/torbrowser.d/50_user.conf
in an editor with root rights.
This box uses sudoedit
for better security [archive]. This is an example and other tools can also achieve the same goal. If this example does not work for you or if you are not using Whonix ™, please refer to this link.
sudoedit /etc/torbrowser.d/50_user.conf
TB_NO_TOR_CON_CHECK=1 CURL_PROXY="--fail"
Save.
For some applications, this is impossible:
These applications can only talk to Tor Onion Services directly and cannot be configured to use the system default. Therefore you can only deactivate sdwdate and/or not use applications like OnionShare and Ricochet IM.
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.
Instructions below include a fail closed mechanism.
VPN Client Choice[edit]
It is recommended to utilize OpenVPN. Other VPN clients are unsupported because we are unaware of any sane VPN client choice besides OpenVPN.
Using Bitmask VPN [archive] for this use case is not possible. [8] In other words, you cannot use user
→ Tor
→ bitmask
→ Internet
. [9]
Set Up Tor before a VPN (User → Tor → VPN → Internet)[edit]
Introduction[edit]
Two configurations are available:
- Qubes-Whonix ™ users have the option of a Separate VPN-Gateway, but could also use Inside Whonix-Workstation ™ instructions.
- Non-Qubes-Whonix ™ users should prefer Inside Whonix-Workstation ™ instructions.
Separate VPN-Gateway[edit]
Qubes-Whonix ™ only; Non-Qubes-Whonix ™ is unsupported.
This configuration has a separate VPN-Gateway between Whonix-Gateway ™ and Whonix-Workstation ™: Whonix-Workstation ™
→ VPN-Gateway
→ Whonix-Gateway ™
.
User
→ Tor
→ VPN
→ Internet
1. Clone a Template. For example, clone debian-11
and name the new template clone debian-11-vpn
. [10]
Qube Manager
→ debian-11
→ Clone qube
→ Enter name for Qube clone:
debian-11-vpn
→ Press: OK
2. Create a new ProxyVM based on the newly cloned template.
Name the VM VPN-Gateway and set the Whonix-Gateway ™ ProxyVM (sys-whonix
) as NetVM. Make sure to check [✔] the box for "provides network".
Qube Manager
→ Qube
→ Create new qube
- Name and label:
VPN-Gateway
(Set the preferred color) - Type:
Qube based on a template (AppVM)
- Template:
debian-11-vpn
- Networking:
sys-whonix
- Advanced: [
✔
] Provides network - Press:
OK
3. Set up the VPN-Gateway as per Qubes VPN Documentation [archive].
It is recommended to follow the Set up a ProxyVM as a VPN gateway using iptables and CLI scripts instructions because this prevents clearnet leaks if/when the VPN breaks down.
Note:
- Without configuring a fail closed configuration, all traffic originating from the Whonix-Workstation ™ App Qube (
anon-whonix
) would only be forced through Tor if/when the VPN connection breaks down (User
→Tor
→Internet
). - UDP-style VPN connections are incompatible with Tor because it requires the VPN to be configured to use TCP. [11] This requires adding
proto tcp
to the VPN configuration file/rw/config/vpn/openvpn-client.ovpn
. Nearly all VPN providers support this configuration.
4. Check the VPN-Gateway is fully functional.
Test connectivity from inside the VPN-Gateway as per Qubes VPN Documentation [archive].
5. Recommended: In Whonix-Workstation ™ (anon-whonix
), apply instructions from the Prevent Bypassing of the Tunnel-Link section.
6. Optional: It is recommended to run the related Leak Tests.
The VPN-Gateway configuration is complete.
Notes:
- No DNS configuration is required when using a separate VPN Gateway and system DNS should work out of the box. [12]
- For troubleshooting, see footnote. [13]
- Whonix ™ user forum discussion: Set up a VPN in ProxyVM over sys-whonix [archive] [14]
- The following warning will appear when using Tor Browser and is expected (see technical footnote): [15]
Something Went Wrong! Tor is not working in this browser.
Inside Whonix-Workstation ™[edit]
This configuration will connect to the VPN using your preferred software inside the (Whonix ™-)Workstation.
Note that UDP-style VPN connections are incompatible with Tor; the VPN must be configured to use TCP. [16] This requires adding proto tcp
to the VPN configuration file /etc/openvpn/openvpn.conf
. Nearly all VPN providers support this configuration.
User
→ Tor
→ VPN
→ Internet
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.
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 to learn how to set up OpenVPN on Debian stable (currently bullseye). The following steps are a simple overview of the process:
- Prepare a Debian bullseye VM.
- Install the Debian OpenVPN package:
sudo apt install openvpn
. - Research how to set up a VPN using OpenVPN on the command line. [17]
- Search for help with general VPN setup in the VPN Setup section or in the VPN Tunnel Setup Examples chapter. Help is available from various sources, and the VPN provider may also be of assistance.
Prerequisite Knowledge[edit]
Before proceeding, it is strongly recommended to read and understand the Whonix Debian Packages chapter.
Firewall Settings[edit]
Modify Whonix-Workstation ™ 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.
In Whonix-Workstation ™ App Qube. Make sure folder /usr/local/etc/whonix_firewall.d
exists.
sudo mkdir -p /usr/local/etc/whonix_firewall.d
Qubes App Launcher (blue/grey "Q")
→ Whonix-Workstation ™ App Qube (commonly called anon-whonix)
→ Whonix ™ User Firewall Settings
If using a graphical Whonix-Workstation ™, complete these steps.
Start Menu
→ Applications
→ System
→ User Firewall Settings
If using a terminal-only Whonix-Workstation ™, complete these steps.
Open /usr/local/etc/whonix_firewall.d/50_user.conf
with root rights.
sudoedit /usr/local/etc/whonix_firewall.d/50_user.conf
For more help, press on Expand on the right.
Note: This is for informational purposes only! Do not edit /etc/whonix_firewall.d/30_whonix_workstation_default.conf
.
The Whonix ™ Global Firewall Settings File /etc/whonix_firewall.d/30_whonix_workstation_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 {{project_name}} is updated, this ## file may be overwritten.
Also see: 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-ws-16
→ Whonix Global Firewall Settings
If using a graphical Whonix-Workstation ™, complete these steps.
Start Menu
→ Applications
→ Settings
→ Global Firewall Settings
If using a terminal-only Whonix-Workstation ™, complete these steps.
In Whonix-Workstation ™, open the whonix_firewall configuration file in an editor.
nano /etc/whonix_firewall.d/30_whonix_workstation_default.conf
Add the following settings.
WORKSTATION_FIREWALL=1 TUNNEL_FIREWALL_ENABLE=true
Save.
Reload Firewall[edit]
Reload Whonix-Workstation ™ Firewall.
If you are using Qubes-Whonix ™, complete the following steps.
Qubes App Launcher (blue/grey "Q")
→ Whonix-Workstation ™ App Qube (commonly named anon-whonix)
→ Reload Whonix ™ Firewall
If you are using a graphical Whonix-Workstation ™, complete the following steps.
Start Menu
→ Applications
→ System
→ Reload Whonix ™ Firewall
If you are using a terminal-only Whonix-Workstation ™, run.
sudo whonix_firewall
sudoers Configuration[edit]
Open file /etc/sudoers.d/tunnel_unpriv
in an editor with root rights.
This box uses sudoedit
for better security [archive]. This is an example and other tools can also achieve the same goal. If this example does not work for you or if you are not using Whonix ™, please refer to this link.
sudoedit /etc/sudoers.d/tunnel_unpriv
Edit the file so the text looks looks like the following code block.
Note: This might include removing comments (#) and adding text. Do not remove the lines with double hashes (##).
tunnel ALL=(ALL) NOPASSWD: /bin/ip tunnel ALL=(ALL) NOPASSWD: /usr/sbin/openvpn * Defaults:tunnel !requiretty Defaults:tunnel env_keep += script_type Defaults:tunnel env_keep += dev
Save and exit.
VPN Setup[edit]
Update: The Riseup "legacy" VPN appears to have been discontinued. The Riseup replacement service (Bitmask) has not been tested. If you do not have a Riseup invite code then tailor the instructions in this section to work with any other OpenVPN provider.
Introduction[edit]
The following example uses the Riseup VPN, because it is known to support TCP, UDP and SSL. However, any preferred VPN provider can be used.
Get VPN Certificate[edit]
- Inspect the Riseup Certificate Authority [archive] page and download (right-click) the Riseup CA certificate [archive]. [18]
- Advanced users can optionally verify the Riseup CA certificate [archive] before storing it. [19]
- Store the certificate in
/etc/openvpn/RiseupCA.pem
:
curl --tlsv1.3 --proto =https https://help.riseup.net/security/network-security/riseup-ca/RiseupCA.pem | sudo tee /etc/openvpn/RiseupCA.pem
VPN Credentials[edit]
For this example, for this step, a Riseup account is required. Unfortunately, the former free VPN service is no longer available. [20] This means to create an account you will need an "invite code" from a current Riseup user.
- If you have one:
- 1. Navigate to the account creation page [archive] in Tor Browser.
- 2. Enter the invite code.
- 3. Choose a username unrelated to your real identity.
- 4. Enter a strong password.
- If you do not have an invite code:
- Please do not ask Whonix ™ developers or forums for an invite code because none will be available.
- Instead tailor the instructions in this section to work with any other OpenVPN provider.
1. Open file /etc/openvpn/auth.txt
in an editor with root rights.
This box uses sudoedit
for better security [archive]. This is an example and other tools can also achieve the same goal. If this example does not work for you or if you are not using Whonix ™, please refer to this link.
sudoedit /etc/openvpn/auth.txt
2. Add.
Note: Replace riseupusername
with the actual Riseup user name and replace vpnsecret
with the actual user name and password or just go to https://account.riseup.net/ [archive], log in and click on "VPN".
riseupusername vpnsecret
3 . 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.[21] 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]
1. Open file /etc/openvpn/openvpn.conf
in an editor with root rights.
This box uses sudoedit
for better security [archive]. This is an example and other tools can also achieve the same goal. If this example does not work for you or if you are not using Whonix ™, please refer to this link.
sudoedit /etc/openvpn/openvpn.conf
2. Add.
Note: It is necessary to adjust the remote 198.252.153.226 80 variable in the configuration below unless you are using nyc.vpn.riseup.net as the 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 ############################################ ## Connecting to Tor before a VPN specific settings # ############################################ proto tcp
3. Save.
Install resolvconf[edit]
Update the package lists.
sudo apt update
Install resolvconf
. [24]
sudo apt install resolvconf
Users preferring not to install resolvconf should read the footnotes. [25]
DNS Configuration[edit]
1. Open file /usr/lib/tmpfiles.d/50_openvpn_unpriv.conf
in an editor with root rights.
This box uses sudoedit
for better security [archive]. This is an example and other tools can also achieve the same goal. If this example does not work for you or if you are not using Whonix ™, please refer to this link.
sudoedit /usr/lib/tmpfiles.d/50_openvpn_unpriv.conf
2. Add. [26]
d /run/resolvconf 0775 root tunnel - - d /run/resolvconf/interface 0775 root tunnel - -
Save the file.
3. Adjust permissions. [26]
sudo chown --recursive root:tunnel /run/resolvconf
sudo chmod --recursive 775 /run/resolvconf
4. Open file /etc/resolvconf/run/interface/original.resolvconf
in an editor with root rights.
This box uses sudoedit
for better security [archive]. This is an example and other tools can also achieve the same goal. If this example does not work for you or if you are not using Whonix ™, please refer to this link.
sudoedit /etc/resolvconf/run/interface/original.resolvconf
Comment everything out by adding a # in front of all entries. Alternatively, empty or delete that file. [27]
Save and exit.
Additional Setup[edit]
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 /run/openvpn
systemd Setup[edit]
1. Create the OpenVPN systemd service file.
sudo cp /lib/systemd/system/openvpn@.service /lib/systemd/system/openvpn@openvpn.service
2. Enable the OpenVPN systemd service file.
sudo systemctl enable openvpn@openvpn
3. Start the OpenVPN systemd service.
sudo systemctl start openvpn@openvpn
4.Check the OpenVPN systemd service status.
sudo systemctl status openvpn@openvpn
resolvconf Adjustments[edit]
Restart resolvconf
. [28]
sudo service resolvconf restart
Verify DNS Settings[edit]
1. Open the /etc/resolv.conf
file.
sudo cat /etc/resolv.conf
2. Check the current settings.
It should not include the following setting; this is the standard Whonix ™ DNS server.
nameserver 10.152.152.10
It should also not include the following settings; these are the standard Qubes DNS servers.
nameserver 10.137.3.1 nameserver 10.137.3.254
3. Confirm it only includes the DNS server of your DNS provider.
For example.
nameserver 10.5.0.1
systemcheck[edit]
systemcheck cannot work in this configuration out of the box. Perform the following steps to unbreak it.
1. Open file /etc/systemcheck.d/50_user.conf
in an editor with root rights.
This box uses sudoedit
for better security [archive]. This is an example and other tools can also achieve the same goal. If this example does not work for you or if you are not using Whonix ™, please refer to this link.
sudoedit /etc/systemcheck.d/50_user.conf
2. Add the following text.
systemcheck_skip_functions+=" check_tor_bootstrap " systemcheck_skip_functions+=" check_tor_socks_port_reachability " systemcheck_skip_functions+=" check_tor_socks_port " systemcheck_skip_functions+=" check_tor_trans_port " systemcheck_skip_functions+=" check_stream_isolation " systemcheck_skip_functions+=" download_whonix_news " ## {{ Alternative to disabling check_tor_trans_port. ## Make the Tor TransPort test work by simulating the Tor SocksPort test succeeded. #CHECK_TOR_RESULT_SOCKS_PORT=0 ## Do not warn if Tor was not detected. (Will be the VPN.) #SYSTEMCHECK_NO_EXIT_ON_TRANS_PORT_DETECTION_FAILURE=1 ## }} ## {{ Alternative to download_whonix_news. ## Download news through system default. #CURL_PROXY_WHONIX_NEWS="--fail" ## }}
3. Save the file.
Qubes-specific[edit]
1. When using an App Qube, persistent changes require the Qubes bind dirs mechanism.
sudo mkdir /rw/config/qubes-bind-dirs.d
2. Open file /rw/config/qubes-bind-dirs.d/50_user.conf
in an editor with root rights.
This box uses sudoedit
for better security [archive]. This is an example and other tools can also achieve the same goal. If this example does not work for you or if you are not using Whonix ™, please refer to this link.
sudoedit /rw/config/qubes-bind-dirs.d/50_user.conf
3. Add the following content.
binds+=( '/etc/sudoers.d/tunnel_unpriv' ) binds+=( '/etc/openvpn' ) binds+=( '/lib/systemd/system/openvpn@openvpn.service' ) binds+=( '/etc/systemd/system/multi-user.target.wants/openvpn@openvpn.service' )
TODO: This does not work yet because the files need to exist first.
/usr/lib/qubes/bind-dirs.sh umount
/usr/lib/qubes/bind-dirs.sh
Test[edit]
1. Test the ping functionality.
Utilize a suitable IP address such as Google's DNS server or an alternative server of your choice.
ping 8.8.8.8
2. Test DNS to check it correctly resolves a suitable domain.
Utilize check.torproject.org
or an alternative server of your choice.
nslookup check.torproject.org
3. Test DNS and output IP address.
whonixcheck_skip_functions="" \ CHECK_TOR_RESULT_SOCKS_PORT=0 \ WHONIXCHECK_NO_EXIT_ON_TRANS_PORT_DETECTION_FAILURE=1 \ whonixcheck --function check_tor_trans_port
Additional Information[edit]
The procedure is complete. If you have any issues, refer to the Troubleshooting section below. Once the setup is functional, it is recommended to perform Leak Tests.
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 the VPN Configuration File section:
- Whonix TUNNEL_FIREWALL uses ip_unpriv (underscore)
- Standalone VPN-FIREWALL uses ip-unpriv (hyphen)
Be sure to use the right version of ip unpriv depending on whether VPN-FIREWALL or Whonix TUNNEL_FIREWALL is in use.
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
To avoid permission issues, do not:
- start OpenVPN as root; or
- use
sudo openvpn
.
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 successively.
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 in use.
Permissions on two directories may need to be manually changed if they are not automatically applied. Check if changes are necessary with 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 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:
- Connect to a VPN Before Tor (
User
→VPN
→Tor
→Internet
). - Connect to Tor Before a VPN (
User
→Tor
→VPN
→Internet
). - And so on.
Always refer to the connection scheme when requesting support, such as:
User
→VPN
→Tor
→Internet
, orUser
→Tor
→VPN
→Internet
.
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 to work towards a solution. Whonix ™ developers will use the reported information to determine if the issue is a technical problem (legitimate bug) and/or configuration error which is a common cause of VPN connectivity issues.
Before Whonix ™ developers will review the support request, the following information is required:
- Steps to reproduce the behavior. For example, list all command that were run up to this point. [29]
- A detailed explanation of actual behavior. Incomplete reports stating the "VPN does not work" will be rejected.
- Expected behavior. Reports simply stating "VPN works" will be rejected.
The following technical information is also necessary:
- All error messages.
- VPN logs from the debug start section:
- This can be found using the Troubleshooting section on this page.
- Redact all sensitive information such as VPN server IP addresses; see Never Post Full System Logs or Configuration Files for a rationale.
- VPN logs are required because a configuration error and/or mismatch may not produce a noticeable error.
- Confirmation of whether the VPN configuration has been modified aside from the instructions on this page.
- Note: Users are encouraged to troubleshoot their VPN issues in an effort to find a solution. However, if the VPN was modified with custom configuration options, a favorable outcome is less likely if this information is not shared with Whonix ™ developers.
- Confirmation of whether Whonix ™ is configured to use a second tunnel-link/proxy or bridge.
- If applicable, whether links to similar issues were found on the Whonix ™ forums [archive] and/or other offsite forums/resources.
Leak Tests[edit]
Introduction[edit]
It is important to verify the network traffic configuration enforces User
→ Tor
→ VPN
→ Internet
and not only User
→ Tor
→ Internet
. Therefore, it is recommended to run the following related leak tests inside Whonix-Workstation ™. Test Tor Browser, a uwt wrapper deactivated application, as well as a regular application for leaks.
Regular Application Test[edit]
Use curl
without pre-configured stream isolation.
UWT_DEV_PASSTHROUGH=1 curl --silent --tlsv1.3 --proto =https https://check.torproject.org | grep IP
The output should show something similar to: Your IP address appears to be: xxx.xxx.xxx.xxx
It should also list the VPN's IP address.
uwt-wrapped Application Test[edit]
Connect to check.torproject.org
.
curl --silent --tlsv1.3 --proto =https https://check.torproject.org | grep IP
Browser IP Test[edit]
This test can be skipped if Tor Browser will not be used through the VPN.
If everything was configured correctly, test the setup. Open https://check.torproject.org [archive]
in Tor Browser. It will state "You are not using Tor." and the VPN's IP address will be visible. In fact this means the VPN was tunneled through Tor first because Whonix-Workstation ™ can not make any non-Tor connections by design (everything is tunneled over Tor).
DNS Leak Test[edit]
- DNS leak test.com [archive]
- DNS Leak Test [archive]
- Perfect Privacy VPN: DNS leak test [archive]
- Anonymster DNS leak test [archive]
- PureVPN DNS leak test [archive]
- Surfshark DNS leak test [archive]
Other Leak Tests[edit]
Advanced users can also run a host of additional, general leak tests that are unrelated to tunneling. However, these are more difficult to perform and are targeted at developers rather than general users. For further information, see: Leak Tests.
Footnotes[edit]
- ↑ This term was coined in context of a Tor Transparent Proxy [archive] (.onion [archive]). It acts as a simple gateway that routes all connections through Tor, but does not provide Stream Isolation.
- ↑ If these settings are changed, Tor Button would previously show a red sign and state "Tor Disabled" when a mouse was hovered over it.
- ↑ Unless this environment variable is manually unset before starting Tor Browser.
- ↑
- ↑ The regular Tor Browser Bundle from The Tor Project (without Whonix ™) allows networking settings to changed inside Tor via the
Open Network Settings
menu option. It has the same effect as editing Tor's config file torrc. In Whonix ™, the environment variableexport TOR_NO_DISPLAY_NETWORK_SETTINGS=1
has been set [archive] to disable theTor Browser
→Open Network Settings...
menu item. It is not useful and confusing to have in the Whonix-Workstation ™ because:- In Whonix ™, there is only limited access to Tor's control port (see Dev/CPFP for more information).
- For security reasons, Tor must be manually configured in /usr/local/etc/torrc.d/50_user.conf on Whonix-Gateway ™, and not from Whonix-Workstation ™ (see VPN/Tunnel support for more information).
- ↑
TB_NO_TOR_CON_CHECK=1
needs to be set because there is no filtered Tor ControlPort access when Whonix ™ tunnel firewall is enabled, which would break tb-updater's Tor connectivity check. - ↑
By tb-updater default, if unset, variable
CURL_PROXY
will be dynamically set to a Tor SocksPort on Whonix-Gateway ™. For example toCURL_PROXY="--proxy socks5h://user:password@10.137.6.1:9115"
.
By utilizing a curl parameter we are using anyhow --CURL_PROXY="--fail"
-- the environment variable can be disabled even if it is technically still set. This will result in downloading via the system's default networking. - ↑ https://0xacab.org/leap/bitmask-vpn [archive]
- ↑ Previously Bitmask did not support Tor. Broken link: https://github.com/leapcode/bitmask_client/issues/1009 [archive]
- ↑
At the time of writing Debian 11
bullseye
was the stable release version. - ↑ See UDP.
- ↑ This is because a properly configured Qubes VPN-Gateway will be able to resolve DNS.
- ↑
- Check the VPN-Gateway is fully functional. Test connectivity from inside the VPN-Gateway.
- When testing the VPN connection do not add any VMs that have been previously used for non-anonymous activities behind the VPN-Gateway. This will burn the VPN, making it unsuitable for use with Whonix ™!
- Create a fresh, newly created VM if intending to use a non-Whonix ™ VM behind the VPN-Gateway for testing purposes.
- ↑
- Qubes users mailing list discussion: https://groups.google.com/d/msgid/qubes-users/5759D76E.8000401%40riseup.net [archive]
- Qubes development ticket: https://github.com/QubesOS/qubes-issues/issues/2060 [archive]
- ↑ This is because Tor Browser can no longer access Tor's ControlPort (onion-grater) on Whonix-Gateway ™.
- ↑ See UDP.
- ↑ Only proceed if this is successful. Please do not post support requests regarding these instructions before completing this basic exercise.
- ↑ Riseup notes:
Every CA (certificate authority) has a file that is distributed publicly. This file, called a “CA certificate”, is used by your local program to confirm the identity of servers you connect with.
- ↑ If verification is not performed, then it is impossible to know the correct certificate was downloaded and that connections are secure.
- ↑ Previously a VPN secret (VPN password) and username could be registered.
- ↑ Many VPN service providers include DNS hostnames in their configuration files. The hostnames typically include the providers name followed by (.net, .com, .ch, .pw).
- ↑
- The /usr/bin/ip_unpriv [archive] wrapper script is provided by the usabilty-misc [archive] package.
- The /etc/sudoers.d/tunnel_unpriv [archive] wrapper script is provided by the usabilty-misc [archive] package.
- The /lib/systemd/system/openvpn@openvpn.service.d/50_unpriv.conf [archive] wrapper script is provided by the usabilty-misc [archive] package.
- ↑ It is necessary to run OpenVPN as user 'tunnel' because that is the only user besides user
clearnet
that is allowed to establish external connections when using Whonix ™ Firewall setting VPN_FIREWALL=1. - ↑
/etc/openvpn/update-resolv-conf
usesresolvconf
.resolvconf
needs to be installed for the lines beginning with script-security, up, and down to function properly. - ↑
1. In the
/etc/openvpn/openvpn.conf
file, change the following text.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"
To the following. Remove or comment out the lines beginning with "up" and "down", and change the 2 to a 1.
script-security 1
2. Open file
/etc/resolv.conf
in an editor with root rights.This box uses
sudoedit
for better security [archive]. This is an example and other tools can also achieve the same goal. If this example does not work for you or if you are not using Whonix ™, please refer to this link.sudoedit /etc/resolv.conf
3. Comment out the nameserver.
#nameserver 10.152.152.10
4. Add the VPN provider's DNS server.
## Riseup.net OpenVPN DNS server nameserver 172.27.100.1
If Riseup is not in use, replace 172.27.100.1 with the virtual LAN IP address of the VPN provider's DNS server. If unsure, the VPN provider might provide it. To try to infer it, run
sudo route
after successfully connecting to the VPN. The first destination default gateway should also function as a DNS server.5. Save and exit.
6. Optional: Prevent
/etc/resolv.conf
being overwritten by other packages like DHCP orresolvconf
.Run.
sudo chattr +i /etc/resolv.conf
In order to revert this change, use -i.
Ignore the
/etc/resolv.conf
instructions below. - ↑ 26.0 26.1 This is removeable since Whonix ™ 14 because it was merged in the
usablity-misc
package. - ↑ This is done to prevent the old DNS server being used. For further discussion of this issue, see: https://github.com/adrelanos/vpn-firewall/issues/16 [archive]
- ↑
This ensures changes in
/etc/resolvconf/run/interface/original.resolvconf
from the DNS Configuration section take effect. - ↑
To list previous commands, run.
history
- ↑ 30.0 30.1
In the absence of functional system DNS, an alternative is to just test TCP.
The IP
116.202.120.181
might change. To discover the current one, run the following command inside a VM with functional system DNS. (Ideally inside a Whonix-Workstation ™.)nslookup check.torproject.org
- ↑
UWT_DEV_PASSTHROUGH=1 curl --silent --tlsv1.3 --proto =https -H 'Host: check.torproject.org' -k https://116.202.120.181 | grep IP
- ↑
curl --silent --tlsv1.3 --proto =https -H 'Host: check.torproject.org' -k https://116.202.120.181 | grep IP
Whonix ™ is Supported by Evolution Host DDoS Protected VPS. Stay private and get your VPS with Bitcoin or Monero.
100px | |
Fosshost | About Advertisements |
Search engines: YaCy | Qwant | ecosia | MetaGer | peekier | Whonix ™ Wiki
Subscribe to Whonix ™ Newsletter.
Priority Support | Investors | Professional Support
Whonix ™ | © ENCRYPTED SUPPORT LP | Freedom Software / Open Source (Why?)
The personal opinions of moderators or contributors to the Whonix ™ project do not represent the project as a whole.