- tor-relays - lists.torproject.org

All of my nodes have been banned
by petition_tricky750＠simplelogin.com 20 Jan '25

20 Jan '25

Hello, What are some of the most common reasons for relays and exits to be banned from Tor? Had it happen to all of my 5 nodes and I'm currently awaiting response from bad-relays list. They all present this in logs Jan 18 20:41:40 example.com Tor[2439671]: http status 400 ("Fingerprint and/or ed25519 identity is marked rejected -- if you think this is a mistake please set a valid email address in ContactInfo and send an email to bad-relays(a)lists.torproject.org mentioning your fingerprint(s)?") response from dirserver 204.13.164.118:80. Please correct. All of them have been running just fine before 4E1E745FF661657E3D3CE10DF1A1AEEF1D3F7996 2D9D4F0D298C68044F2476DFCB191CEBCE7AC860 078B7B30953A6DA8BB73612035BB876EA90847E3 DE3550EBB205660730900C05B6330B663CEED25434A09907FB89BE444A0A456C12A1A9C54CCF1A8A I'm genuinely curious if others also had it happen to them, and the reason behind it. Thank you.

2 2

Possible attack on servers via Tor Guard relays?
by x9p 19 Jan '25

19 Jan '25

Hi, I am running a relay and other servers. Sometimes doing SSHD over Tor via a hidden service in a VPS in openbsd.amsterdam. In all my other setups, in other providers, I do not see this problem happening. Upon connecting for the first time, I do get a "banner line contains invalid characters" error, and the connection is terminated. (MSG1) Upon connecting for the second time, everything goes smooth. (MSG2) Problem is happening on my 2 servers in openbsd.amsterdam. Any directions into debugging this problem? Both via Tor or via SSHD? Is it possible a bad guard is logging the IPs first connecting, then dropping the connection, and then allowing the connection to succeed later? Any directions would be appreciated to solve the problem. System: uname -a OpenBSD xxxx.yyyy.com 7.6 GENERIC#501 amd64 Tor version: Tor version 0.4.8.13. MSG1 (BAD): localhost:~# torify ssh -v ams02 OpenSSH_9.9p1, OpenSSL 3.3.2 3 Sep 2024 debug1: Reading configuration data /root/.ssh/config debug1: /root/.ssh/config line 284: Applying options for ams02 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 22: include /etc/ssh/ssh_config.d/*.conf matched no files debug1: Connecting to ngbjd5vpxamy5d63hcflinghioo2qa5e75uiysscmo4ml5qd4rpaobid.onion [127.42.42.0] port 60113. debug1: Connection established. debug1: identity file /root/.ssh/oams002_2 type 0 debug1: identity file /root/.ssh/oams002_2-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_9.9 kex_exchange_identification: banner line contains invalid characters banner exchange: Connection to 127.42.42.0 port 60113: invalid format MSG2 (OK): localhost:~# torify ssh -v ams02 OpenSSH_9.9p1, OpenSSL 3.3.2 3 Sep 2024 debug1: Reading configuration data /root/.ssh/config localhost:~# torify ssh -v ams02 OpenSSH_9.9p1, OpenSSL 3.3.2 3 Sep 2024 debug1: Reading configuration data /root/.ssh/config debug1: /root/.ssh/config line 284: Applying options for ams02 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 22: include /etc/ssh/ssh_config.d/*.conf matched no files debug1: Connecting to ngbjd5vpxamy5d63hcflinghioo2qa5e75uiysscmo4ml5qd4rpaobid.onion [127.42.42.0] port 60113. debug1: Connection established. debug1: identity file /root/.ssh/oams002_2 type 0 debug1: identity file /root/.ssh/oams002_2-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_9.9 debug1: Remote protocol version 2.0, remote software version OpenSSH_9.9 debug1: compat_banner: match: OpenSSH_9.9 pat OpenSSH* compat 0x04000000 debug1: Authenticating to ngbjd5vpxamy5d63hcflinghioo2qa5e75uiysscmo4ml5qd4rpaobid.onion:60113 as 'xxxxxxxxxx' debug1: load_hostkeys: fopen /root/.ssh/known_hosts2: No such file or directory debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: sntrup761x25519-sha512 debug1: kex: host key algorithm: ssh-ed25519 debug1: kex: server->client cipher: chacha20-poly1305(a)openssh.com MAC: <implicit> compression: none debug1: kex: client->server cipher: chacha20-poly1305(a)openssh.com MAC: <implicit> compression: none --x9p

3 2

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