Running normal applications has the problem that any remote code execution vulnerability in the application totally compromises the user. This isn't just a theoretical attack, a vulnerability in Firefox was used to compromise visitors of hidden services hosted by Freedom Hosting in August 2013.

One obvious way to contain this is sand-boxing the application in a virtual machine. Nothing inside the virtual machine, not even the OS should be able to bypass Tor. This obviously implies running Tor outside the virtual machine so this limitation cannot be bypassed by malicious software running inside the virtual machine.

This seems like a natural and secure way to run Tor, so I was surprised to not find any standard bundle (some virtual machine software configured to use Tor together with a specialized Linux or BSD distribution, like Tails) that works this way.

Is there an easy way to configure a virtual machine that can only communicate with the outside through Tor?

  • If you're going to sandbox your Tor install, sandbox everything including Tor itself. If you don't want Tor on the same machine as the other software, run a second virtual machine with Tor on it. The networking side of this is a bit off topic and depends heavily on the virtualization software you're using and what sort of network you're virtualizing. If you want help with that anyways, more info would be good. – Sam Whited Oct 4 '13 at 18:09
  • 5
    The Whonix setup does this, and the Whonix wiki also contains a wealth of security-related information. It has clearly been well thought out, with careful attention to practically every possible detail. – Michael Hampton Nov 1 '13 at 0:49
  • I'm not that worried about security holes in the Tor client, since my normal working behaviour is far riskier. IMO the biggest advantage of the Whonix approach is that the tight integration of Tor with then outer VM reduces the risk of configuration mistakes. – CodesInChaos Feb 15 '15 at 18:59
up vote 14 down vote accepted

Have you considered using Whonix? It comprises two virtual machines, one of which is a gateway and the other a workstation. You work as normal on the workstation, with every network request being funnelled through the gateway and hence through Tor.

Tails is a live Linux operating system that routes all traffic through Tor. Tails can handle many use cases well and is the way to go if you need to torify applications apart from your browser. Please take a look at Tails first, understand its features and threat model before you advance.

Remember the Tor Project suggests only two ways to use Tor: Tor Browser and Tails.

If you explicitly need a way to:

  1. route all traffic through Tor
  2. have Tor running in another machine

then Tails may not fit.

Generally speaking, to implement this you will need two machines: the first machine will run Tor and will serve as a router. The second machine will be able to connect only to the first and thus every connection will be routed through Tor.

This scheme is implemented from Whonix Anonymous Operation System:

Whonix is divided into two parts: Whonix-Workstation for your work and Whonix-Gateway for automatically routing all Internet traffic through Tor. This is security by isolation, and it averts many threats posed by malware, misbehaving applications, and user error.

Apart from Whonix, you could implement something yourself. For example:

  • Run Tor in machine A (say it's a Debian)
  • Set up a virtual interface on machine A, with a private IP address:

    File /etc/network/interfaces:

    auto vnet0
    iface vnet0 inet static
        bridge_ports none
        bridge_maxwait 0
        bridge_fd 1
  • Create the virtual machine B, configure its interface in bridge mode with the vnet0 interface of machine A. Set a static IP address, for example, and as gateway the private IP address of machine A.

  • Create a script in machine A that will do all the NAT routing with iptables. You will need something like this:

    iptables -F
    iptables -t nat -F
    iptables -t nat -I POSTROUTING -s -j MASQUERADE
    iptables -t nat -A PREROUTING -i vnet0 -p udp --dport 53 -j REDIRECT --to-ports 53
    iptables -t nat -A PREROUTING -i vnet0 -p tcp --syn -j REDIRECT --to-ports 9040
    iptables -t nat -A PREROUTING -i vnet0 -j DROP
  • Finally you should make sure that on machine A will use Tor, so in torrc:

    AutomapHostsOnResolve 1
    TransPort 9040
    DNSPort 53

This is to get a rough picture and there should be various other aspects that you should handle with care. For example, running a non Tor-Browser browser in the isolated machine will distinguish you from other Tor users, so that may harm your anonymity.

  • 3
    The Whonix workstation uses the Tor Browser, by the way. – mirimir Oct 5 '13 at 4:45


Running normal applications has the problem that any remote code execution vulnerability in the application totally compromises the user. This isn't just a theoretical attack, a vulnerability in Firefox was used to compromise visitors of hidden services hosted by freedom hosting in August 2013.

Never rely on the virtual machine against malicious code. For that task you should take a bare hardware, separate station connected to the Tor's host.

You can google a thousands of examples with breaking any chroot / any jail. The same picture with virtual machines.

If you do not believe me, start googling from this -> Blue Pill.

If you are looking for a solution against leaks - probably, there is a SOCKS5 settings for you:



You should create a virtual interface called "bridge" and bind IP address from host to this interface. Thereafter, make a SOCKS5 proxy on the 9050 port for IP address

root@host:~# brctl addbr br0
root@host:~# ifconfig br0 netmask up
root@host:~# kill -HUP `pidof tor`

Make sure that your VM use only a virtual interface, br0, that not connected to any external (real) interface.

In your VM, configure everything what's needed for a network to use socks5 proxy. For example, look at /usr/bin/torsocks.

1) For example, LXC-Container, /var/lib/lxc/VM/config:

