- tor-relays - lists.torproject.org

Re: Having trouble with setting up a relay in a censored country.
by Marco Moock 15 Jan '25

15 Jan '25

Am 15.01.2025 um 16:25:42 Uhr schrieb nyyymi: > > Please post your torrc (without comments). > > and the IP addresses of the machine. > Ip is 192.168.1.113. This is a private IPv4 address, unreachable from the internet by design. You need to set up port forwarding in your router to make it reachable. Did you do that? If your ISP provides IPv6, you need to create a firewall rule in your router to allow access. Because that doesn't use NAT, no port forwarding is needed. > I've let the relay run for a bit, errors started > to accumulate. "Problem bootstrapping. Stuck at 5% (conn): Connecting > to a relay. (Connection timed out; TIMEOUT; count 25.." and "25 > connections died in state connect()ing with SSL state (no SSL object)" Please test ncat -v tr.dorfdsl.de 9001 If that doesn't work, those problems must be first fixed. -- Gruß Marco Send unsolicited bulk mail to 1736954742muell(a)cartoonies.org

1 0

Re: Having trouble with setting up a relay in a censored country.
by Marco Moock 15 Jan '25

15 Jan '25

Am Wed, 15 Jan 2025 16:01:44 +0000 schrieb nyyymi <nyyymi(a)protonmail.com>: > Nickname is nyymi. It doesn't show up on the relay search That is an indicator that something isn't working. Please post your torrc (without comments). and the IP addresses of the machine.

1 0

Having trouble with setting up a relay in a censored country.
by nyyymi 15 Jan '25

15 Jan '25

Hello. For the past few days I've been trying to open a tor-relay on my old laptop running arch. The tor service starts fine but when I check nyx no traffic goes through me, both download and upload is 0. Nyx shows Unknown:portnumber. I doubt that the port is closed or somehow unavailable since arch's defaults are wide open. And for some reason my tor version (0.4.8.13) shows up as "unknown" as well. I thought the issue may lie in torproject's ban in Russia but somehow other people run relays just fine? (https://metrics.torproject.org/rs.html#search/country:ru) I've set up obsf4 as well but It didn't change anything Im quite new in all of this so bear with me. Thanks -Arttu

3 2

Question: Relay speed South Africa
by Carlo P. 15 Jan '25

15 Jan '25

Hello experts, I have, from the same provider, two VPS with same specs (also same port speed of 200MBit/s, verified via speedtest-cli) - one in Germany, one in South Africa. Whilst the German one behaves as expected (two fast relays on it), the two relays in South Africa won't really get up to speed - barely traffic, and advertised bandwidth below 2MB/s . In general, search for country:za on metrics does not really look too impressive. Do you have any idea about the reason, i.e. why, despite the VPS having the bandwidth, the relays do not get up to speed? Thanks - C. -- Sent with https://mailfence.com Secure and private email

3 2

My web-bridges looks offline in the Relay Search
by Brook Rameev 10 Jan '25

10 Jan '25

Hello! Today all my web tunnel relays become offline according to https://metrics.torproject.org/rs.html#search/BrookRameev (my web tunnel bridges have the 'W' suffix). But they are surely online (except BrookRameev7W, which is surely dead). I see traffic on them, I see no problems in logs, nothing changed in their configuration. I also checked them using tor browser. All of them "went down" at the same time: " 1 hour 17 minute and 48 seconds" from the current moment. The problem relates only to webtunnels, ordinal relays work normally. Good luck.

4 5

Tor node shutdown
by Tschador 30 Dec '24

30 Dec '24

FYI: My Tor node »TorMachine« (6A7551EEE18F78A9813096E82BF84F740D32B911) will be shut down on 2024-12-31. Sorry folks – but I'm too old for the job. Good luck and all the best wishes for the future!

3 2

Re: Strange UFW logs from another Tor node - update.
by code9n＠pm.me 30 Dec '24

30 Dec '24

