Disable default http redirects on 8007
- Thread starter basisnederland
- Start date
Yes, but it's interesting nevertheless. Could you still please run the
tcpdumps? It would really help a lot, thanks!I think i broke the setup but when i have time, i will rebuild the pbs and try that.
I have done the tcpdumps, but i dont want to put them here as an attachement.
I'd like personal contact to transfer the files save.
I can make an downloadlink with a password,
i than mail the download link with e-mail.
And the password i can send to an mobile phone as 2 factor.
You can provide your mail and mobile to info@basisnederland.nl
Thanks Max Carrara
I'd like personal contact to transfer the files save.
I can make an downloadlink with a password,
i than mail the download link with e-mail.
And the password i can send to an mobile phone as 2 factor.
You can provide your mail and mobile to info@basisnederland.nl
Thanks Max Carrara
Hello everyone! I've got good news: Thanks to the logs and tcpdumps that @basisnederland had sent me, I was able (finally!) to track down the root cause of this bug. I just sent in a patch series containing a fix.
Once this series is applied, you should be able to immediately connect to your PBS instance on the first try, regardless of what circumstances your network is in.
In short, there was an error in the logic that handles the TLS handshake. That part of the code also had a timeout that was way too short - both of those are things that I hadn't considered when I first implemented the HTTP-to-HTTPS redirection feature. See the patch series for more details.
I will let you know once the patches have been merged and packaged. It will probably take some more time, so all you have to do now is be patient.
Thank you all for all of the information you provided! It really helped a lot, especially @basisnederland's tcpdumps.
Once this series is applied, you should be able to immediately connect to your PBS instance on the first try, regardless of what circumstances your network is in.
In short, there was an error in the logic that handles the TLS handshake. That part of the code also had a timeout that was way too short - both of those are things that I hadn't considered when I first implemented the HTTP-to-HTTPS redirection feature. See the patch series for more details.
I will let you know once the patches have been merged and packaged. It will probably take some more time, so all you have to do now is be patient.
Thank you all for all of the information you provided! It really helped a lot, especially @basisnederland's tcpdumps.
Hello!
The patch series has been applied (the commit of the fix can be found here), but it will probably still take a little bit until it's all packaged and released. It will most likely be included in the next version of the
proxmox-backup-server package (unless an issue comes up, but that's unlikely).As always, once everything is packaged, the package will end up in our testing repository first, then in the no-subscription repo, and afterwards finally in the enterprise repository. (See here). This is mostly for quality assurance. So, no worries, it will be shipped eventually.
"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."
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."
This exact issue was bugging me all day with debugging until I found this thread. In my case, I could not get a remote sync working because of this issue.
I got it working by removing my enterprise subscription (!!) and installing the no-subscription edition. This upgraded my backup server (from where I am syncing the data) from version 3.2.7 to 3.2.9, making it work again.
I got it working by removing my enterprise subscription (!!) and installing the no-subscription edition. This upgraded my backup server (from where I am syncing the data) from version 3.2.7 to 3.2.9, making it work again.