"unexpected device id expected {ABC} got {XYZ}"

I’m trying to setup a new node (all nodes on v1.22.1) and I get “unexpected device id, expected {ITGKY…} got {XYZ}” using no discovery and direct tcp4://{IP}:{not the web ui port} from another node (as the initiator).

On the new node, receiver, I see the following in the logs:

[ITGKY] 2022/11/23 11:36:04 INFO: Listen (BEP/tcp): TLS handshake: tls: invalid signature by the client certificate: ECDSA verification failure
[ITGKY] 2022/11/23 11:36:04 INFO: Listen (BEP/tcp): TLS handshake: tls: client requested unsupported application protocols ([h2 http/1.1])

On the existing note, initiator, I see the following in the logs:

[53NDQ] 2022/11/23 11:26:14 INFO: Pausing ITGKYJS-...
[53NDQ] 2022/11/23 11:28:16 INFO: Resuming ITGKYJS-...

Thank you!

Whatever address you’ve entered isn’t the correct one to reach the other device.

I know it’s hitting the correct device because I see the errors in its logs. And if I shut it down, or put in a different IP or Port, the error changes to, “io timeout”

On the new/receiving node, my “Sync Protocol Listen Addresses” is set to “tcp4://:12345”

On the existing/initiator node, the new Device’s “Addresses” is “tcp4://{external IP}:12345”

Running on Windows, Windows Firewall is off. Port forward is setup on my firewall for {external IP} to {internal IP of new syncthing server}.

I see now that the errors are on the receiving side. Then all I can say is that the connecting party isn’t Syncthing.

I just reset my new Syncthing config (by wiping the Home folder), leaving all defaults enabled, and changing port forwards to 22000.

It found the device via global discovery, but indicates the same thing: “unexpected device id, expected {XPPSK…} got {XYZ}”

[XPPSK] 2022/11/23 12:22:41 INFO: quic://0.0.0.0:22000 detected NAT type: Port restricted NAT
[XPPSK] 2022/11/23 12:22:41 INFO: quic://0.0.0.0:22000 resolved external address quic://{external ip}:22000 (via stun.syncthing.net:3478)
[XPPSK] 2022/11/23 12:23:14 INFO: Joined relay relay://192.154.3.131:22067
[XPPSK] 2022/11/23 12:23:36 INFO: Listen (BEP/tcp): TLS handshake: tls: invalid signature by the client certificate: ECDSA verification failure
[XPPSK] 2022/11/23 12:23:36 INFO: Listen (BEP/tcp): TLS handshake: tls: client requested unsupported application protocols ([h2 http/1.1])
[XPPSK] 2022/11/23 12:24:32 INFO: Listen (BEP/tcp): TLS handshake: tls: invalid signature by the client certificate: ECDSA verification failure
[XPPSK] 2022/11/23 12:25:37 INFO: Listen (BEP/tcp): TLS handshake: tls: invalid signature by the client certificate: ECDSA verification failure
[XPPSK] 2022/11/23 12:25:37 INFO: Listen (BEP/tcp): TLS handshake: tls: client requested unsupported application protocols ([h2 http/1.1])
[XPPSK] 2022/11/23 12:26:32 INFO: Listen (BEP/tcp): TLS handshake: tls: invalid signature by the client certificate: ECDSA verification failure

That indicates it’s not speaking to what it should be speaking to. If you see that at the same time as an error on the other side (you’re not posting the logs that show any device ID errors), then I guess you may have a MITMing proxy of some kind.

I do have a FortiGate firewall and with outbound SSL inspection which could be mangling the data, but oddly, it’s not interfering with an identical setup to a VM hosted at Azure.

Well, SSL inspection is incompatible with Syncthing, so there you go. Maybe it’s not working/active in the Azure case for some reason.

1 Like

ok, thank you, I’ll run with that and stop SSL inspection in firewall policy.

That fixed it! Disabled traffic inspection in firewall via policy, clicked “resume” in Syncthing (initiator node) and the existing node almost immediately appeared on the new node with a “New Device” prompt…

I’m wondering how Azure might be working. Does the Syncthing protocol even support data movement without TLS? If so, how can I confirm if data is encryted (in transit)?

No, it’s always TLS.

Understood. So if I see any data traversing Syncthing at all it must have gotten there via an encrypted TLS connection.

Thanks for everything!