[HOME] [DOWNLOAD] [DOCS] [BLOG] [SUPPORT] [TIPS] [ISSUES] [Priority Support]

TBB New Identity Breaks Tor Control Port / Maximum Connections

#1

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. :slight_smile:

#2

I am on Qubes R3.2. (And on Qubes testing repository - so things break for me before for everyone else.) Tried to reproduce with stable Whonix 13.

It’s a very well written bug report. I could not reproduce this issue.

Can you check in QVMM please the NetVM setting of Disp1, Disp2, etc. please? It should be set to sys-whonix.

Is all DispVM connectivity broken? Or does curl, wget etc. still work after this is happening?

#3

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

#4

I’m having this error too, seems pretty persistent for me.

I’m going to reinstall and create multiples

#5

Please provide the following debug output. Please shutdown all Whonix VMs. Then start just sys-whonix. Start watching the cpfpy log.

tail -f /var/log/control-port-filter-python.log

The reproduce this issue. Once it happened, please provide that log. Please also check if it is still running after this issue happened.

sudo service control-port-filter-python status
#6

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:

nat: PREROUTING
REDIRECT   tcp  --  vif+   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:9052 redir ports 9052

filter: INPUT
ACCEPT     tcp  --  vif+   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:9052

So something is happening between iptables and cpfp in Gateway.
Is there a maximum number of control port connections?

#7

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.

https://www.whonix.org/wiki/Dev/Firewall_Refactoring#How_to_refactor_the_firewall_script_while_being_sure_there_are_no_iptables_changes

Yes, as of Whonix 13, it’s 5. Config:

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

 sudo service control-port-filter-python restart

Have we found the culprit? :slight_smile:

Whonix virtual box Tor Bootstrap error
#8

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. :slight_smile:

I guess it will depend also on outcome of Multi GW recommendation: https://phabricator.whonix.org/T567.

Sounds useful. Gonna have to re-read that a few times on a rainy day.

#9

For the layman, is this problem a risk to my system? Is there a fix needed?

#10

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.

Further reading:
https://www.whonix.org/wiki/Advanced_Security_Guide#Disable_Control_Port_Filter_Proxy
https://www.whonix.org/wiki/Dev/Control_Port_Filter_Proxy