On Thursday, December 26th, 2024 at 12:00, tor-relays-request(a)lists.torproject.org <tor-relays-request(a)lists.torproject.org> wrote: > > > Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > tor-relays-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > Today's Topics: > > 1. Re: What're these ufw block logs saying? (George Hartley) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 24 Dec 2024 19:55:08 +0000 > From: George Hartley hartley_george(a)proton.me > > Subject: [tor-relays] Re: What're these ufw block logs saying? > To: "tor-relays(a)lists.torproject.org" > tor-relays(a)lists.torproject.org, "code9n(a)pm.me" code9n(a)pm.me > > Message-ID: <9ct9ASpMXXnKRo6w2spT3sRh5hspGh1EqSneiQFDwbhNlI4ZZLyU8F2f3 > 3x_KowFg5e-IYk7P0soKNit50FrGm61lKh50WazDZNkCyfJ5qs=(a)proton.me> > > Content-Type: multipart/signed; protocol="application/pgp-signature"; > micalg=pgp-sha512; boundary="------b4924ec6e97f2ee894d2a6644c496d719be > 5fc5bbba1fc1072274ea1ae63bf7c"; charset=utf-8 > > Hello, > > this is weird indeed, but the packet size is interesting. > > For example, using the tool MTR, you can trace the route to another host using different protocols: > > 1.) ICMP being the obvious default. > 2.) TCP. > 3.) UDP. > > If all these TCP packets were just below 100 bytes, that would be my guess. > > Looking up the relay, there is a name, e-mail contact and PGP key ID for this node operator: > > "Tom" > tom(a)kh6ilt.org > 0x620836CF > > Just ask this operator first to check his server for something that could cause this, and if he is running something special alongside Tor. > > Then, if that does not sufficiently explain or resolve the spurious packets, I would recommend to install tcpdump, and to use a syntax like: > > > sudo tcpdump tcp and src host 155.138.146.249 and not dst port 443 -w dump.pcap > > > You will need elevated privileges in order to run tcpdump. > > This will guarantee to exclude all legitimate Tor traffic originating from his server by excluding destination port 443, and log the remaining packets to file "dump.pcap". > > You can add the -i <interface> parameter to the beginning of the tcpdump argument list if you have multiple public interfaces. > > > Like so: > > tcpdump -i eth0 <other arguments> > > > Once the dump is finished, you can send signal 2 / SIGINT if the process is running in the background, or simply press CTRL + C.. both ways lead to a graceful exit of tcpdump: > > > kill --signal 2 tcpdump > > > Now you can inspect the traffic using a GUI tool like Wireshark (highly recommended) which can parse .pcap files and decode / recognize many types of packets. > > Please report back what you find! > > All the best, > -GH > > > On Monday, December 23rd, 2024 at 6:46 PM, code9n via tor-relays tor-relays(a)lists.torproject.org wrote: > > > Hi, > > > re. my (guard / middle relay) : 181.215.226.65 : 443 : http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/rs.ht… > > > I'm getting traffic from another (non-exit) relay : 155.138.146.249 : 9001 : http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/rs.ht… ( CCed) > > > always from port 9001 but to different, high number destination (on my vps) ports which ufw is blocking. > > This isn't Tor traffic I'm blocking, right? That would only come to my ORport? Is this abuse attempts? Under the cover of Tor relay traffic? They're quite infrequent (sample) : > > > Dec 23 14:33:29 xxxxxxxx kernel: [2228957.705152] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=37256 WINDOW=1027 RES=0x00 ACK PSH URGP=0 > > > Dec 23 14:33:34 xxxxxxxx kernel: [2228962.788380] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=37256 WINDOW=1027 RES=0x00 ACK PSH URGP=0 > > > Dec 23 14:52:36 xxxxxxxx kernel: [2230104.586835] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=55546 WINDOW=1027 RES=0x00 ACK PSH URGP=0 > > > Dec 23 14:53:16 xxxxxxxx kernel: [2230144.487410] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=55546 WINDOW=1027 RES=0x00 ACK PSH URGP=0 > > > Dec 23 14:53:54 xxxxxxxx kernel: [2230183.086653] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=55546 WINDOW=1027 RES=0x00 ACK PSH URGP=0 > > > Dec 23 15:16:42 xxxxxxxx kernel: [2231550.336547] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=40 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=40998 WINDOW=0 RES=0x00 ACK RST URGP=0 > > > Dec 23 15:18:15 xxxxxxxx kernel: [2231644.112246] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=40998 WINDOW=1027 RES=0x00 ACK PSH URGP=0 > > > Dec 23 15:22:31 xxxxxxxx kernel: [2231900.117391] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=52 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=40998 WINDOW=0 RES=0x00 ACK RST URGP=0 > > > Dec 23 15:42:30 xxxxxxxx kernel: [2233098.835686] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=32822 WINDOW=1027 RES=0x00 ACK PSH URGP=0 > > > Dec 23 15:43:34 xxxxxxxx kernel: [2233162.852181] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=32822 WINDOW=1027 RES=0x00 ACK PSH URGP=0 > > > Dec 23 15:45:42 xxxxxxxx kernel: [2233290.874044] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=32822 WINDOW=0 RES=0x00 ACK PSH RST URGP=0 > > > Dec 23 16:14:43 xxxxxxxx kernel: [2235032.148940] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=1124 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=47586 WINDOW=1027 RES=0x00 ACK PSH URGP=0 > > > Thanks, > > > Pete > >

