After Upgrade to v5.13.1 HTTPS Farms not working correctly #125
Comments
MakcaR
changed the title
|
An update became available today: the problem is gone. Thanks to the developers for their promptness. |
|
I hurried to rejoice. |
Could you clarify what you mean by "contacting via the web" and "contacting through the client"? If I had to guess, perhaps you are trying to connect to the service via HTTP while using an HTTPS listener on the zproxy. Could you try connecting explicitly using HTTP and also explicitly using HTTPS, tell me the results, and send in a supportsave with the results? Meanwhile I'll try to reproduce the issue. Thank you for your cooperation. |
|
Yes, I apologize for the confusing description of the problem.
|
|
Could you show me the error that the client is receiving? Particularly I'd like to see what the web console (in the browser) has to say when the client fails to connect. |
|
if we use a browser, there is no problem, I can't reproduce it I can give logs from backends, I attach part of the log 10.10.0.121, -, 3/20/2023, 12:33:17, W3SVC1, 1c-lic-0, 10.10.0.26, 1, 102, 792, 200, 0, GET, /thinclient/, -, |
|
@MakcaR I'm unsure as to where those logs are coming from. Could you clarify? Also, I'm not sure exactly how the "Thin Client" is trying to "open the database". Do you mean it's trying to connect to the database directly via some protocol other than HTTP/HTTPS, and through the load balancer? |
|
He is trying to connect over https, and only over it. |
|
my load balancer is a cluster of 2 nodes, can it affect? as far as I understand, there was no update of the cluster package. |
In 5.13 we've upgraded to a new zproxy implementation that's supposed to be an improvement upon the older zproxy. Though we seem to still be filling out the edges. Could you try seeing what SSL/TLS versions are being used by your thin client and ensuring that the load balancer is configured to work with those versions? |
|
good question!, I will try to look / search for information about this from the developers of the accounting system. |
Considering the HTTPS parameters you've just displayed, my guess is that the only protocols enabled are TLSv1.2 and TLSv1.3. Something you could try, if your able, is enabling the other protocols available to see if perhaps it is simply an issue of the protocols you're using (that is, to untoggle the disabled options you have for HTTPS parameters). Please report your findings, thank you. |
|
I would agree with you if I was just setting up the work of the load balancer and backends on IIS for the first time, but!!!, the configuration of the load balancer and HTTPS farm, which in the screenshot did not change and was configured more than 6 months ago on v5.11, then there was an update to 5.12 and there were also no problems with either the load balancer or with backends... and only after the update to 5.13, the rpoblema appeared... then updating to 5.13.1 did not solve the problem. the removal of the zproxy/buster 0.9.2-5.13.1 package solved the problem for the case of working through the browser (I wrote above that users work in 2 ways with the application), but the problem remained for working with the "Thin Client" method. |
|
as for SSL/TLS that the application backend uses, I looked in the documentation of my application and the developers confirmed that everything is supported, and those that are allowed on IIS that are on the backend are used for data transmission. in my case, these are the ones in the screenshot. For clarity, I will show you through IIS Crypto |
|
@MakcaR I agree, this is not an issue with your configuration. My intention with enabling (for testing purposes) the other protocols would be to see, not if your configuration is a problem, but if the internal logic of zproxy SSL protocol handling needs to be revised. What I'd need to know isn't what is supported by your backends, but what is supported by your thin client which sends the request to zproxy. |
|
on clients, the situation is the same, SSL/TLS uses those that are allowed in the OS on which the "Thin Client" is running. We have it all starting with TLS 1.0 and higher. |
|
in the documentation for the application 1C:Enterprise I found this: In order for the system "1C:Enterprise" could correctly determine the HTTP request of the client application and some parameters of the client application, it is necessary to configure the reverse proxy in such a way that: ● To "restore" an HTTP request: when forwarding an HTTP request, the request headers X-Forwarded-Port, X-Forwarded-Host and X-Forwarded-Proto were formed accordingly. ● To correctly determine the IP address of an external client application: when forwarding an HTTP request, the X-Forwarded-For request headers were formed accordingly. But I don't understand yet where to look at it or configure it on the farm |
|
just in case, the network scheme is like this. And users who come from remote sites have no problems, there is a problem only with local network users 10.10.1.0/27 |
|
@MakcaR Is the issue with any user in the 10.10.1.0 subnetwork, or just with the thin client? If at all possible, could you give me a client log of the error, such as a 4xx/5xx response or something of the sort? |
|
We turned on the log on the client machine and that's what we see, every time the information window falls out that the connection is lost: 15:58.703000-0,EXCP,1,process=1cv8c,OSThread=13968,Exception=580392e6-ba49-4280-ac67-fcd6f2180121,Descr='src\vrscore\src\VResourceConnectionImpl.cpp(608) : fully assembled log file attached |
|
We tested the connection from users' machines from the "Thin Client" directly to IIS on backends, bypassing the load balancer. There is no problem described above, the test was performed on each of the two backends to make sure that both work fine |
Is it possible that your thin client is utilizing websocket to connect? This is an issue that has been reported by other users (e.g. #123). |
|
no the websocket is not used, and users who work via the Internet have no problem. there are only those who work on the same site where the load balancer, only in another subnet, according to the scheme above |
|
Would it be possible for you to generate a HAR file containing the failing requests? I'd like to see the requests and responses. |
|
HAR can be collected only by means of MS EDGE, but there are just no problems when working through the browser. But so as to understand what requests are coming, during the session I'll try to collect something via Wireshark, I'll post it by the evening |
That would be very helpful. Thank you very much. And thank you for the HAR file. |
naortega
changed the title
|
And so I spent a little time to conduct tests and capture through Wireshark.
IP of the test user machine 10.10.1.10 |
|
Dear @MakcaR ,
Looking forward to your response, |
|
Yes, mostly errors with POST requests supportsave supportsave_nlb-1_20230322_1818.tar.gz sent to support@zevenet.com according to point 3, I will conduct the test tomorrow during the day |
|
Hi @MakcaR , Good news. We have a new binary with several fixes that might resolve your issues. Please download it from here: https://drive.google.com/file/d/1s9iA28TsD07kcvr5OSIiHW5l8J562KsV/view?usp=share_link You've to upload to the appliance and rename it in the path /usr/local/zevenet/app/zproxy/bin/zproxy After that, please restart the farms and let us know how it goes, |
|
Hi, I think the problem is that the application cannot work on TLS 1.3, and the farm raises this protocol, not TLS 1.2. and in the farm settings there is no way to disable the use of TLS 1.3. If I connect directly to the Backends, the connection is raised via protocol 1.2 and there is no problem. |
|
Hi @MakcaR could you please try this binary out? The SSL options in the proxy have not been changed, isn't it? Thanks! |
|
No, I haven't changed anything, I haven't touched anything there for a long time. |
|
Ok thank you for the confirmation @MakcaR https://drive.google.com/file/d/1Yx7rXgrljgLVvhVFTUbKptJbUWiGkajk/view?usp=share_link Thank you. |
|
with the zproxy_force_ssl_ps option, the problem was not solved, although the number of breaks decreased now it is already possible to login to the application, before the breaks were at the stage of the login password prompt |
|
@MakcaR could you please try to add in the configuration file the directive: Disable TLSv1_3 Just below the Ciphers directive. Then, restart the farm to apply the changes. Thank you, |
|
added to config file /usr/local/zevenet/config/1CService_proxy.cfg the connection, anyway, uses protocol TLS 1.3 |
|
Hi @MakcaR, please download the zproxy binary from here and apply it in zevenet. Please let me know if it's working now with the thin clients. Thank you. |
|
With the latest version of the zproxy_tls file, the connection goes over TLS 1.2 protocol, but connection losses are still present. |
|
Hi @MakcaR, please enable the farm logs, then reproduce the problem and finally, please regenerate a fresh support save (send it via support@zevenet.com ). Thanks. |
|
Hi, |
|
Hi, |
Good day, @bcnet-dev Are you referring to that there are certain chunked responses/requests that are not being sent in full? If so, we have issued a patch for this issue in version 5.13.2, though this version does not seem to work for you. Please the issue you seem to be having, and send a support save, and if possible a HAR, to support@zevenet.com. |
|
Over the past couple of weeks, there have been several update packages, but my problem has not been solved. In general, while we are sitting through a workaround TCP farm. This of course creates some problems, but in this mode I have only 15 users, so it is tolerable for now. |
|
Dear @MakcaR , in regards the TLS 1.2 connection please update, ensure you've only "Disable TLS1.3" enabled and try again. It should work, otherwise, please share again a fresh supportsave and HAR (or wireshark trace) via support@zevenet.com . Thank you. |
|
Hello, |
|
Hi @bcnet-dev , the connection is be performed? or you're experiencing outages? could you provide a support save via support@zevenet.com ? Also, a wireshark trace could be useful. Thank you. |
hi, |
|
@MakcaR Sorry for taking a while to get back to you. Would it be possible for you to add the following directive manually to your Zproxy configuration? This should be placed inside the ListenerHTTPS block. |
|
Made changes to the config, but it didn't solve the problem. and supportsave_nlb-0_20230513_1817.tar.gz sent to support@zevenet.com |
when trying to access a farm with an https Load Balancer, the connection is terminated.
the load balancer and users are in different subnets.
The architecture is like this:
The pfsense firewall has a subnet for application servers 10.10.0.0/25 and a subnet for users (workstations) 10.10.1.0/27.
An https-type company has an address of 10.10.0.13, users open the Web address of the 1C accounting system application. The web interface of the accounting system is organized through 2 web servers, which are just the backends of the https farm.
An unrecoverable error
Error when executing a GET request to the /e1cib/metadata/splash resource:
due to:
HTTP error when accessing the server: https://xxxx.xxxxxxxs.com
Transferred a partial file
before the upgrade to v5.13.1 (on version 5.12), the problem was not observed
supportsave_nlb-0_20230316_1913.tar.gz
The text was updated successfully, but these errors were encountered: