Connection failed ERROR: "first record does not look like a TLS handshake"

[JBow87]

Afternoon friends, I’ve finally got all my backups and checks scheduled properly, and it worked properly for the first 48 hours or so (initial backup + scheduled backup the following night), and all checks also completed without errors/all chunks found.

But with last night’s schedule, everything failed with this message:

Running backup command from X:/TEMP/Duplicacy Cache/localhost/1 to back up X:/Yyy
Options: [-log backup -storage [name] -threads 10 -stats]
2023-02-18 02:00:01.489 INFO REPOSITORY_SET Repository set to [x]
2023-02-18 02:00:01.490 INFO STORAGE_SET Storage set to [y]
2023-02-18 02:00:02.381 INFO BACKBLAZE_URL download URL is: [URL]
2023-02-18 02:08:43.735 ERROR STORAGE_CONFIG Failed to download the configuration file from the storage: Head "B2 URL": tls: first record does not look like a TLS handshake

Failed to download the configuration file from the storage: Head "B2 Bucket URL": tls: first record does not look like a TLS handshake

I am unable to execute any of the 15 odd backups now, either with schedule or manually; all logs return the same error. I am also obviously unable to perform any restore operations as well.

All the schedules were set up with the Web-UI.
My master PW is not stored in a keyring.
No files/credentials/keys were moved from any folders.
Each of the three storages involved utilize the B2 master ID/key, and are all encrypted with the same PW (non-RSA, just standard pw upon initialization of storage).
Duplicacy Web and main app were closed, reopened, master pw re-entered, and all operations/connections still fail.
Rebooting the machine doesn’t help.

What is going on here? Why would everything work well for 2 days but suddenly stop working in this fashion?

All help is appreciated!
Thanks,
John

P.S. Forgot to mention – It is possible I was connected to a VPN when I performed the initial backups of these files. Would this cause any potential issues? If so what would be the solution?

[JBow87]

UPDATE: The backups/checks will only complete if I am connected to a VPN now (B2 Bucket+Master Keys).

It doesn’t even matter which VPN IP I use, any Surfshark servers within the mainland U.S. all seem to work…

What the actual hell?

Again, it’s likely the initial backups were created while I was connected to a VPN, if this makes a difference… I am now radically confused.

Is there some simple router setting I can change here perhaps? If so that’s still very odd, as I was initially connected without a VPN to the exact same buckets for about 3 days.

[gchen]

First find the url of the config file. You can find it on the B2 web page by clicking the file link. It should be in the form like this:

https://fxxx.backblazeb2.com/file/bucket/config

Now open this url in the browser on the same computer. Does the server allow you to connect?

[JBow87]

Nope, gives error message:

Secure Connection Failed

An error occurred during a connection to fxxx.backblazeb2.com. SSL received a record that exceeded the maximum permissible length.

Error code: SSL_ERROR_RX_RECORD_TOO_LONG

    The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.

Was connecting just fine with no VPN a few days ago! Very strange.

[JBow87]

BUMP/UPDATE

I read somewhere it could be a Firefox issue, but the SSL error persists in Chrome… so not a browser issue apparently.

[gchen]

Have you checked this post to see if it is the same issue: Duplicacy unable to check BackBlaze storage due to 'connection refused' error on port 443 - #6 by duranki

You can run ping fxxx.backblazeb2.com and make sure this host name doesn’t resolve to a local ip address.

[JBow87]

UPDATE: Solved

As I suspected it was a router issue, but not any sort of the usual suspects like port-forwarding or even basic firewall settings; apparently Comcast (xFi router) has a feature called ‘advanced security’ which ‘detected backblaze servers as malicious phishing attempts’.

This can’t even be accessed by the WebUI router portal now – they force you to download their shitty app (I used Bluestacks) in order to turn off what is essentially an extra ISP-run firewall that no one asked for but probably makes their IT support life easier (small indie company, can’t afford proper support).

It’s not even possible to whitelist IPs or domains permanently, the best you can do is allow access one hour at a time.

Disabled the feature and works just fine (although I’ll probably just use VPN from now on).

In short, Comcast is just as obnoxious of an ISP as ever and this ‘feature’ is trash, breaks commonly used FTTP connections and PLEX servers, is poorly documented, and is intentionally difficult to turn off.

Be advised!