tor-relays

tor-relays@lists.torproject.org

18 participants
4839 discussions

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

24 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

1 0

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

23 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

1 0

Announcing the shutdown of our Tor Relay "ExitTheMatrix"
by George Hartley 23 Dec '24

23 Dec '24

Hello dear list readers and contributors, We received UDP floods (mostly through DNS Amplification) which were usually 60-70 GBit/s in size, up until a month ago this was not a problem for most of the exit relays lifetime, because we had a custom Tilera sitting between our server and the remaining infrastructure. Since the Tilera hardware was leftover hardware that we initially bought, maintained and installed in agreement with the colocation contract, the DC had no responsibility for it. Last month the Tilera failed, and additionally the DC had constant issues with their line-cards. So, now we just had our 1GbE link and the default 10GbE scrubbing provided by the DC's routers. This was not nearly enough, the largest attack ever we saw after that was reported to be over 140 GBit/s and also knocked some other servers in the same room offline too. These attacks were not directed towards my VM's bridged failover IP on the colocated server that I share with my friend, but towards the game servers he was hosting on his main NIC IP. Right now, every single attack above 10 GBit/s traffic will result in a null-route if it exceeds 60 seconds. This is incredibly cheap for malicious attackers to achieve, so I decided to take the relay offline for good and wipe the keys as well, both on my encrypted online cloud sync provider (MEGA) as well as from my machines MEGASync folder. The fingerprint is / was: 0F8538398C61ECBE83F595E3716F7CE7E4C77B21 If you look it up now, you will see it used to be on my own link for a while, but since we don't have a static IPv4 assignment (VDSL2 is still incredibly popular in rural areas such as the one that I live in), so the constantly changing IP address would have been just a pain in the butt for clients (one forced DSL disconnect every 24 hours). I currently don't have enough money for a decent dedicated server or VM and a host that I can trust which doesn't have too many Tor relays already. In total, according to vnstat, we routed 20TB's of exit traffic per month for the last 3 months, the relay was up for a total of around 292 days with a fresh set of secret keys, the relay before that, same name but different keys, was online for around 60 days while optimizing the hypervisor, libvirtd and guest OS for maximum performance / throughput). According to my calculation, we have contributed roughly ~180 Terabytes of exit traffic, and maybe 500GB's of Guard traffic (this was mainly an exit relay, so I didn't expect much more). I personally have been hosting Tor (Exit) Nodes for almost 10 years under different names and e-mail addresses, and it is definitely a New Year's resolution to continue that fashion. Tor was incredibly helpful for me, so I will continue return the favor. I also will continue to be active on the mailing list to help new people, as long as my time allows for it. Happy Holidays to everyone reading this, I sincerely hope you have a good time with your family and friends. All the best, -GH

1 0

Unable to bind to IPv6
by Eddie 23 Dec '24

23 Dec '24

I had an issue with my VPS that I didn't notice for a while where I had lost my IPv6 addressing. After contacting support they have restored the IPv6 address, but I'm now unable to bind to the address. I've a feeling it's more either my configuration or the VPS configuration at fault, not tor, but I thought I'd throw it out for ideas, as I'm not that confident (yet) with IPv6 stuff. Here's the interface: 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether a6:6a:08:73:42:27 brd ff:ff:ff:ff:ff:ff altname enp0s18 inet xxx.yyy.87.222/26 brd xxx.yyy.87.255 scope global eth0 valid_lft forever preferred_lft forever inet6 aaaa:bbbb:1a:10::1/64 scope global dadfailed tentative valid_lft forever preferred_lft forever inet6 fe80::a46a:8ff:fe73:4227/64 scope link valid_lft forever preferred_lft forever root@fw1475:~# ip -6 route aaaa:bbbb:1a:10::/64 dev eth0 proto kernel metric 256 pref medium fe80::/64 dev eth0 proto kernel metric 256 pref medium default via aaaa:bbbb:1a:10:a46a:8ff:fe73:4227 dev eth0 proto static metric 1024 pref medium And the netplan configuration: root@fw1475:~# netplan status Online state: online DNS Addresses: 127.0.0.53 (stub) DNS Search: . ● 1: lo ethernet UNKNOWN/UP (unmanaged) MAC Address: 00:00:00:00:00:00 Addresses: 127.0.0.1/8 ::1/128 ● 2: eth0 ethernet UP (networkd: eth0) MAC Address: a6:6a:08:73:42:27 (Red Hat, Inc.) Addresses: xxx.yyy.87.222/26 aaaa:bbbb:1a:10::1/64 fe80::a46a:8ff:fe73:4227/64 (link) DNS Addresses: 1.1.1.1 1.0.0.1 Routes: default via xxx.yyy.87.193 (static) xxx.yyy.87.192/26 from xxx.yyy.87.222 (link) aaaa:bbbb:1a:10::/64 metric 256 fe80::/64 metric 256 default via aaaa:bbbb:1a:10:a46a:8ff:fe73:4227 metric 1024 (static) And this is what I get from the IPv6 OR port, determined by commenting/uncommenting the relevant line in my previously working configuration: 2024-12-14T20:36:38.782783+00:00 fw1475 tor[2317]: Dec 14 20:36:38.782 [warn] Failed to parse/validate config: Failed to bind one of the listener ports. 2024-12-14T20:36:38.782821+00:00 fw1475 tor[2317]: Dec 14 20:36:38.782 [err] Reading config failed--see warnings above. Any ideas/help would be gratefully accepted. Cheers, Eddie

3 3

