Torifying a Fedora AppVM

Hello! Welcome back to our course on building your secure ThinkPad.

Introduction

In our previous lessons, we installed Whonix and learned to use the Tor Browser within a dedicated Whonix AppVM. This setup is excellent for anonymous web browsing, as both the browser and the underlying OS are specifically hardened for that purpose.

However, your need for anonymity might extend beyond web browsing. You might want to use command-line tools like git to contribute to a project anonymously, or use other network applications without revealing your IP address.

Today's lesson directly addresses this need. The learning outcome is to route the traffic of a standard Fedora AppVM through the Whonix Gateway to 'torify' a non-Whonix application. This technique dramatically expands the power of your Qubes-Whonix setup, allowing you to apply Tor's anonymity to a wide range of software. We will cover the simple mechanism that makes this possible, a key configuration detail for reliability, and the important security responsibilities that come with this approach.

1. The Principle: Qubes Networking and sys-whonix

From your work with multi-agent systems, you're familiar with the idea of modular components interacting through defined interfaces. Qubes OS applies a similar principle to networking. An AppVM does not connect to the internet directly; it sends all its traffic to a designated NetVM.

Usually, this NetVM is sys-firewall, which in turn uses sys-net. The sys-whonix qube you installed is simply another potential NetVM. However, it's a very special one: its sole purpose is to take all incoming traffic from a client VM and route it exclusively over the Tor network. It is designed to drop any traffic that cannot be sent through Tor.

Therefore, the theory behind "torifying" an entire AppVM is elegantly simple:

1. Create a standard AppVM (e.g., based on Fedora).
2. Change its NetVM setting from the default (sys-firewall) to sys-whonix.

This powerful abstraction is a core feature of the Qubes-Whonix integration. As the Qubes OS forum thread How to share internet from one VM to another... shows, while the principle is simple, users can sometimes be confused by the distinction between TemplateVMs (like whonix-gw-17) and the running service qubes (like sys-whonix). The key is that AppVMs connect to the running sys-whonix NetVM, not the template it's based on.

2. Practical Exercise: Creating a "Torified" Fedora VM

Let's put this into practice. We will create a new, clean AppVM for this purpose.

1. Create a New AppVM:

   • Open the Qubes App Launcher (blue/grey 'Q' icon) and go to Qube Manager.
   • Click Create a new qube.
   • Name it fedora-torified.
   • Set the Type to AppVM.
   • Set the Template to your standard Fedora template (e.g., fedora-39).
   • Crucially, set the Networking to sys-whonix.
   • Click OK.

2. Verify the Tor Connection:

   • Start your new fedora-torified AppVM. Qubes will automatically start sys-whonix if it's not already running.
   • In fedora-torified, open a terminal (Q -> fedora-torified -> Terminal).
   • To check your public IP address, run the following command. curl is a simple tool for making web requests from the command line.

     curl https://check.torproject.org/api/ip
     

   • The command will output a JSON response. You should see two key things:
     • "IsTor": true
     • "IP": An address that is not your real IP. It's the address of a Tor exit node.

You have now successfully routed all traffic from a standard Fedora VM through the Tor network. Any application you run in this VM will now have its traffic anonymized by sys-whonix.

3. A Configuration Detail for Reliability

While the above steps may work out of the box, the official Whonix documentation recommends a small configuration change to the Whonix Gateway for improved reliability when connecting non-Whonix VMs.

The issue relates to ARP (Address Resolution Protocol), the protocol used on a local network to map IP addresses to hardware MAC addresses. The default Whonix-Gateway configuration is very strict about how it responds to ARP queries as a security-hardening measure. This strictness can sometimes prevent it from correctly establishing a connection with a "custom" workstation like our fedora-torified VM.

To ensure robust connectivity, we need to slightly relax this setting.

As you've just read, the fix is to change the arp_ignore setting from 2 to 1. This must be done in the TemplateVM for the change to be persistent.

1. Shutdown sys-whonix. You must do this before you can modify its template.
2. Open a terminal in the whonix-gw-17 TemplateVM. (Q -> Template: whonix-gw-17 -> Terminal).
3. Edit the sysctl configuration file. The sudoedit command is a secure way to edit system files.

   sudoedit /etc/sysctl.d/99_user.conf
   

4. Add the new setting. Add the following line to the file:

   net.ipv4.conf.*.arp_ignore=1
   

5. Save and exit the editor.
6. Shut down the whonix-gw-17 template.
7. You can now restart sys-whonix and your fedora-torified VM. The change is now active and will persist across reboots.

4. Security Implications: The Shift in Responsibility

You've gained a powerful capability, but it comes with a critical trade-off. The standard Whonix-Workstation is not just Debian with its traffic routed through Tor; it is extensively hardened. Dozens of modifications are made to the OS and its applications to prevent IP leaks, resist fingerprinting, and enhance privacy.

When you use a standard Fedora VM, none of that hardening is present. The responsibility for security shifts from the Whonix developers to you.

The Whonix wiki provides an excellent overview of these differences.

Key responsibilities you now assume include:

• Time Synchronization: The sdwdate utility in Whonix securely syncs time over Tor to prevent your real timezone from leaking. A standard Fedora VM does not do this and could leak your location via its time settings.
• Application Hardening: A standard web browser like Firefox in your Fedora VM is not hardened like the Tor Browser. It is highly susceptible to fingerprinting, which could de-anonymize you even though your IP is hidden. This connects directly back to our previous lesson on browser security levels.
• Preventing Tor-over-Tor: If you were to install Tor Browser inside fedora-torified without reconfiguring it, its traffic would be routed through sys-whonix, creating a highly inefficient and potentially less secure Tor-over-Tor connection. The Whonix-Workstation is configured to prevent this automatically.
• Stream Isolation: Whonix-Workstation attempts to route traffic from different applications over different Tor circuits to prevent an adversary from linking your activities. This is not configured in a standard VM.

This is not to say you should never use this technique. It is immensely useful. However, you must be acutely aware of the risks and tailor the use of fedora-torified to your threat model. For general-purpose anonymous browsing, the hardened anon-whonix AppVM is superior. For "torifying" a specific command-line tool, fedora-torified is an excellent solution.

Conclusion

In this lesson, you have successfully extended Tor's anonymity beyond the purpose-built Whonix-Workstation. You now have a general-purpose tool for anonymizing applications within the secure, compartmentalized framework of Qubes OS.

Key Takeaways:

• You can "torify" any AppVM in Qubes by setting its NetVM to sys-whonix.
• A persistent configuration change (arp_ignore=1) in the whonix-gw-17 template ensures reliable connectivity for these custom workstations.
• Using a non-Whonix VM for anonymous tasks is a powerful technique but transfers the responsibility for OS and application hardening to you.
• You must be mindful of risks like timezone leaks, browser fingerprinting, and Tor-over-Tor scenarios when using a custom "torified" VM.

Preview of the Next Lesson:
We have spent several lessons building a robust technical architecture for security and anonymity. However, the strongest castle can be opened from the inside. In our next lesson, we will begin a new module on Operational Security (OpSec), exploring how your personal habits and procedures are just as critical as the technology you use. We will start by defining OpSec and examining how simple user behaviors can undermine complex security systems.