1 0

Re: Question about middle relays and common web usage annoyances
by Zachary 29 Dec '24

29 Dec '24

I wanted to chime in. I run an entry-middle relay in my basement connected to 300mbps fiber. It doesn’t push much traffic but it’s mine and I’m proud. The bank where I do my banking blocked our IP. After carefully explaining the situation to their IT team, they contacted their web host and had them whitelist my IP. It changed recently because I registered a new router on my ISP’s network, and they happily whitelisted that one too. My bank is a small town bank where everyone knows everyone, and I’m sure it would be much harder at some big corporate bank. Nonetheless, it’s always possible to make a change! Zachary

1 0

Question about middle relays and common web usage annoyances
by tor＠computhings.be 26 Dec '24

26 Dec '24

Hello, I'm located in Belgium. I keep two small middle relays (no exit, not even guard)… https://metrics.torproject.org/rs.html#details/89B4597169A9DBB171F0B4629C73… https://metrics.torproject.org/rs.html#details/07E3A0DC6AD4A5F07D1AF942626E… If I browse the web using a common browser using the basic services of the ISPs (no torbrowser, no tor network) and at least since may 2023, I've observed that some websites (banks, federal services,…) simply don't respond when I want to open their webpages. If I use another IP from the same locations (using vpn, ssh proxy, whatever), those same websites simply respond and works without issue. If I switch back to the local ISP IP, those are unreachable, and so on. If I contact those ISPs or the banks IT services, for them there are no problem. For me, it's clear that hosting simple middle relays puts my ISPs IPs to some black lists handled by who knows who. If hosting basic middle relays is blocking common web services, it will be hard / nearly impossible for me to encourage family, friends or customers to host a basic middle relays. Maybe there is no need for more and more middle relays, I don't know. Does someone encounter the same kind of annoyances ? regards, tierce

6 5

What're these ufw block logs saying?
by code9n＠pm.me 24 Dec '24

24 Dec '24

Hi, re. my (guard / middle relay) : 181.215.226.65 : 443 : http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/rs.ht… I'm getting traffic from another (non-exit) relay : 155.138.146.249 : 9001 : http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/rs.ht… ( CCed) always from port 9001 but to different, high number destination (on my vps) ports which ufw is blocking. This isn't Tor traffic I'm blocking, right? That would only come to my ORport? Is this abuse attempts? Under the cover of Tor relay traffic? They're quite infrequent (sample) : Dec 23 14:33:29 xxxxxxxx kernel: [2228957.705152] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=37256 WINDOW=1027 RES=0x00 ACK PSH URGP=0 Dec 23 14:33:34 xxxxxxxx kernel: [2228962.788380] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=37256 WINDOW=1027 RES=0x00 ACK PSH URGP=0 Dec 23 14:52:36 xxxxxxxx kernel: [2230104.586835] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=55546 WINDOW=1027 RES=0x00 ACK PSH URGP=0 Dec 23 14:53:16 xxxxxxxx kernel: [2230144.487410] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=55546 WINDOW=1027 RES=0x00 ACK PSH URGP=0 Dec 23 14:53:54 xxxxxxxx kernel: [2230183.086653] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=55546 WINDOW=1027 RES=0x00 ACK PSH URGP=0 Dec 23 15:16:42 xxxxxxxx kernel: [2231550.336547] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=40 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=40998 WINDOW=0 RES=0x00 ACK RST URGP=0 Dec 23 15:18:15 xxxxxxxx kernel: [2231644.112246] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=40998 WINDOW=1027 RES=0x00 ACK PSH URGP=0 Dec 23 15:22:31 xxxxxxxx kernel: [2231900.117391] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=52 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=40998 WINDOW=0 RES=0x00 ACK RST URGP=0 Dec 23 15:42:30 xxxxxxxx kernel: [2233098.835686] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=32822 WINDOW=1027 RES=0x00 ACK PSH URGP=0 Dec 23 15:43:34 xxxxxxxx kernel: [2233162.852181] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=32822 WINDOW=1027 RES=0x00 ACK PSH URGP=0 Dec 23 15:45:42 xxxxxxxx kernel: [2233290.874044] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=32822 WINDOW=0 RES=0x00 ACK PSH RST URGP=0 Dec 23 16:14:43 xxxxxxxx kernel: [2235032.148940] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=1124 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=47586 WINDOW=1027 RES=0x00 ACK PSH URGP=0 Thanks, Pete

2 1