.... = veth = 00:12:34:56:78:9a = br0 = up =

Inside the container, change default server IP address from loopback to virtual bridge, for torsocks proxifier /etc/torsocks.conf:

#server =
server =

Now you can proxify anything by torsocks:

root@vm:~# torsocks wget -q -O - 2>&1 | egrep -i 'congratulations|ip address'
<img alt="Congratulations. Your browser is configured to use Tor." src="/images/tor-on.png">
Congratulations. Your browser is configured to use Tor.<br>
Your IP address appears to be: <b></b><br>


Hint: Do not break default Tor settings, keep the SOCKS5 proxy by default on and use one of the inet daemons, for example, rinetd:

root@host:~# vi /etc/rinetd.conf
# bindadress    bindport  connectaddress  connectport     9050         9050

Now reload settings and you get 2 socks5 of Tor, one on the loopback and another on the br0:

root@host:~# service rinetd reload
Reloading configuration of internet redirection server: rinetd.

2) In VirtualBox you need only one settings to achieve this:

VirtualBox settings

Inside the VM, configure everything to use socks5 proxy, for example, chromium:

securityonion inside VirtualBox

3) QEMU; here you are need a tap interface:

root@host:~# modprobe tun
root@host:~# tunctl -t tap0
root@host:~# brctl addbr br0
root@host:~# brctl addif br0 tap0
root@host:~# ifconfig br0 netmask up
root@host:~# ifconfig tap0 up
root@host:~# iptables -I INPUT -m state --state NEW -i tap0 -j ACCEPT
root@host:~# iptables -I INPUT -m state --state NEW -i br0 -j ACCEPT
root@host:~# cat >> /etc/rinetd.conf << EOF     9050         9050
root@host:~# service rinetd restart
root@host:~# /usr/bin/qemu-system-x86_64 -boot d -m 2048 --enable-kvm \
             -cdrom  'kali-linux-1.0.5-amd64.iso' \
             -net nic,vlan=1,macaddr=00:aa:00:60:00:01,model=e1000 \
             -net tap,vlan=1,ifname=tap0,script=no  -vga std 

Don't forget inside the QEMU set ip address to the eth0 interface:

root@kali:~# ifconfig eth0 netmask up
root@kali:~# ping
64 bytes from icmp_req=1 ttl=64 time=0.395ms
64 bytes from icmp_req=2 ttl=64 time=0.241ms 
64 bytes from icmp_req=3 ttl=64 time=0.42ms 

Don't forget to change default firefox settings about:config -> network.proxy.socks_remote_dns = True

kali in qemu / firefox dns proxy

Set socks5 proxy: Edit -> Preferences -> Advanced -> Network -> Settings -> Manual proxy configuration -> SOCKS Host: & Port: 9050

kali in qemu / proxy settings

Check your connection:

kali in qemu / Success!

Configure /etc/proxychains.conf by adding only one string to the end of file: socks5 9050:

kali in qemu / proxychain

Now, you can start any program with prefix proxychain program.bin:

kali in qemu / ddos stackexchange via proxychain

The VM doesn't see an external network, only tap0 and virtual bridge behind this tap0 - br0, and SOCKS5 proxy on that bridge

