Inconsistent SSL error (routines:: wrong version number)

[ruben.urresti]

I am currently setting up a Proxmox Backup Server (PBS) to store my Proxmox Virtual Environment (PVE) backups.

When I tried to add the PBS as a new storage location, I encountered the following error:

create storage failed: pbs1: error fetching datastores - 500 Can't connect to pbs1.example.com:8007 (SSL connect attempt failed error:0A00010B:SSL routines::wrong version number) (500)

Initially, I thought this might be due to using a self-signed certificate. So, I purchased and installed a proper SSL certificate via the GUI. However, the same error persisted.

Interestingly, after seeing the error message a few times, if I click 'Add' again, the server eventually adds the remote storage without any issues. But when attempting to write a backup, the same error occurs. If I try to initiate the backup a few more times, it eventually works. This behavior makes it impossible to get scheduled backups working, because this set-up requires manual retries to succeed.

Extra hint:
Sometimes when I try to access the web GUI after a long time, I get an 'SSL Protocol Error' in my browser. Similar to the previous issue, a few refreshes resolve the problem.

 

[fgavello]

Tengo el mismo problema

 

[dcsapak]

do you have any firewall/reverse proxy or similar in front of the pbs? it seems like something is interfering with the tls connection

 

[ruben.urresti]

do you have any firewall/reverse proxy or similar in front of the pbs? it seems like something is interfering with the tls connection

Nope, just port-forwarded port 8007 on the router to the server with a plain install of PBS.

I also thought it could be my UFW so I disabled that using $: ufw disable
Made no difference...

EDIT:
UFW was apparently still running, so I disabled it and rebooted the machine. It seems to be working for now, but I will check it again tomorrow because sometimes the results are very inconsistent.

If this really fixes the issue permanently, then my question would be: why is UFW causing this strange behavior? My rules are nothing special, only this:

To                         Action      From
--                         ------      ----
Anywhere                   ALLOW       192.168.0.0/16      
Anywhere                   ALLOW       <MY_REMOTE_NETWORK>/30

 

[ruben.urresti]

Update:
After disabling the firewall it got a lot better. Before, every scheduled backup was failing. Now, only 2 out of the 100 back-ups failed due to the same error. Don't know why it still happens sometimes but I could live with these results.

 

[dcsapak]

IMO this indicates that something is not quite right with the network packages and it seems that something introduces errors in them, but i cannot really say what that would be (maybe it's just a hardware issue like a broken nic/cable?)

 

[Max Carrara]

IMO this indicates that something is not quite right with the network packages and it seems that something introduces errors in them, but i cannot really say what that would be (maybe it's just a hardware issue like a broken nic/cable?)

I'm investigating in this thread over here: https://forum.proxmox.com/threads/disable-default-http-redirects-on-8007.142312/

It's definitely related to #5105, but I still wasn't able to reproduce this issue, unfortunately. I don't necessarily think it's an issue regarding NICs / cables, as it only started to appear after I had implemented the automatic redirect to HTTPS. My current guess is that OpenSSL isn't playing along here -- curiously, it works on PVE without any problems.

 

[SamTzu]

"It is very likely that the server does not speak TLS at all.
The client will start with the TLS handshake and the server will reply to this with some non-TLS response. The client expect the server to do its part of the TLS handshake though. Thus it will try to interpret the servers as response as TLS. This will lead to strange error messages depending on the TLS stack used by the client. With OpenSSL based stacks it will often result in wrong version number, since the trying to extract the TLS version number for the expected TLS record and get some unexpected results since the server did not actually send a TLS record."