- tor-relays - lists.torproject.org

Max number of bridge under the same IP
by ML Tor 08 Nov '21

08 Nov '21

Hi, hi made a new Proxmox server for my home network. I still run a bare metal Tor bridge, but now i would run more bridge in my home network. I have a public dynamic IP: what is the max number of bridge i can run (obviously on different ORPort) under the same IP address Thanks in advance, -- ML

2 1

upgrade problem
by potlatch 06 Nov '21

06 Nov '21

Wondering if my tor.list has a typo since I can't upgrade Tor 0.4.5.9. I get error: Err:1 https://deb.torproject.org/torproject.org stretch/main amd64 tor-geoipdb all 0.4.5.10-1~d9.stretch+1 server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none I have debian 9 installed. Can someone turn on the light for me? Thanks, potlatch Sent with ProtonMail Secure Email.

2 1

known issues with deb.torproject.org repos?
by nusenu 02 Nov '21

02 Nov '21

Hi, are there known issues with the nightly master debian package builds? https://deb.torproject.org/torproject.org/dists/ and a related question: Will the stable packages remain on the 0.4.5.x LTS branch until the next LTS branch or will it at some point move to the latest stable again? (as it used to be) https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/CoreTorRele… kind regards, nusenu -- https://nusenu.github.io

2 3

Relay MIGHTYWANG consensus issues and loss of STABLE flag
by Mighty Wang 30 Oct '21

30 Oct '21

Hello fellow operators I have one pretty large relay, MIGHTYWANG which is an IP4/6 guard, dedicated hardware running on a 1Gb line uncontended. It is usually one of the top 5 relays by consensus weight but on the morning of 14th October it lost Guard status on account of losing the stable flag. I checked logs, connectivity and server health - nothing unusual, everything is generally pretty bullet proof in and around the relay and it had been running for well over a year without a reboot - just the very occasional Tor daemon restart following upgrades but no such activity prior to the 14th. So next I checked the consensus and I see that around half of the directory authorities seem to be not assigning the stable flag. See attached screenshot showing current consensus. The peering to each of those relays seems OK from what I can see (IP4 and IP6) so any idea what gives? I've got a MIGHTYWANG sitting here twiddling it's thumbs because have the directory authorities don't want to use it. Bit of a waste. I had similar things happen a few years ago with one of my old relays; again no obvious reason, just seemed to be the a random whim of the directory authorities. I've noticed a couple of other long term relays are in a similar position - is this some time of attack, deliberate action or just Tor magic? Wang -- MIGHTYWANG 9B2BC7EFD661072AFADC533BE8DCF1C19D8C2DCC

4 5

Tor respority can't be updated from securly on debian
by Keifer Bly 28 Oct '21

28 Oct '21

Hi, so I am trying to update tor to the newest version on my debian vps, only to receive this error: Reading package lists... Done E: The repository 'https://deb.torproject.org/torproject.org st retch Release' no longer has a Release file. N: Updating from such a repository can't be done securely, and is therefore disabled by default. Here is my sources.list file, ## Note, this file is written by cloud-init on first boot of a$ ## modifications made here will not survive a re-bundle. ## if you wish to make changes you can: ## a.) add 'apt_preserve_sources_list: true' to /etc/cloud/clo$ ## or do the same in user-data ## b.) add sources in /etc/apt/sources.list.d ## c.) make changes to template file /etc/cloud/templates/sour$ ### # See http://www.debian.org/releases/stable/i386/release-notes$ # for how to upgrade to newer versions of the distribution. deb http://deb.debian.org/debian buster main deb-src http://deb.debian.org/debian buster main ## Major bug fix updates produced after the final release of t$ ## distribution. deb http://security.debian.org/ buster/updates main deb-src http://security.debian.org/ buster/updates main deb http://deb.debian.org/debian buster-updates main deb-src http://deb.debian.org/debian buster-updates main ## Uncomment the following two lines to add software from the $ ## repository. ## I am wondering what needs to be added here to allow tor to update? Thank you.

3 2

bridge question
by potlatch 28 Oct '21

28 Oct '21

Should torrc for bridges list MyFamily? I run several of both. potlatch Sent with ProtonMail Secure Email.

2 1

Dropped off consensus (0.4.4.5)
by Felix 23 Oct '21

23 Oct '21

Hi everybody This is early. Yesterday I upgraded Ichotolot60 1AE039EE0B11DB79E4B4B29CBA9F752864A0259E from 4.2.7 to 4.4.5. Now I see in the consensus health: moria1 Fast Run Stab V2Dir Valid bw=566 tor26 Fast Guard Stab V2Dir Valid dizum Fast Guard Stab V2Dir Valid gabel. Fast Stab V2Dir Valid bw=1130 danne. Fast Guard Run Stab V2Dir Valid maatu. Fast Stab V2Dir Valid bw=1200 farav. Fast Guard Run Stab V2Dir Valid bw=2970 longc. Fast Stab V2Dir Valid bw=490 bastet Fast Guard Run Stab V2Dir Valid bw=3520 And _no_ Authority "owns" the relay. Old Apr 02 21:51:31.872 [notice] Tor 0.4.2.7 running on FreeBSD with Libevent 2.1.11-stable, OpenSSL LibreSSL 3.0.2, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.4.4. New Sep 18 21:00:22.384 [notice] Tor 0.4.4.5 running on FreeBSD with Libevent 2.1.12-stable, OpenSSL LibreSSL 3.2.1, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.4.5. (Yeah, some Lib stuff is new too, hehe) The "Guard !Run Stab" consensus looks quite interesting to me. How can it be? Other relays with that nice "Guard !Run Stab" dropped off consensus over night (or since days) and no authority "owns" them too: HORUS1 0.4.4.4-rc norisknofun 0.3.5.10 ULayerKiriakou 0.4.3.5 Stellvia 0.4.3.6 torexit42 (StaleDesc) 0.4.1.6 torpidsDEhetzner1 0.4.3.2-alpha (3 days) karen (StaleDesc) 0.4.2.7 Stephen304 0.4.2.7 (3 days) Rigel2020 (StaleDesc) 0.4.3.6 dgplug (FallbackDir, StaleDesc) 0.4.4.5 =?= May-be the operators updated and are now in the same floating position? May-be this is super normal and came to my attention by surprise? Anyways, I let everthing run for a day or so. Time can heal. -- Cheers, Felix