4) VMware:

VMware settings

That way, the VM will connect to the host machine, to VMware's internal virtual interface, vmnet1, only, no external network. Bind the SOCKS5 proxy to this interface by rinetd.

VMware with security onion inside

Q: What VMs support this?

A: pretty much everyone. QEMU, KVM, LXC, Bochs, VirtualBox, VMware, Parallels Workstation, FreeBSD jail, Xen, etc...

Q: What is the main goal?

A: With only one-two commands and SOCKS5, you can get everything what you are looking for. With any environment around you... You may replace Tor with any other proxy server or even with ssh.

It looks much better than native Tor's transport port, because SOCKS5 is everywhere. You will never see any leaks with this technique.

See: tor-talk Tor transparent proxy leaks?, TransparentProxyLeaks.


Let me tell you once again, NEVER rely on the virtual machine against malicious code! This may be used only for comfort. 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16 ... infinity.

What color? It doesn't matter...

  • Have you tested? – adrelanos Oct 7 '13 at 1:13
  • How does the network interface to socks5 translation work? – adrelanos Oct 7 '13 at 1:16
  • Have you tested? Yes, I do this with Qemu, LXC and VritualBox. This works like charm! How does the network interface to socks5 translation work? I'm not sure that understand you correctly, socks5 is the third generation of proxy. http_proxy -> socks4 -> socks5. Read the wikipedia. also look at proxifier: /usr/bin/torsocks – perpetuity Oct 9 '13 at 8:58
  • I know what socks is. I mean, SocksListenAddress opens a SocksPort. ifconfig virbr0 netmask up does what? Redirecting the network to the SocksPort? But why does Tor receive socks traffic? Why doesn't this require Tor's TransPort? – adrelanos Oct 10 '13 at 5:46
  • ifconfig virbr0 bind to the virtual interface called bridge. Your VM use this interface, and get access only to socks. Its like you behind corporation's DMZ, where only proxy exist for external world. Create your own bridge this way: brctl addbr br0. See I have improve my answer. – perpetuity Oct 11 '13 at 9:04

Update: 2016-04-17

Qubes-Whonix integration is now extremely good. I use it myself and highly recommend it. (Qubes TorVM is now deprecated.)

You can read all about Qubes-Whonix on the Qubes website here and on the Whonix website here.

Thanks go to adrelanos and all the other devs whose hard work made this happen.

Old answer (2014-08-17):

Qubes TorVM is exactly what you've described.

In simple terms, Qubes OS is an operating system which provides security by isolation using the Xen hypervisor. All user data and programs are run in lightweight, securely isolated virtual machines called AppVMs.

Qubes TorVM is a Qubes OS service which fully and transparently "Torifies" all the network traffic to and from any AppVM which is connected to it. From the documentation:

By default, any AppVM using the TorVM as its NetVM will be fully Torified. (Such AppVMs are referred to as "AnonVMs.") This means that even applications which are not "Tor aware" will be unable to access the outside network directly. Moreover, AnonVMs are not able to access globally identifying information (IP address and MAC address).

In brief, TorVM is designed so that all AnonVM traffic which can be sent over Tor is sent over Tor. All other traffic is silently dropped.

This means that even if a hacker uses a Firefox zero-day to compromise your Tor Browser, which is running in your AnonVM, the attacker will not be able to learn your real, external IP address, since all the traffic to/from the (now compromised) AnonVM is still being sent over Tor, which is running in the separate, uncompromised TorVM.

Note: The answer I've provided here is just a brief sketch. You are strongly advised to do your homework before attempting to use any security-critical software. (In the case of Qubes OS and TorVM, I recommend thoroughly reading the documentation and searching the mailing list archives for issues which pertain to your situation.)

Last, but not least, good people are also working on integrating Whonix with Qubes, which promises more great things for the future of using Tor securely!

  • Qubes is very cool, but since it doesn't work (well) in a VM, it forces me to dual boot, making it rather inconvenient to use. – CodesInChaos Feb 21 '15 at 19:07
  • 1
    @CodesInChaos you don't install Qubes in a VM though. You install it on your computer as main OS and you can have different isolated operating systems (including whonix) as a VM. – mrphs May 24 '16 at 19:41

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.