After understanding what tcp_window_scaling is, I could no longer believe that your problem relates to that. The area in firewall is a good one to get into.
Ask your provider if he has following modules properly configured, which are injected into the kernel:
Main vps serverconfiguration
That is for CSF, whi9ch you do not use. But it will help to identify, if these modules are in there and in their absence, if they “may be” causing troubles (not all, though). You could turn off the firewall and install CSF instead, to find the difference.
BTW, CSF declared to give up support for OVZ long times ago. It has been many years, I have not seen OVZ. It has too many disadvantages.
Thats precisely CSF refused to support OVZ, simply because they could not work in harmony. So Eris, you are correct. But to have a bad firewall setting as default, which causes hindrances to exim4 is worse than CSF firewall not in harmony. It will work - if and only if - the modules, as listed in the linked page, are properly configured in the host system.
I run my own libvirt/KVM host with lots of VM guests there. And for several years there was mail server with Debian 9 and VestaCP. I’ve migrated this server to new VM guest under Debian 11 and HestiaCP.
Just fresh install and backup recovery. Same settings in VM.
But it doesn’t work like before.
Changes only in OS (debian 9 - debian 11) and CP (vesta to hestia).
I finally solved my problem…
Changed virtio driver for bridged network card to e1000 in libvirt guest settings.
Whole day no issues with firewall on and tcp_window_scaling = 1.
But the main problem is that every time I send an email to microsoft, for example, it never arrives, and when they send it to me, they get an error saying that it is a problem with the SMTP connection:
Error detectado: 550 5.0.350 Remote server returned an error -> 550 smtp auth required
DSN generado por: DB7P191MB0458.EURP191.PROD.OUTLOOK.COM
I haven’t changed anything since hestia v1.4.15 and it was working fine before, is it possible that some security policy has changed?
The complete error Outlook gives is:
1 22/10/2021
9:53:36 DB8P191MB0635.EURP191.PROD.OUTLOOK.COM DB8P191MB0635.EURP191.PROD.OUTLOOK.COM mapi *
2 22/10/2021
9:53:36 DB8P191MB0635.EURP191.PROD.OUTLOOK.COM DB7P191MB0458.EURP191.PROD.OUTLOOK.COM Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) *
Debian 11 here, the same problem with GMail with emails that has attachments.
2021-11-18 16:26:39 1mnjFV-007OIa-0A H=gmail-smtp-in.l.google.com [172.253.120.26] TLS error on connection (send): The TLS connection was non-properly terminated.
2021-11-18 16:26:39 1mnjFV-007OIa-0A H=gmail-smtp-in.l.google.com [172.253.120.26] TLS error on connection (send): The specified session has been invalidated for some reason.
2021-11-18 16:26:39 1mnjFV-007OIa-0A H=gmail-smtp-in.l.google.com [172.253.120.26]: SMTP error from remote mail server after sending data block: 250 2.0.0 OK m184si76546wme.129 - gsmtp: Connection reset by peer
Emails without attachments goes perfectly, but emails with attachments gets stuck like this in above log.
I respectfully oppose to your confirmation of above.
Eric is 1000% correct, when he said in his message above: “Be careful with 0”.
You can imagine as an example: “If firewall is turned down, some connection will work and therefore firewall should be turned off”. In this case, you confirm that firewall should be turned off always. No, that can only be wrong and Eric can only be correct.
I had my above configuration in Centos all the time and never had problems. Because of Hestia, I divorced with Centos and jumped to Ubuntu. Therefore, I have drawbacks in many areas. But in the area of TCP connections and networking, there is many similarities.
If you have problems with a non-zero config, I suggest that you further investigate it. It will help you and not leave you - like now - exposed to a different set of problems.
I will test next 10 servers with @Deepak suggested sysctl fix, so I will monitoring exim4 log and see if timeout shows up.
I have no other ideas how to be sure if something fixes this issue.
The firewall example in my message above was simply to tell you (by this example) that one cannot generalize from one area of problem with a different area of problem.
Scaling means magnification (увеличавање). Check what happens if you turn scaling off in the following articles:
The above finding means that there is a problem with theb receive window, when the sender had streamed datapackets but the receiver faild to handle it.
So I suggest that you increase the receiver wndow by scaling.
@Deepak
You are probably right, today I saw on one page (related to gmail timeout) that somebody also mentioned rmem_max.
I will compare values from Debian 10, where everything is fine.
Will write here if I conclude something.
Thanks a lot for help.
