My assumption is that the Duplicati config is far, far away from the NIC. Windows owns the NIC. Additionally, .NET is in between. Duplicati is a high level application, not handling any hardware.
That sounds good. I just wanted to suggest an early way to test with it before jumping all-in.
The destination format hasn’t changed. The Duplicati-server.sqlite server database changed.
This makes it somewhat more awkward than usual to revert to old Duplicati, if one wishes to.
More findings:
The NativeErrorCode seems to have gotten split in copying. If I go to Windows error Decoder https://james.darpinian.com/decoder/, -2146893008 search is giving me this for a description:
SEC_E_DECRYPT_FAILURE: The specified data could not be decrypted.
Let’s try checking that claim:
Schannel Error Codes for TLS and SSL Alerts (Microsoft)
TLS1_ALERT_DECRYPTION_FAILED 21
SEC_E_DECRYPT_FAILURE 0x80090330
Plug that hex value into Windows calculator with QWORD length, get
So this Windows error in its SChannel (a.k.a. Secure Channel) appears to be the start of issue. Sometimes the SChannel user can have an impact, but for Duplicati, the user is the .NET code.
I saw some say that NOT using TLS 1.3 avoids issue, but I’m not sure your Windows 10 does it.
allowed-ssl-versions can be tried, but I’m not sure it can be added to the test programs I named.