Still Under DDOS, but here is a status update anyway. The Tor network is breaking.
/d/OpSec icon


17,155 subscribers

Anonymous Planet Onion

Discussion of OpSec, Threat Models, Protection, Assessment & Countermeasures.

Vendors: /d/vendor_handbook.

While the focus of this community's OpSec discussions may center around Dark Net (DN) activity, all members of this sub are encouraged to think about, discuss, and share ideas relating to OpSec.

The actual guide to I2P in Qubes + missing config fix

by /u/fineline · 5 votes · 1 week ago

This post is part rant and part information. I am constantly seeing long guides posted on dread that literally just repeat what is in the official docs. I have no idea why people think copy/pasting docs is more useful than just linking to the actual documentation. These copy/pasted versions will quickly go out of date and often miss important details. Let's stop doing that and instead point people to the relevant documentation from the organizations actually building the tools. What is useful are posts that add context, warnings, issues+fixes, etc.

With that said, the OFFICIAL guide to I2P in Qubes/Whonix:


The docs are a bit nitty-gritty, but at a high level, the steps are:

  • create a template VM (like whonix-ws-16-i2p)

  • install I2P in the template and update config

  • create AppVM based on template and use sys-whonix for networking

  • update tor browser to support i2p


As of today (11/22/23) there is an issue with step 7 in the official docs (step 2 above), which say to update the following config file in the template VM:


If you follow the steps exactly, you'll find that this file doesn't exist. That's because it gets created when the service runs. Unfortunately the service will never run on the template VM because the service file /lib/systemd/system/i2p.service.d/40_qubes.conf looks like this:

## Copyright (C) 2020 - 2022 ENCRYPTED SUPPORT LP <>
## See the file COPYING for copying conditions.


Notice the last line, which causes it to fail if it's being run from the template.


The best way to fix this is to do the following on the template:

  • comment out the last line (the condition) in /lib/systemd/system/i2p.service.d/40_qubes.conf

  • run the service sudo systemctl start i2p, which creates the config

  • update the config per the docs

  • uncomment the condition line so i2p doesn't start next time you boot the template

This will ensure the configs exist in the template and thus your AppVM.

I've seen some other fixes involving sed and scripts to run manually that update the config in the AppVM. This is a hack and is annoying. Having the configs actually on the template VM makes more sense IMO.

Comments (8)
/u/FatherBear · 1 votes · 1 week ago · Link

I will add this to my guide, thank you for this information! Previously I have been using a / startup script (in AppVM) to get everything configured in /var, knowing that Qubes i2p config persistence could be fixed via a simple config line is slightly embarrassing, but nevertheless I shall add it. +1

/u/fineline OP · 1 votes · 1 week ago · Link

All good, it took me a while to figure out why the service wasn't starting in the template. Good to know why services won't run on the template, though. Makes sense --don't want want random (potentially malicious) services making changes to the templtae. In this case it seems reasonable to start it up just to create those config files, then turn it back off again.

/u/donkeysquadreborn · -2 votes · 1 week ago · Link

u got source 4 dat?

miss me wit that random code nigga that like taking candy from some dude in a van

/u/fineline OP · 1 votes · 1 week ago · Link

Source for what? And what random code are you talking about?

/u/walter499 Euphoric Psychemist, PhDarknet · 1 votes · 1 week ago · Link

I mean.... well...right? Lol. There's no code at all in your post... just the obvious error that anyone following any guides will get, and then the config file that you can use to fix it.

Anyone running qubes should pretty instantly know exactly what that config file is doing and why, as well as the consequences for changing it per your instructions.

Honestly, if you don't know, and aren't intimately familiar with how qubes separates VMs and Templates and Dom0 etc, and are confused when you see 40_qubes, 30_qubes, 50_user type files, you probably shouldn't be running Qubes at all just yet. It's not even remotely as foolproof as tails, and you can easily break things and de-anonymize yourself and never even know.

/u/fineline OP · 1 votes · 1 week ago · Link

100% agree. Around dread, qubes+whonix are often touted as the most secure and private you can get. While this can be true, I fear many people will assume they're safe just because they're running qubes. Unfortunately, you can easily break anonymity if you don't have some base knowledge of how things work.

/u/AnonymousBH · 1 votes · 6 days ago · Link

Just getting into this and already downloaded whonix, would you be able to link me to a post or something explaining what would break anonymity?

/u/fineline OP · 2 votes · 6 days ago · Link

read through the official whonix docs. tons of good info: dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/wiki/Documentation

here's a good starting point: