Experienced this issue while troubleshooting the domain isolation features of TBB. I don’t usually use the New Identity feature.
TBB 6.0.5 in Qubes 3.1
Appears to be related to Whonix. Unsure if it is Qubes-specific.
To reproduce:
1: launch Whonix-WS dispVM.
2: launch torbrowser
3: click New Identity
4: results in error
whonixcheck in dispVM reports:
[ERROR] [whonixcheck] Tor Bootstrap Result:
Tor's Control Port could not be reached!
whonixcheck in all other appVMs also report same error.
5: close torbrowser
6: whonixcheck connects to control port successfully in all VMs again.
7: interesting part: launch torbrowser again in same dispVM
8: whonixcheck can not connect to control port in any VM again
Seems like a trivial issue but I’d rather err on the side of caution with anything related to the Control Port.
NetVM is correctly set to Whonix-GW. dispVM connectivity is unaffected. In fact, the error-triggering Tor Browser continues to function normally.
Even more strange. This is not reproducible 100% of the time. After I wrote the bug report, a newly launched dispVM did not experience this issue. I tested a further dispVM to confirm the issue and indeed, it caused control port failure.
Just now (after system reboot)
disp2: no issue
disp3: no issue
disp4: control port failure
Was difficult to reproduce this time. Took 15-20 tries. Once it happens, (almost?) every dispVM that is subsequently created experiences the issue.
tail -f /var/log/control-port-filter-python.log
On a working TBB, New Identity results in:
CPFP log - DEBUG - Request: signal newnym
CPFP log - DEBUG - Answer: 250 OK
On a broken TBB, there is nothing logged after sending New Identity
While broken TBB is running, other TBB that send New Identity also do not generate any output.
After closing offending TBB, New Identity results in normal output for all TBB.
sudo service control-port-filter-python status
Status never changes.
I took one additional step. I monitored iptables for incoming packets and indeed, New Identity on all TBB (working or broken) results in incrementing both:
Whonix firewall and cpfpy should not interact. But btw this is a great opportunity to hint at the following chapter. It explains how to create a deterministic dump of iptables rules. Then you could change something or do something. After that you can create a second deterministic dump and then compare both with a diff viewer.
Please try to increase that number. I wonder why we have set it so low. Probably that default was set long before there was Qubes-Whonix a thing. Feel free to set it to 50 or so. Then
I believe so! (As much as my RAM will let me test anyway.) I’m surprised I haven’t run into the issue earlier. It must be because I just never used the control port for anything. I guess if I had run Whonixcheck in all open VMs, I would’ve noticed sooner. It’s nice to know that I can survive without control port - I should disable it altogether now.
The control port has very limited functionality in Whonix - by design to protect you. Should it become non-functional, you’ll mostly lose some usability tools provided by Whonix. You’ll see various error messages as well (sdwdate, whonixcheck, torbrowser). None of these will weaken your anonymity.
However, it is important to note that if you see the error message in the first post, then New Identity is not triggering the circuit reset in the Gateway like it’s supposed to so proceed accordingly.
The workaround / fix is to close Workstations that aren’t needed or to edit /etc/cpfpy.d/30_default.conf to increase the maximum number of concurrent connections.