How To Set Up A TOR Middlebox Routing All VirtualBox Virtual Machine Traffic Over The TOR Network

This tutorial will show you how to reroute all traffic for a virtual machine through the Tor network to ensure anonymity. It assumes a standalone machine with a Linux OS, and VirtualBox installed. In this case, we'll be using Ubuntu on the host machine.

Thanks to
- http://www.tolaris.com/2009/03/05/using-host-networking-and-nat-with-virtualbox/
- https://trac.torproject.org/projects/tor/wiki/doc/TransparentProxy
- http://www.rootdamnit.eu/2011/12/10/virtualbox-tor-backtrack-aka-how-to-become-almost-invisible/

All commands on the host machine should be run as root (sudo or su.

 

Step 1 - Add A Bridge Interface For Your Virtual Machine (VM) On The Host Machine (HM)

# apt-get install bridge-utils

Add the following to /etc/network/interfaces:

# VirtualBox NAT bridge
auto vnet0
iface vnet0 inet static
 address 172.16.0.1
 netmask 255.255.255.0
 bridge_ports none
 bridge_maxwait 0
 bridge_fd 1
 up iptables -t nat -I POSTROUTING -s 172.16.0.0/24 -j MASQUERADE
 down iptables -t nat -D POSTROUTING -s 172.16.0.0/24 -j MASQUERADE

Start the bridge interface:

# ifup vnet0

 

Step 2 - Setup DHCP And DNS For Clients

# apt-get install dnsmasq

Edit /etc/dnsmasq.conf to include:

interface=vnet0
dhcp-range=172.16.0.2,172.16.0.254,1h

Start the daemon:

# /etc/init.d/dnsmasq restart

 

Step 3 - Install And Set Up TOR

Install TOR - INSTUCTIONS

Edit /etc/tor/torrc and add:

VirtualAddrNetwork 10.192.0.0/10
AutomapHostsOnResolve 1
TransPort 9040
TransListenAddress 172.16.0.1
DNSPort 53
DNSListenAddress 172.16.0.1

Restart TOR:

#/etc/init.d/tor restart

Create and edit middlebox.sh on the HM:

#!/bin/sh

# destinations you don't want routed through Tor
NON_TOR="192.168.1.0/24"

# Tor's TransPort
TRANS_PORT="9040"

# your internal interface
INT_IF="vnet0"

iptables -F
iptables -t nat -F

for NET in $NON_TOR; do
 iptables -t nat -A PREROUTING -i $INT_IF -d $NET -j RETURN
done
iptables -t nat -A PREROUTING -i $INT_IF -p udp --dport 53 -j REDIRECT --to-ports 53
iptables -t nat -A PREROUTING -i $INT_IF -p tcp --syn -j REDIRECT --to-ports $TRANS_PORT

and run it:

#./middlebox.sh

 

Step 4 - Set Up The Virtual Machine On The HM

Open VirtualBox, start the machine. Go to Devices > Network Adapter. Disable all network adapters except Adapter 1.

Set the following options:

Attached to: Bridged Adapter
Name: vnet0
Click OK.

Finally make sure your virtual machine gets its IP address via DHCP, and refresh the DHCP client/reboot the VM. It should have an IP in the range 172.16.0.n, name resolver 172.16.0.1 and gateway 172.16.0.1.

Share this page:

12 Comment(s)

Add comment

Comments

From: at: 2012-03-30 11:02:35

You can also block all UDP traffic/leaks from your virtual machine with

iptables -A FORWARD -i $INT_IF -p udp -j DROP

in middlebox.sh (DNS queries continue to be handled by TOR):

#!/bin/sh

# destinations you don't want routed through Tor
NON_TOR="192.168.1.0/24"

# Tor's TransPort
TRANS_PORT="9040"

# your internal interface
INT_IF="vnet0"

iptables -F
iptables -t nat -F

for NET in $NON_TOR; do
 iptables -t nat -A PREROUTING -i $INT_IF -d $NET -j RETURN
done
iptables -t nat -A PREROUTING -i $INT_IF -p udp --dport 53 -j REDIRECT --to-ports 53
iptables -A FORWARD -i $INT_IF -p udp -j DROP
iptables -t nat -A PREROUTING -i $INT_IF -p tcp --syn -j REDIRECT --to-ports $TRANS_PORT

 

 

From: at: 2012-05-27 22:36:43

I have set this up and it seems to be working well.  I included chris_dj's extra command in middlebox.sh.  Web sites like seemyip and others show IP addresses that are not mine. 

However, I use a lot of command line requests, and I'm wondering how I could test them for anonymity.  Is there a address I could ping that would somehow return my originating IP?  Or would it just be reasonable to conclude that since the browsers are anonymous, and since TOR is not installed on the guest OS, only on the host OS, that all traffic from the guest must necessarily be anonymous as well?

From: Pan Ta at: 2012-06-26 18:31:27

It works for me -- also including the extra command in middlebox.sh.

You can check your IP address at the command line by creating a shell script.

http://ubuntuforums.org/archive/index.php/t-526176.html 

I confirmed the same IP addresses from the command line that I get from my browser.

Also, for what it's worth, I'm running through a VPN on my host before I ever start Tor. When I start my guest, everything still works... the IP addresses are always different -- and never reflect my current ISP. If someone discovers a flaw in this, I'd like to hear about it.

From: lbm at: 2014-09-18 19:41:20

Maybe it's a flaw or maybe it's just me getting confused here but with this setup I get some strange results using nmap guest-side. No matter the target "nmap -sS" reports all ports open and "nmap -sT" all ports filtered.

Maybe I'm missing something obvious here but I'm really not experienced when it comes to iptables.

From: Anonymous at: 2012-05-15 19:34:53

Has anyone been able to successfully replicate the steps outlined above?  Just curious. I'm unable to connect to any hosts in the Virtual Machine. I can ping the 172.16.*.* address but can't any where else. Thought I'd ask.

From: mpd2 at: 2012-06-07 14:34:58

Yes, this works as of the date of this comment.  I had to make an adjustment on my machine (vanilla ubuntu 12.04) because dnsmasq-base was installed by default: http://ubuntuforums.org/showpost.php?p=12006425&postcount=7.

From: Anonymous at: 2013-08-05 08:47:41

 There is one flaw in this procedure, in that the MASQEURADE rule in Step 1, which gets executed when the vnet0 interface comes up, gets flushed out of iptables when you execute the middlebox.sh script, which is a bit of a mistake, and which is probably causing your problem.

To fix this you need to add that same rule by copying and pasting it into the middlebox.sh script so it looks like this;


#!/bin/sh
# destinations you don't want routed through Tor
NON_TOR="192.168.1.0/24"
# Tor's TransPort
TRANS_PORT="9040"
# your internal interface
INT_IF="vnet0"
iptables -F
iptables -t nat -F
iptables -t nat -I POSTROUTING -s 172.16.0.0/24 -j MASQUERADE
for NET in $NON_TOR; do
 iptables -t nat -A PREROUTING -i $INT_IF -d $NET -j RETURN
done
iptables -t nat -A PREROUTING -i $INT_IF -p udp --dport 53 -j REDIRECT --to-ports 53
iptables -A FORWARD -i $INT_IF -p udp -j DROP
iptables -t nat -A PREROUTING -i $INT_IF -p tcp --syn -j REDIRECT --to-ports $TRANS_PORT

From: Anonymous at: 2012-10-16 13:56:02

Thanx four this tutorial, I have searched a lot for this but never found it. My problem is, I want to do this on arch linux and there doesn't exists the file /etc/network/interfaces or any similar config.
So i want to start the bridge manually with:
brctl addbr br0
ifconfig vnet0 172.16.0.1 netmask 255.255.255.0 up
iptables -t nat -I POSTROUTING -s 172.16.0.0/24 -j MASQUERADE

but I can't figure out how to set the other settings like:
auto vnet0
vnet0 inet static
bridge_ports none
bridge_maxwait 0
bridge_fd 1

I hope someone can help me.

From: Anonymous at: 2013-08-04 09:26:00

Is it really necessary to run a dhcp server on the host machine or can the VM be run without dhcp by assigning an IP to its network?

 

From: Rune at: 2013-10-09 13:54:21

No, setting up a DHCP server on the host is not necessary.

I just configured the network device in the VM to have a static IP of 172.16.0.2 and a gateway and DNS server of 172.16.0.1 and it works.

From: Anonymous at: 2014-09-23 09:29:24

Before the Step 2, when I trying to do the:

# ifup vnet0
Cannot find device "vnet0"
Failed to bring up vnet0.

 Any suggestion?

From: Me at: 2015-04-14 07:46:01

I had this setup working in Mint Maya / Ubuntu Precise. I upgraded to Mint Rebecca and now the VirtualBox is not disguised properly any longer: before the upgrade, the VB was not able to contact the outside world without running the script containing the iptables commands. Now, in Mint 17, the VB has full access to the internet, even when the virtual network is not startet and sites like ipaddress.com show that the ip is not masqueraded!

There seem to be some serious changes either to the kernel or VirtualBox 4.3 that require changes to this setup.