Syncthing fails to reestablish connections after initial TLS handshake timeout at boot

I’m running Syncthing 1.28.0 on NixOS with WireGuard VPN. My setup requires Syncthing to only communicate over specific WireGuard interfaces. I have multiple peers configured with static IP addresses on different WireGuard networks (10.x.0.x ranges).

The issue:

  • At system boot, Syncthing starts before WireGuard connections are fully established
  • Initial connection attempts fail with TLS handshake timeouts
  • Despite having reconnectionIntervalS=60 configured, Syncthing never successfully establishes connections after these initial failures
  • If I restart the Syncthing service after WireGuard is up, connections work perfectly

Logs show this pattern:

Jan 23 10:40:28 Lenovo2 syncthing[1410]: [KNWX3] 2025/01/23 10:40:28 INFO: Listen (BEP/tcp): TLS handshake: read tcp 10.12.0.11:22000->10.12.0.12:22000: i/o timeout

Jan 23 10:41:38 Lenovo2 syncthing[1410]: [KNWX3] 2025/01/23 10:41:38 INFO: Listen (BEP/tcp): TLS handshake: read tcp 10.12.0.11:22000->10.12.0.12:22000: i/o timeout

Jan 23 10:42:48 Lenovo2 syncthing[1410]: [KNWX3] 2025/01/23 10:42:48 INFO: Listen (BEP/tcp): TLS handshake: read tcp 10.12.0.11:22000->10.12.0.12:22000: i/o timeout

I’ve tried:

  1. Using reconnectionIntervalS=60 in config.xml
  2. Binding to 0.0.0.0 instead of specific interfaces
  3. Pausing and unpausing devices through the GUI
  4. Clearing errors through the REST API

None of these approaches resolve the issue. The only reliable fix is to restart the Syncthing service after WireGuard is fully connected.

Questions:

  1. Why doesn’t Syncthing retry connections properly after TLS handshake failures?
  2. Are there any TLS-specific settings that might help here?
  3. Is there a way to make Syncthing wait for successful peer connectivity before attempting TLS handshakes?

Any guidance would be appreciated.

I doubt this has anything to do with TLS as such, certainly all connections are retried indefinitely. I think you’re on the right track when thinking about binding and interfaces though, my guess would be that somehow it binds in a way that doesn’t include the interfaces that come into existence later. I don’t know why or how, though, so that’s something for someone to investigate.

Thanks, you’re probably right. I was overly fixated on the TLS issues. I’m not too technically inclined where network subjects are concerned.

I struggled for days getting Wireguard client interfaces created during boot at all, just because the destination is a URL, and it wouldn’t resolve. I finally got past that, so maybe what I’m left with is a simple boot ordering issue? Create the interface earlier, so Syncthing can actually bind, even if it can’t communicate yet because I haven’t logged in.

I’ll try to pursue that. Thanks again for your response. :slight_smile: