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.
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.
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?
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.
In all seriousness, I think you should consider yourself lucky if you get a slow entry guard. What kind of honeypot operator would have constrained bandwidth and chase away users?
(If you run your own entry guard - Dingledine suggests doing this in one of his posts - does it need to be done anonymously?)
I come back to you after some tests which I need to continue them to have a good general idea.
I wanted to come back to you for something more specific about this bootstrapping problem.
None of you have pointed out or reacted to one of my previous post.
The line where I got “server connection refused” and which I continue to get.
I would really want to clarify the situation about that to move forward with the problem. Don’t hesitate to correct me if one of you have already reacted on this.
By the way, I’m on version 0.3.1.8 for the moment.
From my humble position, I can say with pretty much confidence that nothing is magical in computer science. So any error message have been programmed before. This error message is pretty clear and must have been provisioned in very precised events in the code.
So first, where this message is coming from? Is there a if somewhere in the script of whonix where it is stated?
Second, does someone know exactly why a node from Tor would launch such a signal? Since this error message is always linked to an address ip^which is not mine, which is not from my network or anything related to me.
So why am I asking that? Because after a few weeks of not using whonix in qubesos because of this problem, I 've tried it and put it up to date and for some hours it has worked more or less in a normal way and then suddenly it stopped working. That does tell me that there is actually no really incompatibilities between my setup or equipment with the tor nodes but for what ever reason, the Tor Nodes are communicating something about me, like a signature or something else and banned me from using it. Because if not, this message would not have been created and if those were simply gateways where you want to do whatever you want with any equipment whatsoever, this message would have no reasons to exists and be present in some code somewhere.
So please someone, answer to those precise questions and be as specific as you can.
This is a long thread. Please make it easier for people to help by linking or including post numbers. I assume you’re referring to #15?
Servers can refuse connections for reasons that have nothing to do with you. They can be misconfigured, or down, or under DoS attack for example. What is the IP address in your log? a bridge?
This is not Whonix code. If you want to deep dive into the Tor source, better place to ask is on Tor mailing lists (ie tor-talk):
[It is possible for individual relays to ban your specific IP. I’m nearly certain the Tor network (as a whole) has no mechanism for banning individual clients.]
So I’ve made some tests.
It is not vlan related, nor the switches.
I’ve tested on 2 different models of ubiquiti routers on default ports without any options activate, just default setup on those ports and it’s very likely that something in the firewall of ubiquiti drops packet or something which would be related to whonix but I don’t know why yet. So I will do some capture on the whonix proxyvm and see what it gives.
so here are the capture which are encrypted for obviously reason. So the ones who really want to investigate and help through this can ask me the password.
the names of the capture are normally enough to understand.
So there is one from the wifi from the iphone accesspoint in 4G
then there are 2 directly connected to a “by default” port on a ER5-POE (ubiquiti).
The first try is in the continuity from the connection from the wifi so I restart Tor and then do a whonixcheck.
The second try I completely shutdown the proxyvm and restart it with the command “sudo wireshark” and directly start the capture…
Each try on the ER5-POE does have 2 whonixchecks.
the proxyvm is up to date by the way.
Thanks in advance for all the help. I hope I didn’t let important information in the caputre but I can’t be sure so it would be very kind to anyone to let me know if I let things not supposed to be there.
And I hope that nobody will abuse of it.
here the link to the capture it’s encoded with openssl aes 256 caputre enc
How are you planning on giving out the pasword if requested? Can’t post it on the open forum without everyone seeing it. Some people (anonymous users) would be hesitant about giving out an email address over the forum.
true but those experimented users and network devs who I need would be registered on those forums no?
Plus it’s simple enough these days to put a anonymous mail address and connect to it through tor no?