5 8

Tor Bridge Question
by Josh Lawson 19 Oct '21

19 Oct '21

I work for a bank and was informed that when I connect to my employer network, it shows I am coming from a Tor IP and sets off an alert that then leads to me being on a call with an investigative team for my employers. I was running a Tor relay, but had to shut it down because of these alerts. I am not thinking of running a bridge instead, but I have a question. Are the bridge IP addresses private enough to not likely trigger an alert by bank fraud detection software? Please let me know if I am not phrasing this well. I would like to donate some bandwidth and was thinking maybe running a bridge would be less likely to set off alerts.

3 2

Overloaded state indicator on relay-search
by Silvia/Hiro 19 Oct '21

19 Oct '21

Hello all, One of our goals with our current performance work is to reduce the overload of relays in the network. The implementation of proposal 328[1] a while back made different overload indicators available to relay operators and since a couple of weeks ago those can be tracked via Onionoo[2] as well. As we know that a lot of our relay operators use relay search to check for the health of their relays, we have launched a new feature there, too, to help them know when their relays are overloaded. When a relay is in the overloaded state we show an amber dot next to the relay nickname. Currently we are counting between 50 and 80 overloaded relays and between 10 and 20 overloaded bridges. The overloaded state is reached when one or many of the possible load metrics have been triggered. When this happens we show it for 72 hours after the relay has recovered [3]. Note, though, that not all of the exposed overload metrics are triggering the overload indicator on relay search yet. If you noticed your relay is overloaded, please check the following support article to find out how you can recover to a "normal" state: https://support.torproject.org/relay-operators/relay-bridge-overloaded/ Let us known how you find this new feature. Cheers, -hiro [1] https://gitweb.torproject.org/torspec.git/tree/proposals/328-relay-overload… [2] https://lists.torproject.org/pipermail/tor-project/2021-August/003168.html [3] https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n637

13 51

What is: Channel padding timeout scheduled
by Eddie 18 Oct '21

18 Oct '21

Noticed that one of my relays (OhNoAnotherRelay02) is showing as off-line. Looking at the logs, I see a bunch of these messages: Oct 18 08:39:16.000 [notice] Channel padding timeout scheduled 143041ms in the past. Oct 18 08:39:21.000 [notice] Channel padding timeout scheduled 156925ms in the past. Oct 18 08:39:24.000 [notice] Channel padding timeout scheduled 168712ms in the past. Oct 18 08:39:25.000 [notice] Channel padding timeout scheduled 166895ms in the past. . . . Oct 18 10:18:48.000 [notice] Channel padding timeout scheduled 194581ms in the past. Oct 18 10:35:22.000 [notice] Channel padding timeout scheduled 216311ms in the past. Oct 18 10:35:30.000 [notice] Channel padding timeout scheduled 224267ms in the past. What's the cause of this. I used this downtime as an excuse to do a bunch of upgrades and a re-boot. Cheers.

1 0

help with exit
by Bass Down Low 17 Oct '21

17 Oct '21

Hi all, I am somewhat new to the project and trying to run a couple exits to help out. I noticed my relay amazinglizard F80494CE5B2441B67431FFA9CCA571D26BC4F6D8 has bee up for 4 days and not turned into an exit yet. I noticed the overload flag is present, does this prefent my relay from becoming an exit? If not, I would appreciate any help you can give. thank you very much

2 1

Tor automatic restart
by Keifer Bly 11 Oct '21

11 Oct '21

7 8

Updating from Ubuntu 20.04 using apt-secure
by John Csuti 11 Oct '21

11 Oct '21

Hello all, I recently went to update and upgrade my system and found that the certificate for deb.torproject.org is expired and no longer trusted? Is anyone else having this issue and is there a way to fix this. I also added the repo to a fresh install of ubuntu 20.04 and got the same error. Error Err:5 https://deb.torproject.org/torproject.org focal Release Certificate verification failed: The certificate is NOT trusted. The certificate chain uses expired certificate. Could not handshake: Error in the certificate verification. [IP: 95.216.163.36 443] Thanks, John Csuti +1 (216) 633-1279

2 2

Restarting Tor
by sysmanager7 10 Oct '21

10 Oct '21

