Transporting UDP Tunnels over Tor
According to the Tor Project: 
Tor transports data over encrypted TLS tunnels between nodes, which is in turn carried by TCP.
The current Tor design does not support the transport of UDP-based protocols [archive] through exit nodes in the network.  This is unlikely to be supported in the near future due to incompatibility with cryptographic protocols in use and those planned.
The consequence is that UDP-based protocols and applications cannot be used to transmit UDP datagrams between guards and exit nodes in the default configuration. This affects a number of activities, such as VoIP or video applications. 
Transporting UDP Tunnels over Tor with a VPN
A solution to this problem is to use a tunneling protocol [archive]. In simple terms, this allows a user to access a foreign protocol or network service that the underlying (Tor) network does not support or provide directly.
The tested and working method in Whonix ™ is to utilize a Virtual Private Network (VPN) with a trusted provider that does not block UDP traffic in the following configuration:
[Other Anonymizing Network] →
Internet. Some VPN protocols like OpenVPN can use UDP while implementing reliable connections and error checking at the application level. 
Before following the instructions to tunnel UDP over Tor, please first read the related VPN documentation and warnings:
- Connecting to Tor before a VPN (
- Tor Plus VPN or Proxy [archive].
- Tunneling comparison table.
- Whonix ™ VPN disclaimer.
The current Tor architecture [archive] may lead to a negative performance impact on user activities. This arises from high latency due to congestion in the network, queue length on nodes (mixing of traffic across multiple nodes), and TCP mechanisms which attempt to account for lost packets and hold delivery of future packets until a resend is complete. 
Always remember that adding a second connection in the tunneling chain adds significant complexity. This potentially increases the security and anonymity risks due to:
- The increased attack surface of secure tunneling software.
- The difficulty in anonymously paying for VPN services - a money trail is potentially the weakest link probed by adversaries.
- Potential bottlenecks with VPN providers.
Depending on the final configuration this may also: increase fingerprinting risk, remove stream isolation of activities, and lead to a permanent destination (exit node) "X" in the Tor network.
Table: Tor Project VPN/SSH Warnings 
|Activity Profiling||If the VPN is the last part of the tunnel connection, the provider can build a profile of all activities which is dangerous for anonymity.|
|Attack Surface and Data||Passive attacks by global adversaries might be more difficult, but this is counter-balanced by a larger attack surface and additional data generated by this configuration. On the other hand, this configuration provides better protection against colluding Tor nodes and hackers targeting Tor client code.|
|Tunnel Fragility||If/when the VPN connection breaks down, direct Tor connections are made without the VPN unless a fail closed mechanism has been configured; see VPN Firewall. |
|VPN/SSH Honeypots||If the VPN/SSH server is adversary-controlled, Tor protection is weakened.  For example, a malicious VPN provider could maintain detailed traffic and session logs, along with meta-data.  This configuration is also reportedly susceptible to end-to-end timing attacks, since the times users were connected to anonymity services can be measured. |
|Website Traffic Fingerprinting||VPN and SSH protocols are vulnerable to website traffic fingerprinting:  |
In this UDP tunneling context, this means that a Tor exit relay could apply website traffic fingerprinting and determine which website is being visited, even though a VPN/SSH tunnel is in effect. 
Whonix ™ Recommendations
Whonix ™ recommends the use of OpenVPN [archive] as the most secure (SSL/TLS-based) protocol, rather than reliance upon IKE, L2TP/IPsec or PPTP. OpenVPN is considered extremely secure when used with encryption algorithms such as AES. 
A dedicated virtual machine is recommended for this activity; see Multiple Whonix-Workstation ™.
- https://blog.torproject.org/blog/moving-tor-datagram-transport [archive]
- The Tor ticket was closed as "wontfix" in 2017.
- https://en.wikipedia.org/wiki/User_Datagram_Protocol [archive]
- Other VPN implementations may also be useful, but they have not been researched yet.
- https://guardianproject.info/2012/12/10/voice-over-tor/ [archive]
- https://gitlab.torproject.org/legacy/trac/-/wikis/doc/TorPlusVPN [archive]
- Without a fail closed mechanism, if the VPN "breaks down" (the connection is interrupted) then traffic is sent without the VPN. It is far safer to shut down the entire Internet connection in this event, until the VPN connection is restored.
- It is impossible to absolutely confirm whether a VPN service is a legitimate provider.
- https://www.comparitech.com/blog/vpn-privacy/how-to-access-the-deep-web-and-darknet/ [archive]
- https://www.sunnyhoi.com/which-is-better-tor-over-vpn-or-vpn-over-tor/ [archive]
- See: Touching from a Distance: Website Fingerprinting Attacks and Defenses [archive]
- This is a relatively minor threat overall. On the other hand, if a VPN/SSH tunnel is established without Tor, “website traffic fingerprinting” is a far more impressive feat.
- IKE is being exploited by advanced agencies to decrypt IPSec traffic. IPsec configured with pre-shared keys is vulnerable to MITM attacks. PPTP is an obsolete method for VPN implementation with a host of security weaknesses. For further reading on adversary capabilities against VPN protocols see: http://www.spiegel.de/media/media-35515.pdf [archive]