Can't consistently get direct connections

[UptightHypertext]

My Current setup:

• 1 instance running on TrueNAS via Truecharts
• 2 instances running on AndroidTV
• 1 instance on Android
• 1 instance on Windows 10

Currently my issue is that the Truenas based instance has isn’t connecting directly to all but the Windows 10 device.

History:

I had the issue in the past with my Windows 10 PC not connecting, that I temporarily resolved by entering a direct ip in addresses

I got my Android device working the same way temporarily.

(months)

I noticed that my AndroidTV devices weren’t connecting directly and so were slow to sync. I’d prefer finding a more solid solution so now I’m trying to hunt down the issue.

I’ve found that my issue with the Win10 computer was Windows not properly identifying the network as private, so I just changed the firewall settings to allow Syncthing out in general.

The Android device is unresolved with the issue of a direct connection only occurring inside the network and global discovery allowing it to direct connect to the port forwarded to the TrueNAS machine when outside.

My best guess is that there is an issue with discovery on the TrueNAS instance since it’s virtualized inside a Kubernetes container with an internal VM network and this normally wouldn’t be an issue but other posts in here about Android(TV) having issues with local discovery compounds it and completely breaks the setup.

So I’m looking if there is a solution for the TrueNAS instance since it sounds like the Android(TV) problem won’t be fixed for some time.

Alongside this issue, I’m having issues with Direct WAN connections. Presumably since I don’t have UPnP or NAT-PMP enabled on my router, only the single device that has the port forwarded manually works.

Is there some other method besides a bunch of manual entries (plus custom ports) or enabling UPnP/NAT-PMP (both I’ve read aren’t the best for network security)?

Notes (mildly related):

I did for some reason have an instance of getting direct connections but it was weird. I changed the listening address of the server to the IP of the server. Logic being that I was only seeing (what I thought to be) the internal IP of the Kubernetes cluster and the WAN IP of the server, I’m clearly not familiar with all the discovery mechanisms and thought this might allow devices to get the proper IP when it broadcasts for discovery. It didn’t seem to work but when I reverted back to default, it temporarily directly connected to the Android devices. Restarting the server without changing any settings anywhere disconnected them and they never reconnected that way again.

[UptightHypertext]

On a whim, I redid the custom listening address. I expanded default into tcp://0.0.0.0:22000, quic://0.0.0.0:22000, dynamic+https://relays.syncthing.net/endpoint then added on tcp and quic listening addresses for the physical server.

After saving, I restarted Syncthing and it directly connected to the AndroidTV devices.

Then I removed the physical server addresses and just kept the expanded default option. Saved and restarted.

All the AndroidTV devices still directly connected.

To check if it was just some cached address, I then used my Android device, swapped it onto the local network, restarted its Syncthing service, and confirmed that it didn’t have the saved ip address for the server.

It still directly connected locally when it hadn’t before.

For extra confirmation, I restarted the Syncthing service on the server again and it still directly connected.

So now I’m curious if there is some issue/change with the default value for Listening Addresses.

[calmh (Jakob Borg)]

There is a cache outside of your devices, global discovery servers keep announced addresses for one hour. I think the root problem here is probably that the Dockerised instance can’t see it’s physical addresses, so those don’t get announced. Adding them specifically as listen addresses like you did makes Syncthing know about them and announce them.

[UptightHypertext]

Ah, so my gut instinct was correct, that whatever I threw in the listening address would likely propagate wherever I needed (either discovery servers or discovery broadcasts).

So it likely was just taking a little while to go through on my first attempt. The removal and save just ended up happening at the same point the info wrapped around and things connected. So the reset then just happened after caches cleared and they couldn’t reconnect.

This time the connections stayed working because there was some cache remaining probably on one of the remote discovery servers.

Well then this seems to solve the main issue, I can force Syncthing to be aware of the proper address by just adding it as a listening address like I initially thought.

I guess what remains is just if there is a clean/convenient way to get direct links across the WAN firewall without UPnP or a bunch of manual port management.