Greetings All, I have three relays that are in need of an upgrade and reboot. What is the best way to restart these relays without loosing flags or time? Secondly how long can a relay be down before flags are dropped? Thank you for any help! Sysop Sent with [ProtonMail](https://protonmail.com/) Secure Email.

4 3

relayor v21.1.0 is released
by nusenu 10 Oct '21

10 Oct '21

Hi, relayor v21.1.0 is released. relayor is an ansible role that helps you with running tor relays with minimal effort (automate everything). https://github.com/nusenu/ansible-relayor Changes since relayor v21.0.1 https://github.com/nusenu/ansible-relayor/releases/tag/v21.1.0 - generate ContactInfo v2 proof files for easy publishing (if enabled) - update apt cache if it is older than one day before installing dependencies (patch by @tsekityam) #219 #220 - increase min. ansible version 2.9.13 -> 2.9.23 - increase min. tor version 0.3.5 -> 0.4.5 - Debian 11, FreeBSD 13 and OpenBSD 6.9 are supported kind regards, nusenu -- https://nusenu.github.io

1 0

Connection Reset and IO Timeout errors on 0.4.6.7 with libnss
by theintern 09 Oct '21

09 Oct '21

Has anyone else on this list had issues with compiled versions of 0.4.6.7 in which the --enable-libnss is enabled?

1 0

Unreachable DirPorts
by Arlen Yaroslav 08 Oct '21

08 Oct '21

Hi to all relay operators! I run two Tor relays: 77D08850C1EE8587451F838D3F49874F75B0B1AC 09A70E396DE93F54D4541BBB0EC8E2B23761F34F They both have DirPorts configured on port 80. I can connect to this port on both hosts externally. However, Relay Search is showing the ports as either unreachable or unconfigured and is not showing the 'Latest server descriptor' and 'Latest extra-info descriptor' buttons at the bottom of the page. Would anyone be able help me troubleshoot this? Many thanks and regards, Arlen

2 1

Re: [tor-relays] Overloaded state indicator on relay-search
by Gary C. New 05 Oct '21

05 Oct '21

David Goulet: Will you confirm whether the Advertised Bandwidth metric is also client initiated (I'm assuming to the Directory Authority)? I have a 250Mb pipe and have seen a maximum Advertised Bandwidth rate of 4MB/s with my Tor relay. I know resource constraint must be factored in, but I would expect better than 4MB/s. I believe I remember reading it was based on an average 10 second burst rate, but in what direction is the connection initiated? Thanks, again. Gary

2 2

Re: [tor-relays] Overloaded state indicator on relay-search
by Bleedangel Tor Admin 29 Sep '21

29 Sep '21

1 0

New round of measuring the accuracy of Tor relays' advertised bandwidth
by Georg Koppen 23 Sep '21

23 Sep '21

Hello! You might recall we ran two "speed tests" so far for investigating the accuracy of a relay's advertised bandwidth, one in 2021[1] and another one earlier this year[2]. We gonna pick this test up again this week. However, this time it won't be just a single run but we are rather scheduling the experiment to be on for two weeks and then off for two weeks for the upcoming weeks/months (see: the third item in our network experiments strategy[3] for some rationale). More exactly: we'll run our measurement script for roughly one week, then wait about a week for flooded values leaving the relay descriptors, then 2 weeks off, then starting again... The experiment itself has not changed: we are planning to download several large data streams for a period of about 20 seconds with the goal to get a better estimation of the relay's true capacity. There are more details related to this experiment in particular in an older mailing list thread[1], in case anyone is interested and has not seen those yet. As in previous instances of this "speed test" there is the option for an opt-out. Let us know if any of you doesn't want to participate and we remove your relay(s) from the list to scan. Finally, an up-to-date status about the flooding being on/off (and other experiments scheduled) can be found on our status page[4]. Thanks, Georg [1] https://lists.torproject.org/pipermail/tor-relays/2019-July/017535.htmlff. [2] https://lists.torproject.org/pipermail/tor-relays/2021-May/019649.html [3] https://gitlab.torproject.org/tpo/network-health/team/-/wikis/Network-exper… [4] https://status.torproject.org/affected/network-experiments/

2 6

tor version question
by torix 22 Sep '21

22 Sep '21

Dear All, I can see in OrNetStats that I have several relays marked as having a vulnerable Tor version. But when I checked and tried to update them, I was told that everything was up to date. In 2 cases relays rented at the same time on the same host have different versions. AlexHost running FreeBSD release 12.1 and 12.2 respectively: 0.4.6.7 and 0.4.5.8 CoolComputers both running Centos8.4.2105: 0.4.6.6 and 0.4.5.10 I'm not sure why the same package repo would cough up different tor versions for different servers - is the answer to sit tight and wait for the older versions to catch up, or is there a way to force the older ones to update to a newer tor version? (My oldest version is 0.4.5.8). TIA, --Torix

2 2

Need help with Dir Address and Exit Address
by Bleedangel Tor Admin 21 Sep '21

21 Sep '21

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi all I have an exit relay running, and all is working well. I am a stickler though, and i notice when i search my relay on the metrics page, the following two items are listed as 'none': Dir Address Exit Address Can anyone help me to get these reporting properly? I have a V2 Directory flag and my dir port is 9030. I am allowing ipv4 exits. Metric page for reference: https://metrics.torproject.org/rs.html#details/5161B1C501805A0D3E9F87AFCAC9… Thanks for any help you can give! -----BEGIN PGP SIGNATURE----- Version: ProtonMail wnUEARYKAAYFAmFJOgQAIQkQ07hp34FMyg4WIQSgEMifmnN5ohFWvfnTuGnf gUzKDs8DAP4hSvlEPrlDkIY5vlLULhJHuNVbq/UT3r5mfBg/cg+p0wEAltfV bPlU/3wfg7j0b31h6R4g+Ik+96fkoq9VTqiydQg= =6AAW -----END PGP SIGNATURE-----

2 1

Ripped off relay name
by xplato 20 Sep '21

20 Sep '21

Just curious a relay appeared with a nearly identical name to a relay I have run for a while. Is this just a lack of creativity or something that I should be concerned about? The name is fairly unique and the new relay is almost identical in name. Sent from ProtonMail for iOS

4 3

OrNetStats now parses all your ContactInfo v2 fields and warns you if your Tor version is vulnerable
by nusenu 15 Sep '21

15 Sep '21

today I pushed new features to OrNetStats: https://nusenu.github.io/OrNetStats/ - Relay Search replacement: relay level pages via a custom allium[1] version Thanks to Jordan for creating allium! - parse and display all ContactInfo v2 fields [2] example: https://nusenu.github.io/OrNetStats/w/relay/A14D96E6C4C3A5AF3D7E57AC0A85AE8… - proven operator domains are highlighted with an icon in all overview relay lists (family-, contact-, country-level pages) example: https://nusenu.github.io/OrNetStats/w/misc/families-by-bandwidth.html (we display the proven operator domain instead of the ContactInfo when available) - the icon links directly to the proof file from the operator (on the relay-level page) - we display a warning sign when a relay runs a vulnerable version of tor examples on relay and contact-level pages: https://nusenu.github.io/OrNetStats/w/relay/FB58E117D11F87F0A291475D603EC61… https://nusenu.github.io/OrNetStats/w/contact/17b90573a94e713bf1b3ad7988934… - we display bandwidth in G|Mbit/s not MByte/s - onionoo AS data replaced with ipfire's upstream version: we no longer use AS data from onionoo - which made the switch from previously used https://yui.cat links to a custom allium version necessary because yui.cat (allium) uses onionoo as data source. Previously over 2000 relays had no AS name data (which affected >25% of tor's exit capacity). Now we are down to bellow 0.1% affected exit capacity without AS name data (mainly in the LACNIC region). +------------+--------+-----------+ |date |affected| affected | | | relays | exit_prob | +------------+--------+-----------+ ... | 2021-09-06 | 2005 | 24.03 | | 2021-09-07 | 2025 | 27.33 | | 2021-09-09 | 2038 | 27.93 | | 2021-09-10 | 2045 | 28.45 | | 2021-09-11 | 2041 | 28.12 | | 2021-09-12 | 2045 | 28.70 | | 2021-09-13 | 2044 | 27.32 | | 2021-09-14 | 2029 | 26.44 | | 2021-09-15 | 108 | 0.05 | <<< todays switch from onionoo to ipfire +------------+--------+-----------+ kind regards, nusenu [1] https://github.com/tempname1024/allium [2] https://nusenu.github.io/ContactInfo-Information-Sharing-Specification -- https://nusenu.github.io

1 0

IPv6 reachability tests fail on CenturyLink IPv6 6rd - reachability broken?
by Neel Chauhan 13 Sep '21

13 Sep '21

Hi, I recently moved into a home with CenturyLink Fiber and moved my FreeBSD relays to the said home. Fingerprints: https://metrics.torproject.org/rs.html#details/B0F9BA27944FA59E3B1A182208FF… https://metrics.torproject.org/rs.html#details/DB710B14D7329B7289CFCC547F48… In my relay logs, while IPv4 works fine, I get these IPv6 errors: Aug 26 18:47:01.000 [notice] Auto-discovered IPv6 address [REDACTED]:143 has not been found reachable. However, IPv4 address is reachable. Publishing server descriptor without IPv6 address. Aug 26 19:47:01.000 [notice] Auto-discovered IPv6 address [REDACTED]:143 has not been found reachable. However, IPv4 address is reachable. Publishing server descriptor without IPv6 address. [2 similar message(s) suppressed in last 2400 seconds] CenturyLink does use 6rd for IPv6 in case that matters, however I can telnet the relay ORPort via IPv6 from a VPS. My firewall is an OPNsense box which terminates PPPoE/6rd. I am running tor-0.4.6.4-rc. Yes I know it's not the "latest", but I usually run the "beta" versions on my relays from FreeBSD pkg. Rebooting both my OPNsense box and my server doesn't work. The same relay fingerprints/torrcs/keys worked fine on Google Fiber/Webpass native IPv6 in another address. I'm guessing IPv6 reachability tests aren't working right now since it worked with CL 6rd earlier today, or maybe CL misconfigured their network. It's not a biggie for me, but while I could go Comcast with better IPv6, I'd rather have a high bandwidth relay than an IPv6 one with Comcast's slow uploads/caps. Other Seattle ISPs like Webpass, Wave, and Atlas aren't in my new home. -Neel Chauhan === https://www.neelc.org/

2 1

new tor network graphs on OrNetStats
by nusenu 10 Sep '21

10 Sep '21

Hi, up until now OrNetStats mainly consisted of tables with lots of numbers about tor network stats that can be interactively searched, but graphs are usually a lot easier to comprehend, that is why I'll be adding more graphs to OrNetStats. Today I've added the first new graph on the main page that shows the 10 largest proven exit operator domains and their exit fraction in a bar chart: https://nusenu.github.io/OrNetStats/index.html In the long run I plan to publish (and re-implement) all graphs that currently are nonpublic (and not on OrNetStats yet). This should give more people a better view / understanding about what is happening/changing on the tor network infrastructure. kind regards, nusenu -- https://nusenu.github.io

1 0

Relay Control Port
by sysmanager7 10 Sep '21

10 Sep '21

In torrc I have the control port commented out. I'm told the control port is not supposed to be listed on the relay itself. Below, is now what it says. How do I get rid of it? Control Socket: /run/tor/control GroupWritable RelaxDirModeCheck Thank you for your help :-) Sent with [ProtonMail](https://protonmail.com/) Secure Email.

3 2

Burning Bridges
by torix 10 Sep '21

10 Sep '21

I think I remember Roger Dingledine saying somewhere that bridges' ips gradually get learned and put on ban lists. I have some bridges bought for the year. When renewal time comes up, does it make sense to let them go and buy new vms for the next year rather than renew them? I don't know if it matters what pool a bridge is in. TIA, --Torix Sent with [ProtonMail](https://protonmail.com/) Secure Email.

2 1

router_do_orport_reachability_checks()
by Gary C. New 10 Sep '21

10 Sep '21

All: Does anyone here know the procedure of the router_do_orport_reachability_checks() function? I've increased logging of my Tor Relay to info and taken several packet-captures, but can't seem to identify connections initiated by my Tor Relay when verifying my ORPort reachability. I just see connections from other Tor Relays initiate connections with my Tor Relay. Any detail that can be provided regarding the procedure of the router_do_orport_reachability_checks() function is greatly appreciated. Respectfully, Gary

1 1

>50% tor exit capacity is now safer against ContactInfo impersonation attacks
by nusenu 10 Sep '21

10 Sep '21

Hi, when analyzing unusual activities on the tor network one of the problems always was the fact that tor relay ContactInfos are an unverifiable claim. This has been exploited by malicious entities multiple times to setup malicious relays using other people's contact details. Since the release of the ContactInfo Information Sharing Specification (version 2) in October 2021 there is an easy option to setup ContactInfo strings that contain a non-spoofable domain to address this issue. https://lists.torproject.org/pipermail/tor-relays/2020-October/019024.html By now over 900 tor relays have set a verifiable domain in their ContactInfo, and this week the landmark of 50% of the tor network's exit capacity has been reached. graph: https://nusenu.github.io/OrNetStats/exit-fractions (since so many operators implemented the spec the mouse-over on that graph is a bit overwhelmed - I'll fix that soon-ish :) It is important to note that a verifiable domain in a ContactInfo string does _not_ mean "this relay is certainly not malicious" after all malicious relay operators can setup verified domains as well with a domain under their control, but having non-spoofable operator identifiers are the foundation for operator trust based relay selection. It is easier to say "I trust www.quintex.com to operate relays without malicious intend" than to say "I trust CC14C97F1D23EE97766828FC8ED8582E21E11665,DE4F7A7B2DF8689B1F8D23ABA9E320D17638EAFD, ..." because relay fingerprints are not human readable and are more likely to change over time. In case you want to join the effort or simply would like to see your operator level graphs - a nice side effect (example: https://nusenu.github.io/OrNetStats/hydra-family.github.io.html) here is the short version on how to set a verifiable domain in your ContactInfo: https://mastodon.social/@nusenu/106094297537909911 Thanks to everyone who joined so far and indirectly helps with malicious relay analysis! kind regards, nusenu -- https://nusenu.github.io

1 0

Old version in Debian/Ubuntu repo?
by Eric Jacksch 05 Sep '21

05 Sep '21

Greetings, Just a heads-up that a fresh install on Ubuntu 20.04 as per https://community.torproject.org/relay/setup/guard/debianubuntu/ Results in a version warning in the log file: "Please upgrade! This version of Tor (0.4.2.7) is not recommended, according to the directory authorities. Recommended versions are: ...." Cheers, Eric

2 2

Did obfs4proxy stopped working for you on Debian Buster or Bullseye?
by s7r 03 Sep '21

03 Sep '21

Hello, Did you try running obfs4proxy on Debian Buster or Bullseye and it worked? For me it stopped working entirely. All it says is: [warn] Pluggable Transport process terminated with status code 256 Here is what I checked so far: - I am on Debian Bullseye with all packages up to date - go lang version is go1.15.9 linux/amd64 - obfs4proxy version is obfs4proxy-0.0.12-dev (compiled from git) - Tor version is 0.4.7.0-alpha-dev I have edited /lib/systemd/system/tor(a)default.service & tor@.service to NoNewPrivileges=no and also installed libcap2-bin and setcap +ep to obfs4proxy executable. The libcap2-bin step is because I want to bind to a lower port, but even if I try to bind to a higher port like 50001 it will still not work and report the same: Pluggable Transport process terminated with status code 256. On another server I did a software upgrade from stretch to buster by apt dist upgrade and obfs4proxy stopped working as well. I am still digging here cause there are chances I did some mistakes while upgrading, so I am just mentioning the Bullseye problem because there are no excuses there, it should work, it's a clean fresh new install from scratch. Can someone please have another look to see if the problem is just on my side or if it's persistent among Bullseye installs, we should update the wiki bridge howto. Thanks.

1 2

Inflated throughput measures from torproject metrics?
by torix 02 Sep '21

02 Sep '21

The advertized bandwidth of my aramis family of relays has gone up from around 45 to 67 total since last week. ZimmerLinux (quetzalcoatl) sees inflation as well. I found a graph here of quetzalcoatl: https://nusenu.github.io/OrNetStats/quetzalcoatl-relays.org.html which whose weekly graph currently shows everything staying the same until about Wed. 25 Aug., then creeping up. He hasn't added any relays, so it looks as though the bwauths have changed something. I'm bringing this up because something seems a little out of control here. TIA, --Torix

2 6

Expected relay performance
by fugel1 31 Aug '21

31 Aug '21

Hi all! I've been running two tor relays [1] on the same machine for the past three weeks or so on my home connection (1 gigabit fibre). When I was looking for appropriate hardware (I needed something fanless) I was surprised at the almost complete absense of information online about what kind of relay performance one can expect from different cpus. Until the current relays speedtest that started on August 25 [2], my relays were slowly ramping up to about 4 MB/s up and down with a consensus weight of 15-19000. Hence, I was expecting to have to wait a few months to find out what the hardware was capable of, BUT then the mentioned test started! Both my relays instantly got an advertised bandwidth over 70 MB/s, and soon after consensus weights of 85000 and 105000 respectively (maatuska even hade the latter at 190000 for a while). The relays are now pushing over 20 MB/s each which enables me to start filling the current performance information void with the following: A fanless Core i5-8250 with HT disabled, running OPNSense 21.7.1, can push 22 MB/s of tor traffic up and down on each of two tor instances, with each main tor process consuming no more than 50 percent of one core and an average across all cores of 35-38 percent. Sorry about the lengthy post! :) [1] https://metrics.torproject.org/rs.html#details/F387C5F92B784137933202BB5E4F… [2] https://status.torproject.org/experiments/2021-08-26-relay-speed-test/

1 0

Network experiments on the Tor network
by Georg Koppen 25 Aug '21

25 Aug '21

Hello everyone! As you might have seen we had announcements on this list a couple of months back about experiments being run on the live Tor network.[1][2] This shows that our network is quite popular among researchers, which is great. However, it means as well that there are a bunch of questions that might be concerning, like how this in general affects relays, which role the Tor Project should play in this process, how we can be transparent both to our users and our relay community while experiments are running, how we can avoid different experiments, running simultaneously, affecting each other etc. etc. We therefore sat down a bit and wrote up our thoughts and reasoning on a wiki page[3] which is hopefully helping to answer those questions some of you might have. Needless to say, feedback is much appreciated as this document is nothing set in stone. Georg [1] https://lists.torproject.org/pipermail/tor-relays/2021-May/019649.html [2]https://lists.torproject.org/pipermail/tor-relays/2021-May/019672.html [3] https://gitlab.torproject.org/tpo/network-health/team/-/wikis/Network-exper…

1 0

Relay on CentOS8
by Totor be 24 Aug '21

24 Aug '21

Hi all As you might be aware, CentOS is switching from CentOS Linux to CentOS Stream https://www.centos.org/cl-vs-cs/ They provides a straightfowrarw way to migrate from Lunix to Stream: #dnf swap centos-linux-repos centos-stream-repos #dnf distro-sync I have migrated a relay running in a small VM and everything seems to run fine Before migrating my production relay, I would appreciate any feedback from other CentOS users on this migration: disk space required, eventual issues envountered and more generally do's & don'ts Thanks a lot!

2 2

ORPort NoAdvertise & NoListen Not Working
by Gary C. New 24 Aug '21

24 Aug '21

Hi! I'm having issues when implementing the NoAdvertise & NoListen options of the ORPort directive and am hoping someone here might be able to point me in the right direction. I can get Tor to successfully work as a relay without using the NoAdvertise & NoListen options of the ORPort directive, but for certain reasons I need to configure Tor on a Private Address. ### ORPort WITHOUT NoAdvertise & NoListen (SUCCEEDS) ### Note: Successful Self-testing logs WITHOUT NoAdvertise & NoListen Aug 13 00:26:42.000 [notice] Self-testing indicates your ORPort 198.91.60.78:443 is reachable from the outside. Excellent. Publishing server descriptor. Aug 13 00:27:49.000 [notice] Performing bandwidth self-test...done. Note: Successful Self-testing torrc WITHOUT NoAdvertise & NoListen # cat /tmp/torrc Nickname ASUSWRTMerlinRelay ORPort 198.91.60.78:443 SocksPort 9050 SocksPort 192.168.0.1:9050 ControlPort 9051 ExitRelay 0 DirCache 0 MaxMemInQueues 192 MB GeoIPFile /opt/share/tor/geoip Log notice file /tmp/torlog VirtualAddrNetwork 10.192.0.0/10 AutomapHostsOnResolve 1 TransPort 192.168.0.1:9040 DNSPort 192.168.0.1:9053 RunAsDaemon 1 DataDirectory /tmp/tor/torrc.d/.tordb AvoidDiskWrites 1 User tor ContactInfo tor-operator@your-emailaddress-domain Note: Nyx shows Tor build the initial 5 measurement circuits and then successfully continues to build new circuits # nyx nyx - gnutech-wap01 (Linux 2.6.36.4b...) Tor 0.4.5.7 (recommended) ASUSWRTMerlinRelay - 198.91.60.78:443, Control Port (open): 9051 cpu: 30.4% tor, 62.1% nyx mem: 53 MB (21.4%) pid: 14372 uptime: 05:18 fingerprint: 02DD61E41B3739C629C5CF8CEBA6000290BC3E7B flags: Fast, Running, Valid page 2 / 5 - m: menu, p: pause, h: page help, q: quit Connections (807 outbound, 9 circuit, 1 control): Note: Openssl s_client is successfully CONNECTED to the Public Address # openssl s_client -connect 198.91.60.78:443 CONNECTED(00000003) depth=0 CN = www.uy24fd6wkrzss.net verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 CN = www.uy24fd6wkrzss.net verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/CN=www.uy24fd6wkrzss.net i:/CN=www.bu5cm42gttwqzick.com --- Server certificate -----BEGIN CERTIFICATE----- MIICQzCCAaygAwIBAgIJAOPPF6uxLfr8MA0GCSqGSIb3DQEBCwUAMCMxITAfBgNV BAMMGHd3dy5idTVjbTQyZ3R0d3F6aWNrLmNvbTAeFw0yMTAzMDEwMDAwMDBaFw0y MTA5MjUwMDAwMDBaMCAxHjAcBgNVBAMMFXd3dy51eTI0ZmQ2d2tyenNzLm5ldDCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM/1zzI/PdYXIm6p1ZshOzIf AnUfauCPovIutPWBBNi9Q6um6EWYzb7DIKhmiTwijl691ktfylwVIMT8JnGO+1t1 +SooiSp4V1oSkMvoA0Whvhh3jonblvq7cD0FGz9xLVxJEs4I5LPxxDFDcfs5AHV9 wQ1rH+CnGOlBGD2X3jjOVJb1Vp9PZPj5sG4mCyBIfJdbuC1MYkXoOfmi8kY0MkV8 mB/XAODk4GmDTPG76gxAv3Da+10vcABqMNpSwraFZwcBcGOhUnmpKxRmm2dZdz7r tTLcZaaeAYJlNH4fxoG6PdmcPidLnlT4ILX44cXAf+OL4WJgWrRUUexTpI75pW0C AwEAATANBgkqhkiG9w0BAQsFAAOBgQCB9fjVciHTD0YlckPoSTzZJXHkDaBpmBVa 9/GpVLQMA9bK03AkDllycxEbSgB0bd8RjZKd1+3T7ck2FsOOzgIZP0v5U8A0uxA7 58w2yJWmomn9DaKXqwD9HHux905znq3elKzd1M5ZSbQhZdqNmsw8wZUo2ZaPCDHW wBCd2m6Ueg== -----END CERTIFICATE----- subject=/CN=www.uy24fd6wkrzss.net issuer=/CN=www.bu5cm42gttwqzick.com --- No client certificate CA names sent Peer signing digest: SHA256 Server Temp Key: ECDH, P-256, 256 bits --- SSL handshake has read 1058 bytes and written 428 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: Session-ID-ctx: Master-Key: BC7B6CA79A1466768EAE37C7D591FB57F2D351E75B4C43AB16C8B8CBCBEB8E4BA4EDE2FEED8D4036D045F42F3F029585 Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1628842910 Timeout : 300 (sec) Verify return code: 21 (unable to verify the first certificate) --- However, Tor fails to work as a relay using the NoAdvertise & NoListen options of the ORPort directive; even though, Openssl s_client is successfully CONNECTED to the Public Address. ### ORPort WITH NoAdvertise & NoListen (FAILS) ### Note: Failed Self-testing logs WITH NoAdvertise & NoListen Aug 13 01:01:46.000 [notice] Now checking whether IPv4 ORPort 198.91.60.78:443 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) Aug 13 01:21:45.000 [warn] Your server has not managed to confirm reachability for its ORPort(s) at 198.91.60.78:443. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports, address, /etc/hosts file, etc. Note: Failed Self-testing torrc WITH NoAdvertise & NoListen # cat /tmp/torrc Nickname ASUSWRTMerlinRelay ORPort 198.91.60.78:443 NoListen ORPort 192.168.0.1:9001 NoAdvertise SocksPort 9050 SocksPort 192.168.0.1:9050 ControlPort 9051 ExitRelay 0 DirCache 0 MaxMemInQueues 192 MB GeoIPFile /opt/share/tor/geoip Log notice file /tmp/torlog VirtualAddrNetwork 10.192.0.0/10 AutomapHostsOnResolve 1 TransPort 192.168.0.1:9040 DNSPort 192.168.0.1:9053 RunAsDaemon 1 DataDirectory /tmp/tor/torrc.d/.tordb AvoidDiskWrites 1 User tor ContactInfo tor-operator@your-emailaddress-domain Note: Confirmed that the necessary PortForward between the Public & Private Addresses is in place # iptables -t nat -S | grep :9001 -A VSERVER -p tcp -m tcp --dport 443 -j DNAT --to-destination 192.168.0.1:9001 Note: Nyx shows Tor build the initial 5 measurement circuits, but after some time fails and only shows the outbound & control connections. # nyx nyx - 192.168.0.1 (Linux 2.6.36.4b...) Tor 0.4.5.7 (recommended) ASUSWRTMerlinRelay - 192.168.0.1:9001, Control Port (open): 9051 cpu: 10.6% tor, 3.2% nyx mem: 55 MB (22.2%) pid: 5374 uptime: 56:32 fingerprint: 02DD61E41B3739C629C5CF8CEBA6000290BC3E7B flags: Fast, Running, Valid page 2 / 5 - m: menu, p: pause, h: page help, q: quit Connections (2289 outbound, 1 control): Note: Openssl s_client is successfully CONNECTED to the Public Address # openssl s_client -connect 198.91.60.78:443 CONNECTED(00000003) depth=0 CN = www.uy24fd6wkrzss.net verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 CN = www.uy24fd6wkrzss.net verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/CN=www.uy24fd6wkrzss.net i:/CN=www.bu5cm42gttwqzick.com --- Server certificate -----BEGIN CERTIFICATE----- MIICQzCCAaygAwIBAgIJAOPPF6uxLfr8MA0GCSqGSIb3DQEBCwUAMCMxITAfBgNV BAMMGHd3dy5idTVjbTQyZ3R0d3F6aWNrLmNvbTAeFw0yMTAzMDEwMDAwMDBaFw0y MTA5MjUwMDAwMDBaMCAxHjAcBgNVBAMMFXd3dy51eTI0ZmQ2d2tyenNzLm5ldDCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM/1zzI/PdYXIm6p1ZshOzIf AnUfauCPovIutPWBBNi9Q6um6EWYzb7DIKhmiTwijl691ktfylwVIMT8JnGO+1t1 +SooiSp4V1oSkMvoA0Whvhh3jonblvq7cD0FGz9xLVxJEs4I5LPxxDFDcfs5AHV9 wQ1rH+CnGOlBGD2X3jjOVJb1Vp9PZPj5sG4mCyBIfJdbuC1MYkXoOfmi8kY0MkV8 mB/XAODk4GmDTPG76gxAv3Da+10vcABqMNpSwraFZwcBcGOhUnmpKxRmm2dZdz7r tTLcZaaeAYJlNH4fxoG6PdmcPidLnlT4ILX44cXAf+OL4WJgWrRUUexTpI75pW0C AwEAATANBgkqhkiG9w0BAQsFAAOBgQCB9fjVciHTD0YlckPoSTzZJXHkDaBpmBVa 9/GpVLQMA9bK03AkDllycxEbSgB0bd8RjZKd1+3T7ck2FsOOzgIZP0v5U8A0uxA7 58w2yJWmomn9DaKXqwD9HHux905znq3elKzd1M5ZSbQhZdqNmsw8wZUo2ZaPCDHW wBCd2m6Ueg== -----END CERTIFICATE----- subject=/CN=www.uy24fd6wkrzss.net issuer=/CN=www.bu5cm42gttwqzick.com --- No client certificate CA names sent Peer signing digest: SHA256 Server Temp Key: ECDH, P-256, 256 bits --- SSL handshake has read 1058 bytes and written 428 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: Session-ID-ctx: Master-Key: BC7B6CA79A1466768EAE37C7D591FB57F2D351E75B4C43AB16C8B8CBCBEB8E4BA4EDE2FEED8D4036D045F42F3F029585 Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1628842910 Timeout : 300 (sec) Verify return code: 21 (unable to verify the first certificate) --- What am I missing? Am I implementing the NoAdvertise & NoListen options of the ORPort directive incorrectly? Thank you for your assistance. Respectfully, Gary

3 6

Tor non-exit relays and Hulu in 2021
by Neel Chauhan 18 Aug '21

18 Aug '21

Hi tor-relays@, Long time no see. Lately I'm more involved with the FreeBSD community, but I still run Tor relays though! I'm moving into a new house in Seattle, WA which has CenturyLink Fiber. However, I'm moving in with people who watch Hulu. I remember Hulu blocked Tor middle relay IPs back in 2016-7, but haven't seen recent information on this. Does Hulu still block Tor middle relay IPs in 2021? I'm also considering adding a static IP block but not sure if CenturyLink is willing to give static IPs to me. I signed up for a "business" account but since it's a "residential" address CL's systems may not 'allow' this [1], so that's why I'm asking. Comcast is not an option for me despite technically being "available" for obvious well-documented reasons. After all, CenturyLink is giving me 1 Gbps Fiber, not 1.5 Mbps DSL. -Neel Chauhan === FOOTNOTES === [1] - https://www.reddit.com/r/centurylink/comments/p6cs1t/cbrasstatic_ip_block_w…

1 0

prometheus onion service exporter
by Fran 15 Aug '21

15 Aug '21

Hey, I recently stumbled over a prometheus exporter for onion services: https://github.com/systemli/prometheus-onion-service-exporter Maybe this is of interest for some of you... fran

1 0

Move or Recreate
by Eddie 15 Aug '21

15 Aug '21

I'm thinking of switching a couple of the VPS servers I have, where I'm running both relays and bridges. (On separate VPSs, obviously). I know how to maintain the keys for both relays and bridges for the replacements, but was wondering exactly what does that buy me, as both will now be running at different IPv4/6 addresses. As opposed to just blowing away the current ones and starting fresh copies. Cheers.

3 2

FallbackDirectoryMirrors relay IP change
by Cristian Consonni 04 Aug '21

04 Aug '21

Hi, After 7+ years of running a relay on DigitalOcean, I have decided to move it somewhere else, as there are cheaper options. I kept the same keys and fingerprint and it seems that it has been picked up correctly on Atlas/Tor metrics, as it is showing with the new IP. I believe that this relay was listed as a fallback directory mirror - how can I check this? According to the doc[1] I should open a ticket to signal the change or write here. The link[2] for opening the ticket seems broken, so here I am. Also, I am wondering if I should have done this *before* moving the relay, if that's the case I think it could be worth putting a note in the FAQ about upgrading/moving a node[3]. Best, Cristian [1]: https://gitlab.torproject.org/legacy/trac/-/wikis/doc/FallbackDirectoryMirr… [2]: https://trac.torproject.org/projects/tor/newticket?keywords=fallback-change… [3]: https://2019.www.torproject.org/docs/faq.html.en#UpgradeOrMove

2 1

Is my node dropping packets?
by Marco Predicatori 02 Aug '21

02 Aug '21

Hi, my Tor node is inside a local network protected by a firewall. Only port 9001 is NATted towards the Tor server. Moreover, I have iptables active on the Tor server itself. The outer firewall blocks any incoming packet except for packets on port 9001 and returning packets from established connections. My iptables blocks several packets which were allowed through by the outer firewall, where I assume they are recognized as returning packets from established connections. Then my local iptables drops them. I can't understand why. You can find here an extract from my Tor node "iptables -L -n" and a typical day's log of dropped packets on the Tor node: https://easyupload.io/m/48if5l Many packets coming from other Tor nodes where dropped. The Tor log doesn't mention any problem. What may be wrong? -- Bye, Marco https://metrics.torproject.org/rs.html#details/A4E74410D83705EEFF24BC265DE2…

2 2

Question about Tor updates
by potlatch 31 Jul '21

31 Jul '21

Hello Tor people, I have several Tor relays in a developing country so I suspect their VPS and network expertise may be developing as well. When I update my ubuntu 20.04.2 LTS (Focal Fossa) I get the following message: Skipping acquire of configured file 'main/binary-i386/Packages' as repository 'https://deb.torproject.org/torproject.org focal InRelease' doesn't support architecture 'i386' Everything else updates fine. The cpus are AMD Ryzen 5 6-core. I see cpus as 32-bit and 64-bit. The installation has been working for over 1-year. Did I install the wrong Tor? (It's 0.4.5.9) Is there a soft/hardware conflict? --potlatch Sent with [ProtonMail](https://protonmail.com/) Secure Email.

2 1

My Family
by Kathi 29 Jul '21

29 Jul '21

Hi - I'm running three relays. Is it necessary to list all three relays in my family on each relay? Thank you! :-)

5 5

Relay Bandwidth/Burst Change
by Kathi 29 Jul '21

29 Jul '21

I set torrc bandwidth/Burst to 5 MBs/6MBs respectively Then I get @7pm Local: Received reload signal (hup). Reloading config and resetting internal state. Read configuration file "/usr/share/tor/tor-service-defaults-torrc". Read configuration file "/etc/tor/torrc". After the above happens I'm back to Kb second. If I understand correctly, torrc is the 'go to' default and those settings [*should be*] used. So why is the bandwidth/Burst being changed? Which is REALLY annoying. There must be another setting somewhere in Tor that I am missing? Thank you for your help!

2 1

Updates to Tor Bridge?
by doTheRightThing655＠protonmail.com 28 Jul '21

28 Jul '21

Hello everyone, I recently started running a Tor Bridge on my Windows 10 PC. How do I update it? Does updating the Tor Browser app update my Bridge? Or is there a method to doing this? Thanks! Sent from ProtonMail

3 2

Relay appears to be broken
by Sarah Alston 28 Jul '21

28 Jul '21

Hi, I just setup a relay on some spare hardware I had around, but it doesn't appear to be functioning properly. It bootstraps fine, and the WAN ports are open. Additionally, the relay doesn't appear to be listed in the relay directory, either.However, the only connections appear to be to directory authorities, and for the life of me I can't work out what the issue is. This is the log from tor systemd service: https://pastebin.com/KsyNnBBq If anyone could help, it would be greatly appreciated.

1 0

relayor v21.0.1 is released
by nusenu 25 Jul '21

25 Jul '21

Hi, relayor v21.0.1 is released. relayor is an ansible [1] role that helps you with running tor relays with minimal effort (automate everything). https://github.com/nusenu/ansible-relayor [1] https://www.ansible.com/ changes since relayor v21.0.0 * install the gpg package by default on debian based systems (patch by @ anadahz) * reload tor when the tor-exit-notice html file is changed (patch by @ anadahz) https://github.com/nusenu/ansible-relayor/releases/tag/v21.0.1 kind regards, nusenu -- https://nusenu.github.io

1 0

APPCRASH on Windows Server Core 2019
by Saswat Padhi 23 Jul '21

23 Jul '21

Hello, I recently switched to a Windows Server Core 2019 machine for running my (exit) relay. Previously I was able to run the relay without any issues on Windows Server 2019, but it crashes without any errors or warnings on Core 2019. Has anyone tried running a Tor relay on Windows Server Core? I have attached my notice.log file and the error report from Windows events log, but none of them have anything informative at all. What I see is very similar to what's described on this thread: https://lists.torproject.org/pipermail/tor-relays/2021-April/019597.html. OP was finally able to resolve it, but they didn't post their solution ... Thanks and regards.

1 0

OVH killed me
by gerard＠bulger.co.uk 18 Jul '21

18 Jul '21

I have had no reports of abuse with my partial exit for a couple of years, then suddenly OVH kills the server (Reinstalling is a pain and IPV6 not autoloaded and they and Ubuntu keep changing networking) Anyway “Abnormal activity has been detected on your VPS vps585081.ovh.net. As your VPS poses too greater threat to our infrastructure, we had no choice but to put it in FTP rescue mode. This mode enables you to access the data on your VPS. An email containing information on FTP rescue mode has been sent to you. Actions can no longer be carried out on your VPS via your Manager/API. Only the following actions are possible: - Reinstallation of your VPS. Please do not hesitate to contact our technical support team so that this situation does not become critical. You will find the logs brought up by our system below, which led to this alert. - START OF ADDITIONAL INFORMATION - Attack detail : 7Kpps/3Mbps dateTime srcIp:srcPort dstIp:dstPort protocol flags bytes reason 2021.07.17 15:44:37 CEST 51.38.64.xxx:39859 192.124.249.xx:443 TCP SYN 60 ATTACK:TCP_SYN 2021.07.17 15:44:37 CEST 51.38.64.xxx:38510 67.222.30.xx:443 TCP SYN 60 ATTACK:TCP_SYN 2021.07.17 15:44:37 CEST 51.38.64.xxx :43014 67.222.30.xx:443 TCP SYN 60 ATTACK:TCP_SYN When I fire it up how to mitigate against this? My new server with the original IPV4 address is under attack already but tor is not running yet Gerry

1 0