I opened the PR first on my fork as I was advised to go for the forum first before opening a PR on the official repo.
This PR is about the addition of a TCP port tunneling feature to syncthing.
I’m using it for providing friends that are not so much technically versed access to servers in my home network.
Of course there are other possibilities to do so. E.g. just configure your router to open a port. But this is rather risky when you do not use a well tested server software.
Other ways would be VPN or Hamatchi LogMeIn. But VPN configuration was not easy to get right and by default exposes much more than just a single port on a single host. And Hamatchi is no OpenSource.
I thought about creating an easy GUI for nebula (GitHub - slackhq/nebula: A scalable overlay networking tool with a focus on performance, simplicity and security). But I found the way how syncthing connections can be established much easier to use for users.
So here is my prototype implementation which I think others might or might not be interested in as well.
At least, I found a request done for this feature here from 2018:
Tell me what you think. And YES, I’m aware that the feature might never make it into main-branch if the maintainers do not see the benefit.
I preface my remarks by saying I’m not part of the Syncthing team. I speak only for myself.
This seems way outside the core functionality of Syncthing, to me. Nord’s MeshNet is easy to set up, free, and does much of what you want — although I do not believe you can set up a single TCP port via MeshNet.
Next, I don’t think you’d be happy with performance if you used a Global Relay to make a port tunnel work. And that’s the only way to reliably expect someone who doesn’t know how to configure their router or firewall to get it to work.
Finally, and most importantly to me, I would expect a large number of organizations would start proactively blocking Syncthing traffic if it was used in this manner. Certainly, file synchronization can be used by a threat actor. I think the reason that we aren’t seeing that in the wild is that there are easier, subtler, and faster ways for threat actors to exfiltrate data than by using Syncthing.
Respectfully, I don’t think this is a good idea for Syncthing.
This would be bad, for sure. But when encrypted, how would one be able to detect syncthing traffic as syncthing traffic?
I’m not an expert for this, so sorry when I do a naive question.
I answer step by step, so please also consider my previous response.
If I open my server side syncthing port on my router, the other one can connect directly without any relay inbetween. Even if the other one is behind a NAT, router, …
I trust syncthing enough to do that (golang, modern tool, heavily used).
There are ways to fingerprint encrypted traffic. See Firewall Setup — Syncthing documentation for information on the ports Syncthing uses by default — that’s certainly one of the easiest ways.
With regard to how they would connect without a Global Relay, totally understood and that would work.
But if you’re doing that, why not use an SSH port tunnel? That does everything you need. And you can easily create a step by step guide to do it, or even script an installer that would do it for your less technical users.
I’m using ssh tunnels myself once in a while. I don’t think its easy nor convenient to use. Especially considering other operating systems. On windows you would have putty, which I also used in the past, and is not easy to understand and use especially when its about tunnel configuration.
Running commands or scripts on command line to setup a tunnel is a no-go for me for these group of persons.
Apart of these I think it too risky to expose a ssh connection to those other persons. Who knows which ideas they have to abuse the console access (even though usually they wouldn’t even try). I know one can block the command line access, but still - its too inconvenient to set this up and I’m myself not firm enough to sshd configuration.
Thanks for pointing to NordVPN mesh. Its seems to be partly opensource and completely free to use without relevant limitiations.
This seems therefor to be even better than the Tailscale variant which limits to 3 users. @calmh did I misunderstood this? Is there a workaround?
In both cases one needs an account on the companies webpage to manage the virtual network. This is quite handy, but strictly speeking not needed as my example with syncthing tunneling shows.
Also, NordVPN Mesh and Tailscale provide true virtual IPs. I guess therefor they need admin rights for installation (due to the virtual network interface, i suppose). Also, it exposes the whole port range by default, which might not be desired.
This can also be quite handy, but strictly speeking not needed for my usecase as my example with syncthing tunneling shows.
Please correct me if I misunderstood something. But i still see a significant enough advantage of the syncthing integration.
Regarding the risk of having syncthing beeing blocked by larger companies due to the tunnel feature: I’m not sure how likely this is … and if it is easy to do or not. Or it would be enough to just use non-standard ports? I guess that VPN protocols like Wireguard or the one from my nebula reference would have had the same issue and they solved it somehow. No?
Much of my professional background is in networking and cybersecurity. It’s trivial to block Syncthing on standard ports. I haven’t tried it, but I expect it would not be very difficult to fingerprint Syncthing’s encrypted traffic and block that as well.
For the sake of clarity, “larger” companies aren’t my concern. I think most security-aware organizations prohibit inbound SSH tunneling through their firewalls. I do, for my personal home firewall. To be fair, I would expect that most organizations that block SSH tunneling are likely to also block Syncthing. And to be fair again, I am speculating regarding this potential issue.
VPN protocols are commonly blocked, yes.
Setting up outbound SSH tunneling, Wireguard, MeshNet, or similar options are easy to document for non-technical users, and easy to script. And they have the advantage of not using Syncthing for something it isn’t designed to do.
OK, if this works out it wouldn’t be that much of an security risk anymore. Still, OpenSSH is implemented in C-lang and had already major issues in the past. I would still favor to open the Syncthing port over SSH port on my router.
Regarding the ease of use for non-technicals, I still think my syncthing proposal has advantages over the other solutions.
No Admin rights for installation needed.
By default, no port, port range, IP or other things are shared.
You can specify the service to expose (on server side) and to use (on client side) with a simple json file (no GUI integration is implemented yet)
(By the way, thanks for the great discussion. I learned already a lot.)
Your list of advantages for using Syncthing - which again, is NOT designed for any of this - are actually all true for using SSH port forwarding, except that the configuration for SSH port forwarding is easier than hand-jamming a JSON file. And PuTTY (which I have used for this many times) is FOSS and regularly updated.
Opening the ssh port on my router is a no-go for me security-wise. And the other solutions do need admin rights. Share ports for their virtual IP and need quite some clicks in their management GUI.
The JSON config file is hand-jammed by myself. The non-technical user receives it via messenger and just needs to place it to the right location. Copy-Paste in windows explorer. That’s it. It can’t be much easier without GUI integration where one would only need to press “accept” for the incoming server side service share. And this is already on my TODO list.
Interesting to me that SSH with all of its security capabilities is a no go but you are okay to have your non technical friends computers with all their possible bots:viruses:malware unfettered access to your private network.
Pick your poison I guess.
The idea of tunneling through a simple to configure tool like syncthing is interesting but I think it opens up a whole can of worms to enable syncthing to become a tunnel for any random IP traffic.
That’s fine. I kind of expected this. Anyway, as the modifications of the code are rather small I think its realistic to maintain it in my fork. The only inconvenience is that this way I can’t distribute automatic updates.
Is there an easy way to achieve this? E.g. with an own server for serving the updates? And my fork-binaries would use this custom URL to check for updates?
This is exactly what I do not accept and also not allow by syncthing. I think there is most likely a misunderstanding.
But I respect your perspective. SSH is used widely and also usually exposed to the public internet by professional hosting companies. I’m not a professional, that’s why I’m hesitating. What If I’m on vacation and a zero-day exploit appears?
I have kind of a personal bad perspective on this tool due to issues in the past.
Your aspect of opening a can of worms is too abstract for me. I can’t really follow that without providing further information.
Hmm, would the issue also be there when the feature is implemented in a fork? With completely different name?
Its sad that the authentication mechanism of synchting network can’t be re-used on its own. This would allow a set of different, but still easy to use tools which one can be rated as “corporate compatible” and others not.
I think it could be implemented in a bit more generic way: extend BEP-protocol, and allow peer to do “tcp-connection-passtthrough” usage. And then the peer might be able to open local tcp port and forward it to the party device…
I think a separate product that is based on syncthing connection strategy that does tunneling but NOT file synchronization sounds like a great idea. I probably could find a decent use for it, especially if it was lightweight enough and could be run in openwrt or other network devices.
