If openvpn is used inside Whonix-Gateway ™ (sys-whonix) or Whonix-Workstation ™ (anon-whonix) as per the Whonix ™ documentation, openvpn will not start inside the whonix-gw-16 or whonix-ws-16 TemplateVM. ^[4] In Qubes R4 and above, by default the TemplateVMs's NetVM is purposely set to none ^[archive]. (They are upgraded through the qrexec-based updates proxy that is running on sys-whonix.)

Example:

In tunnel-chain 1, the ISP-assigned IP address is permanently linked to the tunnel-link. In tunnel-chain 2, the same tunnel-link was reused. Since the user's ISP-assigned IP address was previously linked to that same tunnel-link, the "anonymous" identity can now be linked to the user's actual IP address.

• Tunnel-chain 1: (User → Tunnel-link (user's IP address is linked) → Tor → Internet)
• Tunnel-chain 2: (User → Tor → Tunnel-link (anonymous activities linked) → Internet)

The previous example also holds true if the tunnel-link is first used with tunnel-chain 2 and then reused in tunnel-chain 1. In this case, all anonymous activities conducted with tunnel-chain 2 would be linked with the user's ISP-assigned IP address.

• In the User → VPN → Internet configuration or User → VPN → Tor → Internet configuration, anonymous payments with Bitcoin, cash and other methods does not improve anonymity because a user is still connecting to the service from their own IP address (which can be logged).
  
• In the User → VPN → Internet configuration or User → Tor → VPN → Internet configuration the use of shared IP addresses does not confuse modern surveillance systems which have a host of additional fingerprinting methods (like user agents) to identify persons of interest.
  
• VPN traffic is sensitive to Deep Packet Inspection (DPI) ^[archive] and Website Traffic Fingerprinting ^[archive], ^[8] so it is ineffective in hiding use of Whonix ™ and Tor from the ISP or skilled adversaries.
• Certain variables make it likely Whonix ™ / Tor users can be identified. This includes: the hardened network configuration fingerprint, the list of installed packages and those fetched from repositories, the amount of traffic going to one IP address daily (guard nodes), and examination of dropped (invalid) versus non-dropped packets when the firewall is probed. ^[9]
  
• Apart from a few exceptions (see Use Case Exceptions), VPNs do not provide additional privacy -- it is still possible for adversaries to tap your connection, except at a different point (where traffic leaves the VPN server).

• VPNs are 'glorified proxies'. Since they can observe all user traffic, there is nothing preventing them from using that data for any purpose they like, including logging. ^[10]

• Claims that providers do not log user activity are unverifiable; in fact this claim is exactly what could be expected from a malicious provider.
  
• Recent research reveals that around one-third of all popular VPN providers are owned by Chinese companies, while others are based in countries like Pakistan, with non-existent or weak privacy laws. ^[11] The implication is that traffic might be routinely examined in a high percentage of cases, despite corporate promises to the contrary.
  
• The only safe assumption to make is that all VPN providers log activity in order to deflect potential legal actions and to satisfy government demands for (meta)data on 'suspect' users.
  
• A number of high profile VPN providers like HideMyAss have already handed over user data in the past; ^[12] many VPN adherents are unaware of these precedents.

• VPNs do no necessarily protect against today's advanced malware that tries to discover the true IP address via browser and other exploits.
  
• Adversaries who can break Tor Browser to make web requests not travel over Tor are probably also capable of: running arbitrary commands as a non-root user, gaining root privileges, or ultimately performing a VM escape from Whonix ™. In this case a VPN is useless in providing additional security.

• VPNs do not magically improve security; they are just a glorified proxy. 'Honeypot' or malicious providers might be ubiquitous. ^[13]
• The need to run additional software like OpenVPN can actually increase the attack surface and complicated configuration instructions can lead to mistakes that reduce overall security.
• The claim of 'additional encryption' does not stack up in providing more security; even with a VPN if the endpoint expects plaintext, it is not technically possible for a VPN to change that. It is still necessary to use SSL/TLS and HTTPS (for centralized services), or end-to-end encryption for P2P and social applications for improved security.
  
• The only encrypted part of the connection when using a VPN is from the user to the provider. From the VPN provider onward the traffic is the same as it would have been without a VPN. Since the VPN provider can see this traffic (and potentially mess with it), this is arguably a net loss in security.

• The User → Tor → VPN → Internet configuration attempts to display an IP address that is not associated with Tor.
  
• This throws away many of the anonymity and security benefits associated with Tor and places sole trust in the VPN provider where the traffic exits.
  
  • Traffic is no longer separated on different browser tabs -- a single circuit is built in the Tor network, and this can break local state separation within Tor Browser.
    
  • If other things are done over the VPN connection like SSH traffic, IRC traffic, SMTP or OS updates, all of this traffic is sitting right next to each other.
    
• Anonymity is affected because the ISP will see connections to the Tor guard (unless trying to hide it with a bridge) and a global adversary is likely capable of performing traffic analysis on the limited number of VPN exit points. Further, the VPN provider is granted greater trust under this configuration.
• This configuration slows down connection speed because there is a TCP stream (OpenVPN) inside of a TCP stream (Tor). ^[14]

• keep payment information
  
• keep logs
  
• lie about their geolocation (see here ^[archive])
• share information with adversaries
  
• get breached by advanced adversaries (see this recent NordVPN breach ^[archive])
• fail to keep servers secure (see this recent TorGuard server configuration file error ^[archive])

• A potentially 'hostile' network must be used, like those found in public airports (WiFi access points) and where ISPs have a questionable record of man-in-the-middle attacks. (User → VPN → Tor → Internet)
  
• It is necessary to hide an IP address from non-government-sanctioned adversaries. ^[15]
• If a VPN is essential in your circumstances for whatever reason, it is not recommended to set up your own Virtual Private Server (VPS) ^[archive]. This will lead to a unique fingerprint, and there is no guarantee that a rented server is less likely to be malicious than a standard VPN provider.

• It is questionable the User → VPN → Tor → Internet configuration adds any additional protection; see this stackexchange discussion ^[archive].
  
• If Tor is blocked for whatever reason it is simpler to configure a bridge with a pluggable transport to try and bypass it. ^[16]
• This configuration is unlikely to hide Tor use from a Global Passive Adversary (GPA) ^[archive]. Since a GPA is capable of watching all traffic enter and exit the Tor network, they are more likely to be capable of watching all traffic enter and exit from a single VPN provider. ^{[17] [18]} It has been assessed as difficult beyond practicality to Hide Tor use from the Internet Service Provider with proxies, bridges, VPNs or SSH tunnels.

• Tor avoids using more than one relay belonging to the same operator in the circuits it is building. 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. ^[19] Tor however does not take into account your real external IP address nor destination IP addresses. ^[20]
• In essence, you must avoid using the same network/operator as your first and last Tor relays since this would open up Confirmation Attacks.

• Many tunnel providers use shared IP addresses which means that many users share the same external IP address. On the one hand this configuration is beneficial, since it is similar to Tor whereby many users share the same Tor exit relays. On the other hand, in some circumstances this may result in making you less anonymous.

• It is possible to host Tor relays -- including bridges, entry, middle or exit relays -- behind VPNs or tunnel-links. For example, there are VPN providers that support VPN port forwarding ^[archive]. This is an interesting way to contribute to Tor while not exposing oneself to too much legal risk. This also means in certain situations a VPN or other tunnel-link could be hosted by the same operator providing support to Tor relays, in the same network or even on the same IP address.
• In an economy with deep labor division, certain operators are providing a service to host servers (VPS etc.), while others provide VPN and other tunnel-link services and rent such servers. It is therefore not uncommon for diverse customers to run or share the same IP address. This is another situation where a VPN or other tunnel-link could be hosted by the same operator supporting Tor relays, in the same network or even on the same IP address.

• Based on the section immediately above, it follows that adding arbitrary tunnel-links might lead to the same operator/network being used twice in your connection chain. Consider the scenarios below.
• Scenario 1:
  • A VPN with a fixed IP address is used on the host, thereby it acts as the first relay.
  • The same user's Tor client coincidentally selects a Tor exit relay running on the same VPN IP address.
  • The user is now using the same IP address as the first and last proxy, meaning overall anonymity is reduced in this scenario.
• Scenario 2:
  • A VPN with a fixed IP address is set up inside Whonix-Workstation ™. This results in the connection scheme User → Tor → VPN → Internet.
  • A Tor entry guard is also hosted on the VPN IP address.
  • The user is now using the same IP address as the first and last proxy, meaning overall anonymity is reduced in this scenario.

• Consider the physical location of networks/servers and the legal jurisdiction(s) they are operating in.
• Perhaps avoid using VPN or SSH providers that support port forwarding.
• Perhaps only use tunnel-link providers that are assigning private (non-shared), unique IP addresses. However, as noted earlier it is unclear if this does more harm than good.
• Perhaps use tunnel-link providers that run their own servers rather than relying on shared infrastructure.

• It might be safer to manually select your Tor relay(s), specifically the Entry Guard(s) or Bridge(s) in operation.
• Tor documentation generally discourages tampering with Tor's routing algorithm by manually choosing relays. However, if you have decided to extend the length of the Tor chain -- despite the difficulty of this endeavor and potential adverse anonymity impacts -- then it might make sense to pick the entry guard(s) by hand.
• Using Bridges might be an alternative, but note this warning from experienced Tor developers ^[archive]:

  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.

VPN: If the VPN supports Remote Port Forwarding, yes
SSH: If the SSH supports Remote Port Forwarding, yes

VPN: If supported by the VPN, yes
SSH: Undocumented

1. pass through the ISP as proxy/VPN/SSH traffic;
   
2. exit the proxy/VPN/SSH server as encrypted Tor traffic;
   
3. enter the Tor network; and
   
4. exit the Tor network at a Tor exit node as normal Internet traffic (encrypted or unencrypted).

• You must connect to a VPN or proxy to access the Internet.
  
• Your ISP blocks Tor and Tor bridges but does not block the tunnel-link.
  
• Concerns exist over de-anonymizing attacks against the Tor network and a user believes a VPN or proxy may help protect their identity in such a case.

• A VPN or proxy that knows your identity and/or location may be more willing and able to compromise your privacy than an ISP.
  
• If the software configuration does not block all traffic if/when the VPN connection suddenly disconnects, all encrypted Tor traffic will pass through the ISP without warning. This is the default for most VPN configurations and not a Whonix ™-specific issue. Workarounds are described in the links below.
  
• If Tor use is dangerous in your area, VPNs or SSH may provide insufficient protection (due to software misconfiguration or sophisticated packet inspection). Proxies do not provide encryption and should not be used to try and hide Tor.

1. pass through the ISP as encrypted Tor traffic;
   
2. exit the Tor network at a Tor exit node as proxy/VPN/SSH traffic; and
   
3. exit the proxy/VPN/SSH as normal Internet traffic (encrypted or unencrypted).

• It is necessary to use a VPN or proxy anonymously for a specific reason.
  
• It is necessary to connect to an Internet server who bans Tor exit nodes.
  
• Concerns exist over de-anonymizing attacks against the Tor network and a user believes a VPN or proxy may help protect their identity in such a case.

• Even though Tor will hide the IP address from the VPN or proxy, you can still be located via payment methods, usage logs, or other identifying information the tunnel-link service holds.
  
• This configuration prevents access to Tor onion (.onion) services. ^[31]
• Malware on Whonix-Workstation ™ cannot bypass Tor, but it can ignore the VPN or proxy unless a separate Tunnel-Gateway is configured.
• It is not simple to configure VPNs, SSH or proxies in a foolproof, leak-free manner. However, in the case of Whonix ™ it is impossible for traffic to bybass Tor, even if the VPN or proxy is misconfigured. ^[32]
• Most of the pre-installed software on Whonix-Workstation ™, including Tor Browser, is configured to take advantage of Stream Isolation. As a side effect, this software will ignore the VPN by default. It is necessary to reconfigure this software to disable stream isolation.
• When connecting to Tor before a tunnel link, the browser tab stream isolation feature of Tor Browser will be lost (or difficult to access). ^[33] The reason is Tor Browser will not talk to Tor directly anymore, but will connect to the tunnel-link instead.
• When using a browser, connecting to Tor before a tunnel link worsens the web fingerprint. The anonymity effects of using the configuration: User → (Proxy / VPN / SSH →) Tor → Proxy / VPN / SSH → Tor Browser → Website are unknown. This setup is so specialized that very few people are likely to configure it, reducing the Tor Browser user pool to a far smaller subset. Due to potential fingerprinting harm it is recommended against.
• If proceeding despite the risk, the tunnel configuration should not be combined with any browser other than Tor Browser (like Firefox or Chrome). This would further exacerbate the browser fingerprinting risk. ^[34]