Hi there. I decided to be “weird” and “cool” and give myself a boost in transfer speed by hooking up a 2.5Gbps link between my workstation and my NAS, directly, instead of using the 1Gbps LAN. I have figured out the hoops to jump through in order to get the two machines to communicate on this new network, sans-router - pings both ways work perfectly fine. However, I’m a bit lost on getting Syncthing to cooperate - I get errors such as “I/O timeout”, “network disallowed” and “no recent network activity”. The workstation is at 172.16.0.100 and the NAS is at 172.16.0.10 - though the jail in which Syncthing operates on the NAS has its own IP of 172.16.0.2. After a few attempts at connection, I decided to let the addresses for Syncthing to use be dynamic at either end, to eliminate as much chance of user error, and, from the workstation side, it discovered the Syncthing plugin on the NAS at 172.16.0.2 as aforementioned, and from the NAS side, it discovered the Syncthing app at 172.16.0.100 on the workstation. Off to the races, right? Nope… I am just met with these aforementioned error messages. In the NAS’s interface, the allowed network is set to be 172.16.0.100, and from the workstation’s side, 172.16.0.10. Seeing as though the setup did work over the regular 1Gbps ethernet, I don’t think firewalls are coming into play (it detects port 22000 just fine…), though I could be wrong. Where am I going wrong?
It’s really hard to tell from the description alone, as you haven’t mentioned the interfaces, routing architecture and network masks involved.
From the description, it sounds like you’ve set up a point to point link using a 172.16.0/24 or possibly even a 172.16/16 subnet. At the same time, you already have a containerized (namespaced) 172.16.0/24 (or along those lines) subnet on the NAS machine. Thus, you now have two different interfaces with conflicting network address spaces. This is almost guaranteed to result in broken behaviour. The NAS won’t be able to properly route between these two interfaces, unless specific configuration has been applied to handle this scenario.
If the above is correct, I suggest using a different, non-conflicting RFC1918 subnet address for your point to point link that doesn’t conflict with existing network addresses. Your containerized subnet most likely has some NAT rules already in place that will route between the point to point link and the container address - in simple terms, ignore the container’s IP address and pretend it doesn’t exist (but don’t use its address space).
As local discovery is unlikely to work in containers, automatic address discovery will only work properly if global discovery finds the proper non-container network address. This is unlikely to happen on the NAS, as the namespacing generally prevents syncthing from seeing your point to point interface. However, from your description is sounds like the workstation isn’t containerized, so it will be capable of announcing the point to point link to global discovery. I think that’s the reason why it currently looks like it’s working “from one side”.
Thus, global discovery might work in your scenario (due to one side not being in a container), but if you run into trouble I suggest configuring addresses manually. If the container is NAT’ed as I suspect, you need to enter the IP address outside the container (the IP address on the point to point link) as the remote address on the workstation. Similar for the remote address on the NAS, enter the p2p IP address of the workstation there.
Customized networking is cool, but can get complicated fast 
.
Also, for debugging, don’t set any allowed networks in syncthing: It will just create problems. If you need to use that option, configure it after everything works properly.
Hi, I did indeed forget to provide detail on the routing and general structure of the networks at play. The LAN is in the 192.168.x.x address space, /24, and the dedicated faster point-to-point link is in 172.16.x.x space (hence also RFC1918, but also hence class B, and hence /16). As I said prior - pings running from either device to either device through this network succeed. As for “containerized” subnet, I haven’t the slightest clue … as soon as the second network was up, the IP of the jail kinda switched to it?
I do not believe it was at 172.16.x.x before - nor do any existing connections on the LAN have any new trouble accessing Syncthing on the NAS at 192.168.0.182. As for -
It doesn’t. It doesn’t work at all, from either side. The only thing that happens is it detects the clients at their addresses, and doesn’t communicate in either direction beyond that.
If I don’t set any allowed networks, it always always always defaults to 192.168.0.x, no matter how aggressively I type in the address at 172.16.0.x 
, and then if I specify “dynamic” for address it just goes full bonehead mode via Relay WAN 
so I’m unsure about removing the allowed network …
I don’t have a full grasp yet which side needs to have Global Discovery enabled? You are correct with the workstation not being containerised, though.
Oop, Global Discovery is on on both. Hmm.
As per TrueNAS forums - the jail being on the same network is correct/normal.
Ah yeah, those are BSD jails it’s using right? I don’t have much experience with them. It would be relevant to know if the networking is virtualized/namespaced by the jail or not.
172.16.0.2/30 from the screenshot doesn’t sound good though, as that only includes the IP addresses 172.16.0.2 - 172.16.0.3. Your 172.16.0.100 workstation address isn’t part of that network and as such will either have to be routed by the kernel, or not be reachable from the jail at all.
The fact that pings work doesn’t say that much, as I suspect you’re pinging from outside the jail, right? The proper check here would be to ping from the same network perspective as syncthing, e.g. from within the container/jail.
Which sounds a lot like NAT + namespacing, as that doesn’t match the IP address being shown in the configuration. Either the configuration shows something else (and not syncthing’s actual listening address), or there’s a NAT somewhere in between.
That’s what I meant. Global discovery finds a reasonable address for one of the devices, while the other side just finds unreachable addresses.
Having global discovery enabled is never a problem, I just meant that it might not work flawlessly in your setup. You need to have it enabled on both sides to have any chance for dynamic addresses to work, otherwise you must configure static addresses. (Assuming local discovery is also inoperative due to namespacing)
So there’s still a reachable path via your ordinary LAN, that’s good to know. I suggest to remove allowed networks and configure remote addresses statically.
Set the IP address of the p2p link as remote device address. The workstation IP on the NAS ("tcp://<IP>:22000) and the other way around.
To gather more information, two more things are relevant:
- What are the Sync Protocol Listen Addresses set to on both machines?
- What IP address and subnet does that FreeNAS/TrueNAS GUi show if you (temporarily) remove the point to point link?
PS: A bit of gooling also shows that you can apparently both enable and disable vnet (which is network virtualization/namespacing) (SOLVED - FreeNAS UI IP and Jail IPs | TrueNAS Community). Do you currently have that enabled or disabled for syncthing?
Sync Protocol Listen Addresses are default on both machines.
if I ifconfig mlxen0 down and restart the jail/plugin, the IP of the jail does not change, implying that it was separate, either that or that the network being brought down doesn’t influence that /shrug
Ah, that’s excellent, it shows quite a lot and it also explains the earlier IP address of 172.16.0.2/30.
The jail has its own (virtual) network interface which is a 172.16.0/30 network (extremely small, but still a network). It has setup a NAT to be routed to the outside world. There’s also probably a port forwarding for port 22000 (+ 8384) somewhere, so that GUI + Sync is reachable.
That matches my original guess: The vnet0 network of 172.16.0.2/30 conflicts with your p2p link network of 172.16.0.0/16 (which is a bit excessive by the way), as one includes the other.
OK, that is sounding like some optimism - is there an easy solution from here?
(hahahahahahahaha 
)
Yes, you can change the p2p link address to not conflict with 172.16.0.2/30, or alternatively change the vnet address to something else. “Not conflicting” means that neither network address contains the other, e.g. 172.16.0.2/30 and 172.16.1.0/24 would work just fine.
Again, to reiterate, due to the NAT the workstation will communicate with the “outside” IP address of the NAS, the vnet0 IP address is invisible to the workstation. The NAS will communicate with the “outside” IP address of the workstation, which is straightforward here since there’s no NAT magic going on.
OK - seeing as though I have no devices in 10.x.x.x space, would it be more of a concrete bet of avoiding conflicts to put the vnet somewhere in that address space? I am leaning towards changing the vnet’s address over the externals, being a tad reluctant to possibly harm a configuration that outside of Syncthing is otherwise working. Given that - would you be able to quickly run through what the configuration would have to be on either side within the Syncthing clients, just to remove as much ambiguity as possible/chance of me messing up haha 
Unfortunately, due to overall limited private (RFC1918) IP address space, the chance of conflicts is never non-zero. For example, there is some VPN software using the 10./8 band, and even some nonconforming ISPs.
The best way to avoid conflicts is to avoid creating too large networks. Your jail already tried to be “friendly” by setting up a very small /30 network - that’s just enough room for 4 IP addresses.
At the same time, your /16 network had room for 2^16 = 65536 IP addresses - but your point to point network only has 2 hosts! This dramatically increases the risk of getting such conflicts, because with limited total address space you can either have “many small networks” or “a few large networks”.
I suggest to not touch the vnet config, to avoid breaking stuff. Instead, change the point to point link, which is currently not being used anyway, so breaking it shouldn’t be a big deal.
Example configuration:
-
Network address: 172.16.99.0/24 (has room for 2^(32-24) = 2^8 = 256 IP addresses, 254 hosts max.). Using .99 here to lessen the chance of something else using that already. You can also use something even smaller than /24 (like /28 or so), but it shouldn’t be necessary - /24 is the most common choice. Network address needs to be configured both on the NAS and Workstation, you did that previously already.
You previously used 172.16.0.0/16 here.
-
NAS IP address: 172.16.99.10 (for consistency with the previous IP address, 172.16.0.10)
-
Workstation IP address: 172.16.99.100 (for consistency with the previous IP address, 172.16.0.100)
-
Syncthing configuration:
- NAS:
- Remote device (workstation) address (Edit Device → Advanced → Addresses): “tcp://172.16.99.100:22000”
- Workstation:
- Remote device (NAS) address (Edit Device → Advanced → Addresses): “tcp://172.16.99.10:22000”
- NAS:
taking in info and acting on suggestions… (thanks! )
… less good from there on out. I removed the setting of allowed networks from all configuration, FWIW.
Hm, weird. The connection refused at least means there are some packets flowing. It’s possible that there isn’t a port forwarding setup on the NAS-NAT side, which would explain the connection refused. However, the connection should then still work when initiated from the NAS side - the fact that this results in i/o timeout is worrying, indicating that the packet is lost along the way.
Perhaps some bad routing entry leftover from experimenting (which could go away after a reboot), or a firewall intervening. Other than those two I’ve no good idea left I’m afraid.
OK, post reboot on all sides, I have no further success (though no new errata, just the same as before) I do wonder if the problem lies somewhere in the configuration of the vnet …
@Nummer378 I did it
I set the NAS’s destination in Syncthing (from WS) to 172.16.0.2, and then configured a static route in my workstation’s routing table to 172.16.0.2 using 172.16.99.10 as the gateway for it
