TOR traffic in v1.18.0-rc.1 even when relaying disabled?

Support
1

After upgrading from v1.17.0 to v1.18.0-rc.1, my company’s IT department is now saying that syncthing needs to be uninstalled because they are detecting TOR traffic from it.

In both versions, the following connections settings were (and are still) used:

Sync Protocol Listen Addresses: default
[X] Enable NAT traversal
[X] Global Discovery
Global Discovery Servers: default
Outgoing Rate Limit: 0
[X] Local Discovery
[ ] Enable Relaying

Is there something else that must be done in order to prevent any TOR traffic from syncthing? I’d like to be assured that with the right setting it will never use TOR traffic.

2

I suspect they potentially detected something when it was enabled?

I don’t think any of the behaviours changed since the previous version, so you should question the ips in question and see if they are part of relays.

3

Syncthing doesn’t use TOR for anything, ever, regardless of settings. Specifically, the relaying has nothing to do with TOR.

(You can set up TOR and get Syncthing to use it via proxy, but then it’s TOR generating TOR traffic.)

3 Likes
4

It seems like the issue must be that the IPs being contacted by Syncthing are also being used for TOR nodes/relays. So, it’s kind of a ‘guilt by association’ problem.

I guess there isn’t an easy way to ensure that all connections go to “non-TOR” IPs? Or maybe to constrain all traffic to a limited set of networks?

5

It connects to all the configured devices, plus syncthing project servers, which do not also act as TOR nodes. If you disable relaying (or configure one manually, which is “clean”), you should be good. Better, though likely not practical solution: Tell your it department to drop that “security” policy or whitelist syncthing relays: https://relays.syncthing.net/

6

Can your department clarify which IP addresses are “offending”? As you said you already had relaying off previously, it’s currently unclear what the problem is, as there are no TOR related nodes hosted by syncthing.

7

@Nummer378, here’s a list of some of the “offending” IPs:

5.39.69.166
5.103.80.64
185.149.207.2
185.181.160.216
185.243.218.27  <--- this is the only one I saw on the relay stats page
193.108.117.41

Not sure if there’s anything in common about them.

8

Could it be one of the STUN servers?

9

Is there a way to have an “IP whitelist” for ST (or if not, for this to be considered as a new feature)? Something which will restrict any outgoing connections so that only the listed IPs can be contacted.

10

Use a firewall for that.

1 Like
11

That may make sense when one has control over the firewall, but on a company machine where the firewall is locked down (and which is one of the few environments one might want to be able to restrict the connections), this feature would be important.

12

You can set allowed networks per device.

13

Thanks for pointing that out! With that setting, I suppose that individual IPs can simply be specified as IP/32?

Btw, does anyone know if there is any possibility that SyncTrayzor could contact other IP addresses (outside of what Syncthing connects to)?

14

I know that SyncTrayzor has an inbuild update check + upgrader (distinct from syncthing), so yeah there’s probably something.

15

Using synchthing 1.21 on Ubuntu 22.04. My firewall is alerting me that a process on ubuntu is contacting the following Tor Exit nodes 185.14.97.176, 51.75.64.23, 185.243.218.27 on port 22076 :face_with_raised_eyebrow:

16

Those relay operators host an exit node on the same server which explains your warnings.

1 Like
17

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.