PPTP (Point-to-Point Tunneling Protocol) and Whonix ™
In this chapter, PPTP is utilized because it is useful, very easy to configure and well supported by all kind of devices. Compared to a proper set up with a hardware gateway between the internet and the devices you want to torrify it is less secure but doesn't require any kind of hardware or network layout changes.
Virtual Private Networks (VPNs)
In this case, VPN is used to allow other users on your local LAN to connect and use your Whonix ™ to connect to Tor with minimal configuration. Unlike Tor-VM where all network connections are forced through Tor or rejected, workstations connected over PPTP are NOT automatically protected against network level leaks and application level exploits.
We use PPTP [archive] here due to its wide install base (every installation of Windows since Windows 95 includes a client) and ease of installation. Be aware of the enormous security issues with PPTP [archive].
Warning, PPTP should NOT be used with Whonix ™ over the Internet, only for local trusted sources. See below for an OpenVPN implementation that allows use of Tor with minimal client configuration and should be secure enough to allow Internet connections (coming soon).
VPN: Bypassing Censorship and Enabling Free Speech
Because VPN services tunnel [archive] all Internet traffic, they can be used for e-mail, instant messaging, Voice over IP (VoIP) and any other Internet service in addition to Web browsing, making everything that travels through the tunnel unreadable to anyone along the way.
If the tunnel ends outside the area where the Internet is being restricted, this can be an effective method of circumvention, since the filtering entity/server sees only encrypted data, and has no way of knowing what data is passing through the tunnel. It has the additional effect of making all your different kinds of traffic look similar to an eavesdropper.
We use VPN here for its “tunnel” capabilities, so that others that you allow access, can take advantage of Tor via Whonix ™ with a single connection.
From your Whonix-Gateway ™:
apt-get install pptpd
This will install and start the
pptpd daemon on your Whonix-Gateway ™. Verify its running:
Should show something similar to:
root 8357 0.0 0.5 10512 696 ? Ss 17:26 0:00 /usr/sbin/pptpd
Stop it for the time being, while we configure it.
Configure PPTP settings:
localip 192.168.0.1 #your eth1 address remoteip 192.168.0.200-250 #a range of unassigned IP's
This can be potentially confusing, as the documentation in the configuration files are not the best. When you setup a PPTP connection, your Whonix-Gateway ™ will setup a virtual adapter (e.g. ppp0) which will output traffic sent from your client computer (those that connect to your server from your local LAN) to the Whonix-Gateway ™ and allow it to be routed through Tor. So if we want to use this virtual adapter just like a real adapter (e.g. eth0), we need to give it an IP address. That's what the
localip option is.
remoteip is a bit simpler. It is the IP address (or addresses) that are assigned to the client's computer when they connect. They get their own virtual adapter, which needs its own IP address.
See the FAQ here for information [archive]. For a simple overview of the VPN process see howVPN_works VPNClient @ Ubuntu Community Documentation [archive].
localip, for simplicity should be the IP of your eth1, as Tor is already configured to listen here and we don't actually do any routing creating an IP address conflict. remoteip, should be several IP's on your internal network (you should have as many IP's as potential clients, for example the “192.168.0.200-250” range above defines IP's for 50 clients)
remoteip can be set to other networks, other subnets, etc. With our approach it doesn't matter what their IP's are, simply that they exist. It is in fact encouraged that such clients be assigned to a “quarantine” network. Since we don't have routing enabled, other subnets would prevent your client's from seeing each other and your already established “safe” LAN; where your Whonix-Workstation ™ lives. But! The
torrc would need to be updated to listen on said addresses as well. Subneting in this fashion is beyond the scope of this document.)
Configure PPTP Options
Verify the following settings are configured as shown:
refuse-pap refuse-chap refuse-mschap require-mschap-v2 require-mppe-128 ms-dns <eth1 address>
refuse-pap: PAP style authentication [archive], insecure, so we don't want to use it if we can help it. refuse-chap: CHAP authentication [archive], insecure. refuse-mschap: MS-CHAP [archive], insecure require-mschap-v2: MS-CHAPv2 [archive], make sure that any connecting client must use this. It is as secure a we can get for a supported authentication method for PPTP. require-mppe-128: Microsoft Point-to-Point Encryption [archive], as secure encryption as we can get over PPTP, 128 bit is the maximum supported. ms-dns: Use this address as the DNS server for connecting (Windows) clients.
Configure IPtables rules for client connect and disconnect
ip-up script is called on each connection by a PPTP client, so we can put special firewall rules here to help with Torifying the traffic through this interface.
Add to the end:
#Firewall rules to add to route PPTP through TOR #Tor's TransPort TRANS_PORT#"9040" iptables -t nat -A PREROUTING -i $PPP_IFACE -p udp --dport 53 -j REDIRECT --to-ports 53 iptables -t nat -A PREROUTING -i $PPP_IFACE -p tcp --syn -j REDIRECT --to-ports $TRANS_PORT
The variable “$PPP_IFACE” is defined in the script (see the documentation at the beginning of the ip-up script) and resolves to the name of the interface established after a PPTP connection (e.g. ppp0).
ip-down script is called when tearing down the connection. To prevent your iptables from getting polluted with redundant rules, we remove the previously configured rules here:
Add to the end:
#Firewall rules to add to route PPTP through TOR #Tor's TransPort TRANS_PORT#"9040" iptables -t nat -D PREROUTING -i $PPP_IFACE -p udp --dport 53 -j REDIRECT --to-ports 53 iptables -t nat -D PREROUTING -i $PPP_IFACE -p tcp --syn -j REDIRECT --to-ports $TRANS_PORT
Notice the addition of the -D instead of -A to the rule definitions. This tells
iptables to Delete a rule with those parameters rather than Add one.
Start up your PPTP server:
From a client on your network (preferably one outside of your Tor network, e.g. not your Whonix-Workstation ™) connect to your VPN server.
Instructions for a variety of clients:
Linux (many flavors, direct from the pptp-client site) [archive] How to configure a connection to a virtual private network (VPN) in Windows XP [archive] VPNClient @ Ubuntu Community Documentation [archive] Windows 7 VPN step by step guide [archive]
Now verify the connection on the gateway, after successfully connecting: (Whonix-Gateway ™)
Should show something like:
ppp0 Link encap:Point-to-Point Protocol inet addr:192.168.0.1 P-t-P:192.168.0.200 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1496 Metric:1 RX packets:91 errors:0 dropped:0 overruns:0 frame:0 TX packets:71 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:10080 (10.0 KB) TX bytes:3622 (3.6 KB)
iptables -vnL -t nat
Chain PREROUTING (policy ACCEPT 103 packets, 14589 bytes) pkts bytes target prot opt in out source destination 0 0 REDIRECT udp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 redir ports 53 22 1320 REDIRECT tcp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x02 redir ports 9040
(You may have more information displayed here depending on configuration, but the lines above should at least appear in your PREROUTING chain)
On the client you should then be able to connect via Tor.
- Browse to
check.torproject.organd verify the “congratulations” message
Next disconnect from the VPN. On the server you should see several changes: (Whonix-Gateway ™)
should no longer show any ppp interfaces
iptables -vnL -t nat
should show no rules that involve any ppp interfaces
You can in fact test several client connections in this way. Each should get a new IP address (192.168.0.201, 192.168.0.202, etc), create a new virtual adapter (ppp1, ppp2, etc) and route through Tor via the Iptables commands (as above).
You can also attempt [LeakTests Leak Testing] to verify that no packets are leaking through your VPN connection.