0

I'm using qubes for some times now.

after some weeks to correctly configure my setup, I want to figure it out why sys-whonix is not working correctly with my setup.

so I closely look at the other threads with one same criteria, the message in the logs : ("server rejected connection")

one in particular attracted my attention. So I've tested some advices on this same website. So I've connected through the wifi access point from my phone and through my LAN wired network. The differences are heavy.

first some informational point:

  • the LTE data network and my VDSL2 Line are from the same provider which is Proximus in Belgium (important point to dissipate any doubt about the fact if I'm in a restricted area or not).

  • My LAN Network is organised with VLANs through managed switches and then through a router which is connected wiredly to an ISP box/router but its my router which does the PPPOE connection not the ISP box.

  • I didn't do a DMZ zone for this qubes client but the router/firewall rules are pretty basics

  • My work/personal life are sort of mixed with the justice department and to my knowledge there are no specific filters from ISP in belgium but I could be wrong if I am don't hesitate to correct me.

  • I have pinged all the bridges and all except one answered.

So here are the logs through the LTE access point:

Events (TOR/ARM NOTICE - ERR):
 12:48:28 [WARN] Proxy Client: unable to connect to xxxxxxxxx:xxxxx ("server rejected connection") [2 duplicates hidden]
 12:48:28 [WARN] Proxy Client: unable to connect to xxxxxxxxx:xxxxx ("server rejected connection") [2 duplicates hidden]
 12:48:28 [WARN] Proxy Client: unable to connect to xxxxxxxxx:xxxxx ("server rejected connection") [2 duplicates hidden]
 12:28:55 [NOTICE] Tried for 120 seconds to get a connection to [scrubbed]:80. Giving up. (waiting for rendezvous desc) [1 duplicate hidden]
 12:28:35 [NOTICE] New control connection opened. [7 duplicates hidden]
 12:26:34 [NOTICE] New control connection opened from 127.0.0.1. [3 duplicates hidden]
 12:26:30 [WARN] Socks version 71 not recognized. (Tor is not an http proxy.)
 12:26:29 [NOTICE] Bootstrapped 100%: Done
 12:26:29 [NOTICE] Tor has successfully opened a circuit. Looks like client functionality is working.
 12:26:28 [NOTICE] Bootstrapped 90%: Establishing a Tor circuit
 12:26:28 [NOTICE] new bridge descriptor 'niffierlaterals' (fresh): $F68BBB77DA245790969057EE608E6B14283655EB~niffierlaterals at xxxxxxxxx:xxxxx
 12:26:27 [ARM_NOTICE] Unable to prepopulate bandwidth information (insufficient uptime)
 12:26:27 [ARM_WARN] The torrc differs from what tor's using. You can issue a sighup to reload the torrc values by pressing x.
   - configuration values are missing from the torrc: HiddenServiceStatistics, RunAsDaemon
 12:26:27 [ARM_NOTICE] Tor is preventing system utilities like netstat and lsof from working. This means that arm can't provide you with connection information. You can change this by adding 'DisableDebuggerAttachment 0' to
   your torrc and restarting tor. For more information see...
   https://trac.torproject.org/3313
 12:26:27 [ARM_NOTICE] No armrc loaded, using defaults. You can customize arm by placing a configuration file at '/home/user/.arm/armrc' (see the armrc.sample for its options).

here are from the wired network

 13:12:53 [NOTICE] Tried for 120 seconds to get a connection to [scrubbed]:0. Giving up. [60 duplicates hidden]
 13:12:53 [NOTICE] Bootstrapped 100%: Done
 13:12:53 [NOTICE] Tor has successfully opened a circuit. Looks like client functionality is working.
 13:12:53 [NOTICE] Bootstrapped 90%: Establishing a Tor circuit
 13:12:53 [NOTICE] Bootstrapped 80%: Connecting to the Tor network
 13:12:51 [NOTICE] Bootstrapped 25%: Loading networkstatus consensus
 13:12:50 [NOTICE] Tried for 120 seconds to get a connection to [scrubbed]:0. Giving up. (waiting for circuit) [69 duplicates hidden]
 13:10:39 [NOTICE] Tried for 120 seconds to get a connection to [scrubbed]:443. Giving up. [2 duplicates hidden]
 13:09:58 [WARN] Proxy Client: unable to connect to xxxxxxxxx:xxxxx ("server rejected connection")
 13:09:58 [WARN] Proxy Client: unable to connect to xxxxxxxxx:xxxxx ("server rejected connection")
 13:09:58 [WARN] Proxy Client: unable to connect to xxxxxxxxx:xxxxx ("server rejected connection")
 13:08:21 [WARN] Proxy Client: unable to connect to xxxxxxxxx:xxxxx ("TTL expired")
 13:08:21 [WARN] Proxy Client: unable to connect to xxxxxxxxx:xxxxx ("TTL expired")
 13:07:54 [ARM_WARN] The torrc differs from what tor's using. You can issue a sighup to reload the torrc values by pressing x.
   - configuration values are missing from the torrc: HiddenServiceStatistics, RunAsDaemon [2 duplicates hidden]
 13:07:54 [ARM_NOTICE] Reconnected to Tor's control port [1 duplicate hidden]
 13:07:50 [ARM_NOTICE] Tor control port closed [1 duplicate hidden]
 12:26:27 [ARM_NOTICE] Unable to prepopulate bandwidth information (insufficient uptime)
 12:26:27 [ARM_NOTICE] Tor is preventing system utilities like netstat and lsof from working. This means that arm can't provide you with connection information. You can change this by adding 'DisableDebuggerAttachment 0' to
   your torrc and restarting tor. For more information see...
   https://trac.torproject.org/3313
 12:26:27 [ARM_NOTICE] No armrc loaded, using defaults. You can customize arm by placing a configuration file at '/home/user/.arm/armrc' (see the armrc.sample for its options).

So with the LTE network I had immediately a connection. Between the two tests I've of course restart tor and ask it to reconnect. When I was on the wired network like always, I had some but mostly no connection. You can notice it in the logs and through the timestamp too.

So is it my ISP preventing me to go to Tor? Is it a problem with my router setup ? Is it something else in my wired networked? Does these messages of server rejected connection come from the bridge itself or is it a generic message from ARM? What should I do to have access permanently to Tor through my wired network? Which tests should I do and how to proceed? Should I add pages and pages of bridges?

Here is the configuration of tor user configuration file from sys-whonix. 

DisableNetwork 0
UseBridges 1
ClientTransportPlugin obfs2,obfs3 exec /usr/bin/obfsproxy managed
ClientTransportPlugin obfs4 exec /usr/bin/obfs4proxy

bridge obfs4 xxxxxxxxx:xxxxx 4F815C00771B178C0EB06FDB7293BDB1BD353E03 cert=VaCBcwj1MO3waCsl+Yq/Vuu20dP7fKI92fsvpoMTqlkOHROk/RnX4tx1oFhP7E9YWaOZFA iat-mode=2
bridge obfs4 xxxxxxxxx:xxxxx 08077A0B1248B8FC1E7C114771D3C7A9A3954D71 cert=0jrTOIV/73tSsFwi79k4Vo5rNkmIdK39SlNgv/JUOTS/yRFzeyuSr4DrkwF+Wj+lTJnHSg iat-mode=2
bridge obfs4 xxxxxxxxx:xxxxx E58F54184935689AC7BFD983FB887AFE2D443B4D cert=S+0Tez9y9+q6LUsi658pYXzDHfS+dpSS8UHMsy3OXQvuvA8GtnoQNkWG1KmihXZqt6Yqdg iat-mode=2


bridge obfs3 xxxxxxxxx:xxxxx F4B33297F39EC5CF2EFD0E3D2F3EB87EC8428237
bridge obfs3 xxxxxxxxx:xxxxx 2C3FDA0289A5627ECB582C0A61620780473A46FD

bridge obfs4 xxxxxxxxx:xxxxx F68BBB77DA245790969057EE608E6B14283655EB cert=lxPxDTtghn56dGKbQ2vicevpXiUHNzJpSxCLMd76A8MhbKPVQqurd9Uf4sx7yOfYDA5dBw iat-mode=0
bridge obfs4 xxxxxxxxx:xxxxx F4B33297F39EC5CF2EFD0E3D2F3EB87EC8428237 cert=Ax+LafRJEU1v5BGdXV0To86Vs+gr+EPbIvOZE3iL/fAY3pxScQppxW5y8e03DSCJuqZlCA iat-mode=0
bridge obfs4 xxxxxxxxx:xxxxx D28E0345809AE4BAC903EF7FC78CAAF111A63C58 cert=DtNNYXeRG4ds+iTM7sdbJHJgH7RmxDb1lt8JR17BiT7eHnORyn+4y+RcoqAI65XGvhXKJg iat-mode=0

I've added some bridges of different kind based on the advices here. And all the addresses come from whonix.

Improve this question
3
  • ftr you can consolidate both ClientTransportPlugin lines to ClientTransportPlugin obfs3,obfs4 /usr/bin/obfs4proxy but it looks like some of your bridges are down. "pinging" them won't help judge if the actual bridge and pluggable transport is available.
    – cacahuatl
    Commented Oct 10, 2017 at 2:31
  • I would hazard a guess though, that if both are using the same set of bridges (on LTE is manages to get at least one descriptor and a working circuit), and one of them connects and the other doesn't, that there is a problem in the network configuration either within Qubes or upstream on the wired network.
    – cacahuatl
    Commented Oct 10, 2017 at 2:40
  • Yeah, I'm totally ready to believing it but I can't think about one single settings that could intervene specifically on this thing and have that king of repercussions.
    – vigilian
    Commented Oct 10, 2017 at 7:20

1 Answer 1

Reset to default
0

Well, looks like wired connection is censored or very slow while reaching the bridges. You don't need DisableNetwork 0 in most of the cases - it is zero from the very beginning, unlsess explicitly set to 1. Any ARM_XXX message is ARM related, not tor related, so they're not a concern at all. One question to clarify the things - wh do you need a bridges on wired connection? On mobile connection - yes, the reason is quite ubiquitous, but why don't you use direct connection on wired? However, it must work at least faster on wired rather than on mobile even with the same bridges. What the hardware do you have on wired connection? Please attach the data requested - and I'll be glad to help you further!

Improve this answer
22
  • So sorry for the delay of answer.
    – vigilian
    Commented Nov 1, 2017 at 13:22
  • Bridges was to test to see if problems go away. Since then I have a clean install again and still have problems. The circuits according to onioncircuits doesn't Last very long. How is it supposed to be? For hardware point of view laptop -> basic switch on untagged vlan -> ubiquiti managed switch on tagged and untagged vlan -> ubiquiti router which manages vlan -> pppoe connect -> isp box
    – vigilian
    Commented Nov 1, 2017 at 13:33
  • ubiquiti is a CRAPWARE - just retired some of their stuff recently on one problematic case(not just tor related): tor and ANY app that uses a lot of TCP(especially the troublestarter with U-stuff, tor uses TCP) or UDP(U-stuff drops them) connections at the same time makes it lag, if you powercycle it for 20 seconds powered off - it restores the proper work for a while(18-48 hours in the case I'm referring to). isp box that accepts pppoe is a BRAS device - they holded even 10 years ago a 500000 tcp sessions in realtime easily, so no concern. [continuing on next comment]
    – Alexey Vesnin ♦
    Commented Nov 1, 2017 at 13:42
  • pppoe as well - yes, it's not THAT good as L2TP, but 20000+ TCP sessions is not a problem at all for the protocol. So how long your circuits are living? More than 60,120 seconds or less? Can you please give some stats for a circuit lifetime?
    – Alexey Vesnin ♦
    Commented Nov 1, 2017 at 13:44
  • It s a of course a possibility that's a ubiquiti related problem but would I not have some problems then on the tor browser on a simple windows machine? Or with my numerous vms or my torrents box or even the game then? But don't worry I don't put aside this possibility but I would nt have anything to replace it so it would nt be a solution to retire my equipment. For the pppoe I don't have any other solution than that so same conclusion. How could I provide you good stats about it which would not be related to any feelings? I rarely goes to the successful state ->2 comments
    – vigilian
    Commented Nov 1, 2017 at 13:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .