Can you use Whonix-Gateway with any VM as a workstation?

Discussion in 'privacy technology' started by krustytheclown2, Mar 8, 2015.

  1. krustytheclown2

    krustytheclown2 Registered Member

    Joined:
    Nov 18, 2014
    Posts:
    210
    So I love the concept behind Whonix, but I have a few issues- you can't use FDE on the workstation (that I know of), and I really hate the KDE desktop they gave it. So, I'd like to create a setup where I have Whonix-Gateway, or something equivalent like pfSense running Tor if that's possible, linking to a VM with any arbitrary OS ( probably *buntu or WIndows 7).

    I know that I can have a somewhat similar setup with pfSense running a VPN, but I want it to use Tor. Is there a way to achieve this, and if so- how?
     
  2. mirimir

    mirimir Registered Member

    Joined:
    Oct 1, 2011
    Posts:
    9,252
    Yes, you can do that. Switching from KDE to another desktop on the workstation VM is easy. FDE is harder. I know of two ways. One way is to hack the existing workstation VM. Basically, you backup, repartition the VMDK with a separate /boot partition, do cryptsetup luksFormat on the main partition, and do LVM2 setup on the encrypted volume. The other way is to create a Debian VM with dm-crypt/LUKS/LVM2 using the installer, and then configure it to work with the Tor gateway VM. Tor Browser is easy. Getting other apps to work properly is harder.

    I can provide instructions for installing Tor in pfSense, if you're interested.
     
  3. krustytheclown2

    krustytheclown2 Registered Member

    Joined:
    Nov 18, 2014
    Posts:
    210
    So this is my desired setup: VPN 1 on host --> Tor Gateway VM (running either the Whonix Gateway or pfSense or whatever) --> VM secured with FDE, connected to VPN 2

    With the stock Whonix Workstation, setting up FDE is at the very least, quite a hassle, as you mentioned. Even disregarding that as it's less important, I can't figure out how to get it to connect to a VPN using the KDE network manager, and I've tried both OpenVPN and PPTP. After I set up the VPN, when I click to try to connect to it, it doesn't even respond. I'm not sure whether it's simply the KDE NM's fault, in which case installing Gnome and Gnome packages would solve it, or it's some other issue (maybe TCP/UDP related? But it didn't even attempt to make a connection......).

    I set up a fresh Debian Gnome 64-bit VM, changing the Network Settings to exactly match that of the stock Whonix Workstation, and then launched Whonix Gateway followed by the Debian VM. The Debian VM tried connecting to the network but failed repeatedly. I tried again with an OpenSUSE Gnome VM, with the same exact result. So, I think that Whonix has some sort of authentication mechanism that prevents a random VM from using the Gateway connection.

    What is the best way to create the setup I'm looking for? If pfSense is the only viable option, I'm all ears. However, I'm willing to forgo FDE on Whonix Workstation if I can get the thing to connect to a VPN (the Whonix forum has not been very helpful here).
     
    Last edited: Mar 8, 2015
  4. mirimir

    mirimir Registered Member

    Joined:
    Oct 1, 2011
    Posts:
    9,252
    Using a FDE host is best, because VirtualBox may leave plaintext on disk. What OS is your host running?

    For OpenVPN, you need to point to the SocksPort in the Whonix gateway VM. In each VPN config file, add these lines:
    Code:
    socks-proxy 10.152.152.10 9050 /path/to/up
    socks-proxy-retry
    The port is arbitrary, as long as it's configured in the gateway. The user/password file is not well documented: /path/to/up needs to exist, but it's not parsed.

    You use torsocks etc for apps that don't have SOCKS configuration options. But torsocks needs a local SOCKS port. And so you also need rinetd in the workstation. In /etc/rinetd.conf, you put a line for each of the SocksPorts that you want available:
    Code:
    127.0.0.1     9050     10.152.152.10     9050
     
  5. krustytheclown2

    krustytheclown2 Registered Member

    Joined:
    Nov 18, 2014
    Posts:
    210
    My host is running Linux with LUKS. My motivation for FDE on the Workstation is to secure that data in case of a cold boot attack scenario, or my laptop being taken while on, rather unlikely so it's probably overkill but hey.

    Where exactly do I put that line of code into the .ovpn? I don't want to mess something up in some way that I don't yet understand fully. The beginning of my config file goes:

    My VPN has both UDP and TCP options for OpenVPN, should I use TCP in the Whonix Workstation since that may work better with Tor?

    And you mentioned torsocks, I know that's how you torify apps, could you please explain how to set pfSense to route everything through that (if that is what you were referring to)? I'm not overly familiar with pfSense or FreeBSD and I don't want to introduce a vulnerability resulting from an oversight of mine...

    Thanks mate
     
  6. mirimir

    mirimir Registered Member

    Joined:
    Oct 1, 2011
    Posts:
    9,252
    OK, so FDE in both host and workspace VM is fine.
    As far as I know, the order of options in OpenVPN config files doesn't matter. But that said, I put the two SOCKS proxy lines near the bottom.
    For tunneling VPN through Tor, you must use TCP mode, because Tor doesn't route UDP.
    I was saying that you need to install torsocks and rinetd in a FDE Debian workspace VM that you're setting up to use instead of Whonix workstation VM. Plus Tor browser, of course. And there's an option in about:config that tells Tor browser not to start a local tor process (to avoid doing Tor through Tor, which isn't recommended).

    I don't recommend switching from Whonix gateway VM to a pfSense Tor gateway VM unless you want to reduce disk usage. The Whonix gateway VM needs less RAM (128 MB) than the pfSense Tor gateway VM (512 MB).
    :)
     
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.