The site does not open. TLS. What is the problem?

Question

Wireshark

Site https://hosting.wialon.com
Opened through any provider.

For some reason, the TLS handshake goes through us for an incredibly long time, and then with a 99% probability the site will reset the connection.
We take BGP from the Beeline, while the site opens normally from the Beeline Internet on the same computer.

The site also does not open via http, since apparently there are links to https in the content.

I open the site for an example from tele2, and from us.
Here are two screenshots of the command execution
openssl s_client -connect hosting.wialon.com:443
In the console, it looks the same, just after the response "CONNECTED (00000003)" nothing happens for 30 seconds, then the certificate falls out.
Through tele2, the certificate arrives immediately.
In console:

openssl s_client -connect hosting.wialon.com:443 via us

https://pastebin.com/cJVeEx1Z

openssl s_client -connect hosting.wialon.com:443 via tele2

https://pastebin.com/ifegrSta

in wireshark:

We:

Tele2:

Wireshark dumps:

We:

https://yadi.sk/d/XLhlZVcZRGdKUw

Tele 2:

https://yadi.sk/d/en4aWQjNu1Zm1A

I have no idea where to dig.
What could be the snag if, with the
Beeline- BGP - We
scheme, the site opens for the Beeline, but not for us.

Can there be some hosting restriction on the subnet of our external addresses?

The problem manifests itself in all our subscribers.

Answer 1

Judging from the dump, packets do not reach the server or the server discards your packet. Perhaps the packet is split, TLS does not like fragmentation.
Compare the MTU on your ISP and on Tele2.
https://help.keenetic.com/hc/ru/articles/214470885...
https://networkdirection.net/https-fragmentation-a...
The data to be sent is represented at the TCP level as a stream of bytes, where each bytes are sequentially numbered. TCP divides the stream into parts - segments - and transfers them to a lower (network) level for sending to the recipient. The segment header indicates its number (Sequence number, Seq) - the number of the first byte of the segment in the general stream.
The recipient receives the segments and collects the original continuous stream of bytes from them, sends acknowledgments.
In the header, it indicates the Acknowledgment number (Ack) - the sequence number of the next segment expected from the sender. The Ack value means that the entire contiguous sequence of bytes from the first to Ack-1 was received successfully. According to the specification, confirmation is not required for each segment. One acknowledgment can be sent to several received segments at once.