Question 1
I have two sites, they are connected via a VPN tunnel. I don’t want to use any ‘relays’ and I assume Global discovery allows syncthing to discover my folder share over the internet and Local discovery check the local LAN and in my case VPN. Is that correct? If the VPN tunnel drops, I’m ok with the connection breaking. Basically, I only want to use my network and I don’t want to rely on Global discovery and/or the relay servers.
I’ve unchecked relay and global and I made sure to use tcp://ip:port on both sides of my VPN tunnel. Everything connected and I am able to sync, but one thing still bothers me.
Question 2
I used tcp://192.168.10.10:22000 on one side and 192.168.20.10:22000 on the other side, but when I’m on the main page for syncthing, for remote devices I see 192.168.10.10:54914 on one side and 192.168.20.10:22000 on the other side (under remote devices). Why is one side showing 22000 and the other side is showing 54914?
Syncthing uses TLS, which transports data over TCP. TCP is a connection orientated protocol which requires one side to be a client and the other side is a server. The client can only connect to a single server whilst the server can accept multiple connections from clients.
Since syncthing does not strictly follow the server-client concept, both sides can be either role in syncthing. You can control the port used for the TCP server, but the client needs to run on a different port (as you can’t use the same port twice on a single interface). I believe the client port number is therefore chosen by the operating system. Syncthing always runs a TCP server for incoming connections and creates client sockets for outgoing connections. That’s why the numbers differ.
Oh and by the way: If you configure static addresses in syncthing (which you have done apparently) you don’t even need local (or global) discovery.
Right, the port I’m seeing that isn’t 22000 is the source port being used. I get that part, I was just confused since I specified 22000 for both, I thought those were destination ports not source ports.
I did try unchecking Global and Local and it didn’t seem to connect, but maybe I didn’t give it enough time.
Can I leave it on dynamic and only check Local for local discover over LAN/VPN?
Definitely not. Googling seems to indicate others seeing the same thing. Unfortunately Discourse (the project) doesn’t do any sane form of bug tracking so it’s hard to know. Hopefully it’ll go away in a future forum upgrade. I’ll try one now and see what happens. Brace for impact.
Update failed due to a different bug in the newer version, so we’ll have to live with this for the moment…
If you uncheck global discovery and have dynamic only, it will only connect to devices it finds over local discovery. And that might not work over VPN, as that may not transmit broadcasts (I am guessing here). Easiest solution: Enable global discovery. Unless you have a special threat model, I don’t really see why you wouldn’t want to use it. However you can disable it, if you have a “static setup” (e.g. no laptop that goes online on various locations). Then you can use dynamic (for LAN) in combination with specific global IP addresses (e.g. tcp://22.345.264.94:22000, dynamic in device settings).
Thanks Simon. To be clear, I don’t want to ever use a WAN IP in device settings, it will only be a LAN IP. If I were remote with my laptop, I’d still keep the LAN IP but I’d connect back to the network with a VPN Client and then it should work the same as when I had the laptop behind the network connected via VPN.
I’ll leave local checked and simply specify the static IP as I’m doing now.