Error in whonixcheck: Tor's TransPort was not reachable

Qubes-Whonix
1

In Qubes, with both of the versions I’ve tested, 8.2 and 8.6.6.7, the Whonix-Workstation is reporting this error in whonixcheck:

ERROR: TransPort Test Result: Tor's TransPort was not reachable. (curl exit code: [7] - [Failed to connect to host.])
(if you disabled Tor's TransPort, please disable this check, see whonixcheck /etc/whonix.d/30_whonixcheck_default configuration file.)

ERROR: Stream Isolation Test: Skipped, because TransPort test failed! Can not test stream isolation.

This also seems to be the reason why the Tor Browser shortcuts don’t work for getting the browser downloaded and installed.

The Tor Browser Update Check reports the following error:

ERROR: https://archive.torproject.org/tor-package-archive/torbrowser could not be reached.

...

(Debugging information: curl_status_message: [7] - [Failed to connect to host.])

Wondering TransPort needs to connect with Whonix-Workstation so I can resolve this error and get TransPort working?

Network traffic is opened in the FirewallVM via the following method:

echo "iptables -I FORWARD 2 -s 10.152.152.10 -d 10.152.152.11 -j ACCEPT" >> /rw/config/qubes_firewall_user_script
echo "iptables -I FORWARD 2 -s 10.152.152.11 -d 10.152.152.10 -j ACCEPT" >> /rw/config/qubes_firewall_user_script
2

That that tb-updater package (update-torbrowser) was broken, was because of a bug. It used TransPort (operating system default; Whonix-Gateway as gateway); didn’t use stream isolation (proxy) settings. That is now fixed in tb-updater 0.6. Tested to work without transparent proxy feature as well.

(Will also be fixed in Whonix 9.)

[hr]

What whonixcheck in essence is doing is this:

curl.anondist-orig https://check.torproject.org

(+ settings for enforcing SSL, …)

So if you get that command to work, whonxicheck should work as well. (Just making sure it’s not caused by whonixcheck, although that is unlikely.)

Whonix-Workstation needs to be able to connect to Whonix-Gateway. For TransPort to work, Whonix-Workstation uses Whonix-Gateway as a gateway in /etc/network/interfaces. (But that is already the default.)

No idea why it’s not working in Qubes.

For diagnosing the issue, as setup for finding out what could be missing… You know I am always trying something simpler for comparison. Perhaps if you would figure out how a Debian VM A (like a workstation) can connect to Debian VM 2 (like a gateway) through an internal network… While Debian VM 2 uses IP forwarding. (Whonix-Gateway doesn’t use IP forwarding, but it is a bit similar.) If you get internet to work in Debian VM A in Qubes, you perhaps learned the missing link to get Whonix to work.

[hr]

Another idea for debugging… Maybe a DNS problem?

Maybe try Tor’s TransPort without requiring Tor’s DnsPort.

Simple test command.

curl.anondist-orig 38.229.72.22

More complex test command that should also work fine.

curl.anondist-orig --tlsv1 --proto =https -H 'Host: check.torproject.org' -k https://38.229.72.22 | grep IP
3

[quote=“Patrick, post:2, topic:499”]That that tb-updater package (update-torbrowser) was broken, was because of a bug. It used TransPort (operating system default; Whonix-Gateway as gateway); didn’t use stream isolation (proxy) settings. That is now fixed in tb-updater 0.6. Tested to work without transparent proxy feature as well.

(Will also be fixed in Whonix 9.)[/quote]

Great. This at least takes care of the Tor Browser download, independent of TransPort.

[hr]

I tried the quick commands you mentioned:

curl.anondist-orig https://check.torproject.org
curl.anondist-orig 38.229.72.22
curl.anondist-orig --tlsv1 --proto =https -H 'Host: check.torproject.org' -k https://38.229.72.22 | grep IP

All of those did not work and gave the same error code as whonixcheck.

curl exit code: [7] - [Failed to connect to host.]

[hr]

I’ll likely have to get into this baseline test.

[hr]

Since most Whonix default apps seem pre-configured to route through SocksPort and therefore do work with Tor internet connectivity in Qubes…

The consequence of TransPort not working seems to be just that other additionally installed applications will simply not reach the internet without TransPort working or manual SocksPort configuration.

Seems like nothing compromising anonymity, at least.

4

[quote=“WhonixQubes, post:3, topic:499”]Since most Whonix default apps seem pre-configured to route through SocksPort and therefore do work with Tor internet connectivity in Qubes…

The consequence of TransPort not working seems to be just that other additionally installed applications will simply not reach the internet without TransPort working or manual SocksPort configuration.

Seems like nothing compromising anonymity, at least.[/quote]
Yes.

5

Another idea for debugging transparent proxying… Likely you already know. Just in case or for everyone else. Look how Qubes TorVM does this. If I remember right, they figured it out. So if this is true, there must be a way.

6

Good thought!

Not sure if Qubes ProxyVM networking architecture changes the implementation of this service for TorVM.

[ I’m wanting to move Whonix Qubes from its currently shared FirewallVM networking, to isolated Xen backend networking, and eventually to Qubes ProxyVM networking. ]

Inside the Whonix VMs themselves they should be pre-configured for TransPort connections, so I’m guessing it is something simple missing or misconfigured in the networking between them.

I wonder if this service needs anything extra beyond opened IP addresses between the VMs, like DNS, ICMP, broadcast, etc.

I will keep this TorVM comparison idea in mind for looking into. Thanks!

7

Interesting. Please consider documenting the reasoning/advantages/disadvantages of this on the Dev/Qubes page and eventually ask qubes-dev mailing list if that is a good idea (unless they already stated so).

Inside the Whonix VMs themselves they should be pre-configured for TransPort connections,
Yes.
8

[quote=“Patrick, post:7, topic:499”][quote author=WhonixQubes link=topic=524.msg4071#msg4071 date=1411121446]
[ I’m wanting to move Whonix Qubes from its currently shared FirewallVM networking, to isolated Xen backend networking, and eventually to Qubes ProxyVM networking. ]
[/quote]
Interesting. Please consider documenting the reasoning/advantages/disadvantages of this on the Dev/Qubes page and eventually ask qubes-dev mailing list if that is a good idea (unless they already stated so).[/quote]

Will do.

Edit: Posted this topic: Whonix Forum

9

FYI:

No surprise here, just documenting, that TransPort is not working out of the box in today’s final Whonix 9 release.

Still an ongoing issue for Qubes + Whonix.