I’m going to answer all that but first I would like to remember you that I don’t really how works Tor. I mean in the sense that I don’t how much packet does it sends. If it’s more UDP or TCP. If it’s a new circuit for every webpage you try to open. If it’s a new circuit for each refresh of a page…
And in our little matter here, since you’ve made me install tor inside the vm + the tor browser, how can I configure the tor browser to go through 2 proxies since it has its own proxy with its own instance of tor client + the proxy from tor client that I have installed on the vm ?
Or do you want me to use tor browser configured as it is and alongside of that normal firefox and configure it with the proxy on 9050 from the tor client in the vm ? + the box checked for the dns queries ?
Hi boistordu
Tor only uses TCP. UDP is unsupported.
A new circuit is not created for each new web page or if you refresh your page. You can use either the “New Tor Circuit for this Site” button in the upper left hand corner of Tor Browser.
https://whonix.org/wiki/Tor_Browser#New_Tor_Circuit_Function
Or you can use Arm controller.
Related:
https://whonix.org/wiki/Stream_Isolation
Note: I just want to make sure you are not getting “Create a New Tor Circuit” and “New Identity” confused. Tor Browser also has a “New Identity Function” in the upper left hand corner as well:
https://whonix.org/wiki/Tor_Browser#New_Identity_Function
Another way to get a new identity is to shut down your browser. Then use Arm controller to create a new circuit. Make sure to wait the full 10 seconds it takes to build a circuit before starting Tor Browser again.
See also:
https://whonix.org/wiki/FAQ#New_Identity_and_Tor_circuits
Use Tor Browser Bundle with its default configuration including its built-in Tor client.
Disable system Tor (Tor service) that was installed using apt-get on Debian:
sudo systemctl stop tor.service
sudo systemctl disable tor.service
# or remove it
sudo apt-get remove tor
Read the last part of this post for more info.
Okey let’s start with the ISP questions:
It can’t be a problem around the ISP, because the other places I’ve managed to test it use the same ISP and it worked. More or less fluently, since Tor network’s bandwith are always less than any connection here.
The advantage of the transition to fedora-26 has been that it worsened the problem. Because now at my place I can’t have whonix working nearly at all in every configuration possible on this laptop. And as you’ve seen, the tor package is bootstrapping pretty well on a normal debian distro.
so sys-whonix is not working at all even with sys-net directly connected to it or through sys-firewall. No bootstrapping, no connection available for anon-whonix.
debian-9 (test-tor) was connected/is connected to sys-firewall.
Solution number 1 is not working at all since fedora-26 transition from primary connection but not from other locations.
solution number 2 is working. it working so well actually that, I can make it work through the tor browser bundle or it can work with a simple firefox configure to go through the proxy 9050 of the tor client installed in the debian. It has never failed me since yesterday at noon UTC. ( I was already testing it both case scenario before to ask you the question earlier)
Since wednesday, solution 1 have been working only 3 times for a short period of time. One of these times was when it was connected to a slackware circuit. So I guess that it has successfully been connecting to some circuits and not most of them.
And the whole problem sounds too me as one of my labs of networking in my previous studies, it sounds like packets are not coming back to the emitter. That’s what it sounds like to me. The only factor which are changing from the 4G or the other places, is no ubiquiti equipment and no vlans. And so it must be a bad interaction between whonix vlan creation and then the transmission to ubiquiti equipment. But since whonix is llacking with network tools and that every icmp are filtered, I can’t debug this thing properly like on any other vm or hosts. What I should be able to do is at least with some ping, see where the transmission gets lost and yes somewhere with tcpdump, I don;t know where to put it exactly, I should be able to see the header of the answers with the bad information in it or something like that.
So I’m basically screwed I guess…
Not necessarily, if you have a copper connection ( not fiber optic ) at the location where you are having connection problems it could mean you are to far away from you IPS. Copper can only carry a signal so far and if you are on the fringes of the maximum distance it may be possible to have reliable a clearnet connection but unreliable Tor. Not saying this is the problem but a possibility.
Man I would not be on vdsl2, I would not have 100MB/20MB and I would simply not have reliable connection for everything else.
Plus I’m followig the twitterfeed of the tor project and it doesn’t sound to me that 25.9GiB/s dispatched between 6568 points all avoer the world would be enough to sustain all the traffic at 100MB for everyone… But of course I’m speaking for my case and for everyone this city here, not in the country obviously.
Hi boistordu
Definitely would not be an ISP problem with 100MB/20MB. Possible if 1-5MB. Like you said for someone living way out in the country on the fringes of coverage.
hi,
yup and so it s definetely a problem with whonix vm and vlans/or ubiquiti . But it’s not directly tor related since the debianvm is working perfectly.
So take the next step to confirm. Bypass all of your networking hardware and connect to your ISP directly at your primary location. If the statements above are consistent, then sys-whonix should work. If sys-whonix doesn’t work still, then you need to redo your tests.
You are welcome to use any network diagnostics you want with Whonix and/or Qubes - tcpdump, wireshark, iptables, traceroute, ping, … - but it’s not within the scope of this forum to teach you how. (Frequently Asked Questions - Whonix FAQ)
IMO, it’s much more productive for someone who doesn’t know how to use those tools, to use process of elimination to at least narrow down where the problem lies. These are the pieces that need to be eliminated as problems:
Server (Tor)
ISP
LAN (routers, switches)
NIC (usb, wireless, ethernet, etc)
Qubes sys-net
Qubes sys-firewall
Qubes-Whonix
Since Qubes-Whonix works at another location using all of the same components except LAN, that’s where you need to focus your effort. If Qubes-Debian+Tor works in place of Qubes-Whonix, then there is some interaction between Whonix and your networking equipment that is causing trouble (as you guessed). I have no idea what that might be. And it’s again, beyond the scope of this project to test compatibility with every network vendor. You could use different equipment or contact ubiquiti and try to troubleshoot yourself. We’d be happy to improve Whonix compatibility if you are able to find out why this is happening.
Okey I’m going to the next tests:
- directly connected to the ISP box.
- directly connected to the ubiquiti router on the default vlan
- connected to a ubiquiti switch directly to untagged port
and see the differences. It will certainly take me some days.
Is there any possibilities that the laptop hardware could be the problem here or not at all?
About the tools in whonix, sorry to ask but for me it’s a bit of a blackbox since even ICMP are disabled and so I don’t which other protection can be included in it since the ICMP is the most basic test I should have been able to run from the disposable vm to the gateway just to see if the vlan were effective…,
If you don’t mind installing network debug tools over clearnet… That
would be doable. I.e. configuring whonix-gw / whonix-ws to reach
clearnet so you can install additional packages. Let me know if you like
directions for that.
We should not allow ICMP by default.
But for developer types of people, instructions to unload Whonix firewall is available. It’s of course not advisable since it could break anonymity but perfectly fine to debug network issues.
There are also instructions on how to “unWhonix”, meaning how to make Whonix more similar to Debian to ease figuring out why connectivity is broken.
Sorry, I’ve not been able to follow this forum discussion in detail. I appreciate your persistence and everyone trying to help.
of course thanks for the help patrick and every little piece of information you can give me will be welcomed. And of course I’m not discussing here the need to open or not ICMP packets, it’s jsut that as you well certainly know it’s maybe one of the first things you learn in any networking class to know how to debug a network.
Anyway at some point, I will certainly use tcpdump and wireshark and test link by link to see where is the flaw, and that without touching the firewall at first, if at least there is no other protection than that and so that I can run both programs. It’s the only way that I know to see if packets are received and forwarded.
If I need to install a package and have a connection I can always do that by connecting to my 4G so that’s okey on that part I won’t need normally to configre the template to be able to be directly connected through clearnet.
I will post any discoveries that I can make.
If this wasn’t a privacy distribution, I wouldn’t bother taking one step forward with this issue without having your complete hardware configuration, including model numbers. But on this forum, we have to depend on users providing us all the relevant information while also not providing too much identifying information. In many cases, users don’t know what information is relevant.
So in your case, you have a laptop with 4g, wifi, and ethernet. Have you been using the same interface for all of your tests? including remote locations? If not, then that’s another variable that hasn’t been accounted for.
- Go someplace else. Use Ethernet. See if sys-whonix bootstraps properly.
- Go home. Plug Ethernet directly to ISP. Bootstrap tor again.
(“Use Ethernet” means disabling all other interfaces in sys-net so they don’t randomly connect while you are testing.)
That’s your base good working configuration. Now you can test different network components and different interfaces. It’s inefficient to test random configurations without having a simple baseline.
Since, qubes have been installing without any problem I didn’t think it was relevant no, but now that we reduce the cause of the problem I think it might be.
it’s an old lenovo t430 i5-3230M
the 4G connection was through my Iphone so by wifi from my iphone to the laptop.
the ethernet card is a intel 82579LM rev 04
the wifi is a intel centrino advanced N6205
and wednesday I was someplace else by ethernet cable and the whonix gateway was working but did’nt try a lot so I could have been just lucky. I will try to test anyway more deeply like I said.
just to answer to your question already, yes it bootstrap right away elsewhere with some other equipment.
And if I try to guess which equipment they use because of the name of the vpn box, I think it’s a pfsensebox
entr0py, isn’t my problem (it got slightly better than before) similar? You can see in my thread similar bootstrapping difficulties only with qubes-whonix, but not with qubes-tor.
May I suggest that the bootstrapping problems could relate to poor and/or malicious guards?
I had exactly the same problem as the OP in Qubes-Whonix, bootstrapping was agonizingly slow, took many minutes to finally connect, many circuits were collapsing, weird Tor logs etc.
Simply created a new sys-whonix-clone - with new fresh guards - and viola, Tor connects in seconds. So, this rules out 0.3+ Tor versions, padding, poor local network connections etc as the culprits.
So, I assume that if you hit a really poor guard with limited capacity, or potentially misconfigured, or just one of the malicious turds on the network, this could be the over-riding factor.
Might also explain why one set of guards in a test system e.g. Debian 9 work fine, while the sys-whonix one is terrible i.e. you just lucked out.
torjunkie:
May I suggest that the bootstrapping problems could relate to poor and/or malicious guards?
I had exactly the same problem as the OP in Qubes-Whonix, bootstrapping was agonizingly slow, took many minutes to finally connect, many circuits were collapsing, weird Tor logs etc.
Simply created a new sys-whonix-clone - with new fresh guards - and viola, Tor connects in seconds. So, this rules out 0.3+ Tor versions, padding, poor local network connections etc as the culprits.
So, I assume that if you hit a really poor guard with limited capacity, or potentially misconfigured, or just one of the malicious turds on the network, this could be the over-riding factor.
Might also explain why one set of guards in a test system e.g. Debian 9 work fine, while the sys-whonix one is terrible i.e. you just lucked out.
I understand the reasoning from a user’s point of view. But changing
guards because they are not working is something we should actively
discourage.
Because, perhaps the entry guards are legit, but an attacker slows them
down so the user changes entry guards increasing chances to connect to
malicious ones under the control of the attacker. Slowing down Tor so
the user gives up on it is a known attack by adversaries. It’s an
alternate strategy over fully blocking Tor.
What to do in these cases then? Change the network, use a user → tunnel
→ Tor connection and/or use bridges?
Could you document that please? @torjunkie
I’m not sure what problem you’re referring to. Please link.
Good point. Hadn’t thought of that.
I think it’s safe to rule that out for 2 reasons:
-
Unless it’s been changed again, Tor still uses 2 entry guards (Brainstorm tradeoffs from moving to 2 (or even 1) guards (#9273) · Issues · Legacy / Trac · GitLab) so improbable but not impossible that both guards are bad/dead. Or maybe possible for 1st entry guard to prevent you from using fallback guard. Reason 2 is better.
-
OP has re-installed sys-whonix multiple times. (right @boistordu?)
- Nothing. Use the fallback entry guard.
Improving Tor's anonymity by changing guard parameters | The Tor Project #See Fix 3:
Tor fetches new network status consensus every 2-4 hours.
Dead entry guard will be replaced eventually.
- As Patrick said, best practice is one entry guard per ISP/network, so if you want to replace entry guard set, get a new network first. But this only solves fingerprint problem, still bad to unnecessarily expand guard set in terms of malicious guard exposure.