Standalone snowflake proxy re-testing as restricted
by 0x5fcfbd30＠proton.me 21 Dec '24

21 Dec '24

Hey there, I have been running a standalone snowflake proxy for quite some time now. First in a docker container, but now in its own linux container to have more control over it myself. This has worked out great so far with an ephemeral-ports-range of 200 ports. Those are forwarded to the linux container in my router. Since a few days, I noticed a big drop in connections per hour. I restarted the proxy and it tested as restricted even though all ports are properly forwarded and I see the UDP packets reaching the machine via tcpdump. After several restarts, I finally got it to confirm unrestricted but 6 hours later (default re-test period?), its restricted again. Just to rule out the obvious, is it only me having this problem? I'm building from source and git log says: commit f940d7d6efe423c4d7a901a33d34bb51086b4a41 Date: Tue Nov 26 16:19:49 2024 +0000 chore(deps): update module github.com/pion/ice/v4 to v4.0.3 I wonder if this is a problem of my local setup or a bug snowflake itself. Any ideas? Best regards, 0x5fcfbd30

3 3

Tor activities at 38th Chaos Communication Congress, Hamburg, 2024
by gus 20 Dec '24

20 Dec '24

Hello, Join us for Tor activities @ 38th Chaos Communication Congress (38C3): https://events.ccc.de/congress/2024/ The 38th Chaos Communication Congress runs from December 27 to 30, 2024 in Hamburg. We've got a lineup of Tor activities happening during this congress! - December 28: "Guardians of the Onion" (20:30 - 21:30, Day 2): (live streaming, recorded) https://events.ccc.de/congress/2024/hub/en/event/guardians-of-the-onion-ens… - December 29: "Tor Relay Operator meetup & State of the Onion Operators" (23:00 - 01:00, Day 3): https://events.ccc.de/congress/2024/hub/en/event/tor-relay-operators-meetup… - December 30: "All things Tor related!" (11:00 - 13:00, Day 4): https://events.ccc.de/congress/2024/hub/en/event/tor/ - Tor Project assembly (near Cold North/BornHack assembly): https://events.ccc.de/congress/2024/hub/en/assembly/tor-project/ See you there! \o/ Gus -- The Tor Project Community Team Lead

1 0

Next Tor Relay Operator Meetup - December 7th 2024 @ 1900 UTC
by gus 17 Dec '24

17 Dec '24

Dear Relay operators, Save the date! Our next online meetup is happening on Saturday, December 7th, 2024 at 1900 UTC[1]. I'm happy to announce that we'll have a special guest, Ben Collier, joining us to discuss his new book:"Tor: From the Dark Web to the Future of Privacy."[2] (2024) ## Agenda 1. Announcements - New WebTunnel bridges campaign - https://blog.torproject.org/call-for-webtunnel-bridges/ - Upcoming in-person events 2. Ben Collier's book presentation & discussion ## How to join Meetup details: - Room link: https://tor.meet.coop/gus-og0-x74-dzn - Date & Time: Saturday, December 7th, 2024 @ 19.00 UTC - Duration: 60 to 90 minutes - Tor Code of Conduct: https://community.torproject.org/policies/code_of_conduct/ - Registration: No need for a registration or anything else, just use the room link above. The room will open 10 minutes before the meetup starts. ## DON'T MISS SOTO This month, the Tor team was very busy with State of the Onion (SOTO), and I'd like to invite you all to watch the videos: - Community Day: https://www.youtube.com/watch?v=EODNtLqD7f8 - Tor Project Teams update: https://www.youtube.com/watch?v=HjPdReNmf_g cheers, Gus [1] If you're confused about UTC and your timezone, @anarcat maintains a cool project called undertime - https://gitlab.com/anarcat/undertime [2] "Tor: From the Dark Web to the Future of Privacy" book is available here: https://direct.mit.edu/books/oa-monograph/5761/TorFrom-the-Dark-Web-to-the-… -- The Tor Project Community Team Lead

2 3

install OBFS4
by Keifer Bly 13 Dec '24

13 Dec '24

Hi, So for Debain 12, what is the command to install OBFS4? For my bridge at https://metrics.torproject.org/rs.html#details/0E547D99DEB753B20A19EEAA053C… Even though I configured obfs4 in torrc its saying no transport protocols. Thanks. The torrc Nickname udeservefreedom ORPort <hidden> Log notice file /var/tornitces.log/notices.log SocksPort 0 BridgeRelay 1 PublishServerDescriptor bridge BridgeDistribution email ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy ServerTransportListenAddr obfs4 0.0.0.0:<hidden> ExtOrPort auto ExitPolicy reject *:* ContactInfo keiferdodderblyyatgmaildoddercom --Keifer

4 6

Question about WebTunnel bridge
by apfelnymous＠tutanota.de 11 Dec '24

11 Dec '24

Hi, can I run a webtunnel bridge on the same device that already runs a common bridge ? I have 1 bridge relay running 24/7, I could setup another machine for the webtunnel bridge but I can't get another ipv4 . Should I put it down and replace with a webtunnel bridge ? Thoughts ? Cheers

1 0

Tor Relay via Tailscale Funnel?
by Derek Martin 07 Dec '24

07 Dec '24

Long time lurker. Saw the call for more middle relays. I have a large amount of spare capacity on my homeserver and 2.5GB fiber to the house. Is there precedent for running a relay through a Tailscale Funnel? I would need to check to make sure Tailscale TOS was okay with it, but to my ISP, it'd just look like Wireguard traffic. Any thoughts or fools errand?

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays