Hi
a big German provider "Deutsche Telekom" has started blocking access (at TCP layer) to their SIP servers in February 2026.
That means running a middle tor on this provider line results in a non-functional provider SIP service.
You have to choose between running a middle tor or a working provider SIP service.
_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org
So that means Deutsche Telekom monitors Internet traffic (or at least
the Tor directory, which contains all the nodes) and detects when a Tor
node is being operated. And if that is the case, TCP access to the SIP
servers is blocked? Or have I misunderstood something here?
On Sat, 14 Feb 2026 13:50:55 -0000 iji--- via tor-relays <tor-relays@lists.torproject.org> wrote:
Hi
a big German provider "Deutsche Telekom" has started blocking access (at TCP layer) to their SIP servers in February 2026.
That means running a middle tor on this provider line results in a non-functional provider SIP service.
You have to choose between running a middle tor or a working provider SIP service.
_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org
--
Marek Küthe
m.k@mk16.de
er/ihm he/him
They probably use this blocklist, as do many websites, especially banks and email providers.
https://mxtoolbox.com/problem/blacklist/dan-tor
This means they don’t have to monitor internet traffic themselves.
Am 16.02.26 um 23:10 schrieb Marek Küthe via tor-relays:
So that means Deutsche Telekom monitors Internet traffic (or at least the Tor directory, which contains all the nodes) and detects when a Tor node is being operated. And if that is the case, TCP access to the SIP servers is blocked? Or have I misunderstood something here? On Sat, 14 Feb 2026 13:50:55 -0000 iji--- via tor-relays [<tor-relays@lists.torproject.org>](mailto:tor-relays@lists.torproject.org) wrote:Hi a big German provider "Deutsche Telekom" has started blocking access (at TCP layer) to their SIP servers in February 2026. That means running a middle tor on this provider line results in a non-functional provider SIP service. You have to choose between running a middle tor or a working provider SIP service. _______________________________________________ tor-relays mailing list -- [tor-relays@lists.torproject.org](mailto:tor-relays@lists.torproject.org) To unsubscribe send an email to [tor-relays-leave@lists.torproject.org](mailto:tor-relays-leave@lists.torproject.org)_______________________________________________ tor-relays mailing list -- [tor-relays@lists.torproject.org](mailto:tor-relays@lists.torproject.org) To unsubscribe send an email to [tor-relays-leave@lists.torproject.org](mailto:tor-relays-leave@lists.torproject.org)
--
PGP Key ID: 29D319F8
Hello.
Juergen Lanzki wrote:
They probably use this blocklist, as do many websites, especially
banks and email providers.
Has anyone in the industry tried contacting mxtoolbox and getting them
to stop using the DAN list? Obviously that Dan guy will never stop
listing non-exits because he personally hates Tor, but mxtoolbox could
use Tor Project's own blacklist.
Plenty of reputable blacklist providers, while not "Tor-friendly" per
se, do understand that exit operators are not responsible for the
traffic going through and, importantly, that non-exits are harmless (for
example, IPInfo does this).
I almost lost a relay because the hosting provider got spooked that I
suddenly got their IP on a "blacklist" and had a hard time understanding
that mxtoolbox including DAN's shit does not mean I was sending spam.
Regards,
forest
_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org
And either don’t understand the difference between all tor nodes and exit nodes. Or can’t be bothered to find out.
On 2/17/2026 1:10 AM, Juergen Lanzki via tor-relays wrote:
They probably use this blocklist, as do many websites, especially banks and email providers.
https://mxtoolbox.com/problem/blacklist/dan-tor
This means they don’t have to monitor internet traffic themselves.
Am 16.02.26 um 23:10 schrieb Marek Küthe via tor-relays:
So that means Deutsche Telekom monitors Internet traffic (or at least the Tor directory, which contains all the nodes) and detects when a Tor node is being operated. And if that is the case, TCP access to the SIP servers is blocked? Or have I misunderstood something here? On Sat, 14 Feb 2026 13:50:55 -0000 iji--- via tor-relays [<tor-relays@lists.torproject.org>](mailto:tor-relays@lists.torproject.org) wrote:Hi a big German provider "Deutsche Telekom" has started blocking access (at TCP layer) to their SIP servers in February 2026. That means running a middle tor on this provider line results in a non-functional provider SIP service. You have to choose between running a middle tor or a working provider SIP service. _______________________________________________ tor-relays mailing list -- [tor-relays@lists.torproject.org](mailto:tor-relays@lists.torproject.org) To unsubscribe send an email to [tor-relays-leave@lists.torproject.org](mailto:tor-relays-leave@lists.torproject.org)_______________________________________________ tor-relays mailing list -- [tor-relays@lists.torproject.org](mailto:tor-relays@lists.torproject.org) To unsubscribe send an email to [tor-relays-leave@lists.torproject.org](mailto:tor-relays-leave@lists.torproject.org)
--
PGP Key ID: 29D319F8
_______________________________________________
tor-relays mailing list -- [tor-relays@lists.torproject.org](mailto:tor-relays@lists.torproject.org)
To unsubscribe send an email to [tor-relays-leave@lists.torproject.org](mailto:tor-relays-leave@lists.torproject.org)
Someone much wiser than me once said something like this:
"When you are hit by arrows, nothing changes unless you deal with the archer."
So there you go, have a chat with that DAN list guy...
In essence, if theres a blocklist, folks will use it for convenience.
In case if you haven't already noticed, convenience tends to win when it comes to humans, by a large margin.
Hth,
Markus
* forest-relay-contact--- via tor-relays <tor-relays@lists.torproject.org> wrote:
Has anyone in the industry tried contacting mxtoolbox and getting them
to stop using the DAN list?
_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org
OS: Debian Gnu/Linux 13
Kernel: Linux localhost 6.18.9+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.18.9-1~bpo13+1 (2026-02-13) x86_64 GNU/Linux
Tor: 0.5.0.0-alpha-dev-20260228T020412Z-1~d13.trixie+1 amd64
Error:
17:53:23[root@localhost /etc/tor]# systemctl status tor@default.service -l
● tor@default.service - Anonymizing overlay network for TCP
Loaded: loaded (/usr/lib/systemd/system/tor@default.service; enabled-runtime; preset: enabled)
Active: active (running) since Sat 2026-02-28 17:38:03 CST; 15min ago
Invocation: 84d0ae63461142e3b60155fec8eea98a
Process: 983041 ExecStartPre=/usr/local/bin/rand.sh >/dev/null 2>&1 (code=exited, status=0/SUCCESS)
Process: 983065 ExecStartPre=/usr/bin/install -Z -m 02755 -o debian-tor -g debian-tor -d /run/tor (code=exited, status=0/SUCCESS)
Process: 983067 ExecStartPre=/usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0 --verify-config (code=exi>
Main PID: 983069 (tor)
Tasks: 29 (limit: 18751)
Memory: 109.4M (peak: 113.4M)
CPU: 15.777s
CGroup: /system.slice/system-tor.slice/tor@default.service
├─983069 /usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0
├─983074 /usr/bin/lyrebird
├─983076 /usr/bin/snowflake-client -url https://snowflake-broker.torproject.net.global.prod.fastly.net/ -front cdn.sstatic.net -ice stun:stun.l.google.>
└─983079 /usr/bin/obfs4proxy
2月 28 17:53:24 localhost Tor[983069]: Managed proxy “/usr/bin/lyrebird” having PID 991291 terminated with status code 255
2月 28 17:53:25 localhost Tor[983069]: Server managed proxy encountered a method error. (webtunnel unimplemented)
2月 28 17:53:25 localhost Tor[983069]: Managed proxy ‘/usr/bin/lyrebird’ was spawned successfully, but it didn’t launch any pluggable transport listeners!
2月 28 17:53:25 localhost Tor[983069]: Managed proxy “/usr/bin/lyrebird” having PID 991298 terminated with status code 255
2月 28 17:53:26 localhost Tor[983069]: Server managed proxy encountered a method error. (webtunnel unimplemented)
2月 28 17:53:26 localhost Tor[983069]: Managed proxy ‘/usr/bin/lyrebird’ was spawned successfully, but it didn’t launch any pluggable transport listeners!
2月 28 17:53:26 localhost Tor[983069]: Managed proxy “/usr/bin/lyrebird” having PID 991306 terminated with status code 255
2月 28 17:53:27 localhost Tor[983069]: Server managed proxy encountered a method error. (webtunnel unimplemented)
2月 28 17:53:27 localhost Tor[983069]: Managed proxy ‘/usr/bin/lyrebird’ was spawned successfully, but it didn’t launch any pluggable transport listeners!
2月 28 17:53:27 localhost Tor[983069]: Managed proxy “/usr/bin/lyrebird” having PID 991314 terminated with status code 255
On Wed, Feb 25, 2026 at 12:22 PM Marco Moock via tor-relays <tor-relays@lists.torproject.org> wrote:
On 23.02.2026 11:14 <gerard@bulger.co.uk> wrote:
Auto-discovered IPv6 address [2a00:da00:f460:f800::1]:443 has not
been found reachable. However, IPv4 address is reachableYet is says
09:36:45 [NOTICE] Heartbeat: Tor’s uptime is 10:21 hours, with 14231
circuits open. I’ve sent 602.28 GB and received 594.50 GB. I’ve
received 64725 connections on IPv4 and 1021 on IPv6. I’ve made
2301709 connections with IPv4 and 437304 with IPv6. [1 duplicate
hidden]Does that issue still exists with this message?
–
kind regards
MarcoSend spam to abfall1771841676@stinkedores.dorfdsl.de
tor-relays mailing list – tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org