https://serverfault.com/a/1066233

gistfile1.txt

In my understanding, the "tcp meltdown" problem is not difficult to solve:
you only need to set a large retransmission timeout for the inner tcp connection.

By greatly increasing the minimum retransmission timeout of the inner TCP connection,
we have effectively disabled the timeout retransmission mechanism of the inner TCP.
Therefore, the TCP meltdown problem is avoided.

For example, in linux, you can use ip route replace 192.168.168.1/24 via 192.168.168.2 rto_min 12s
to increase the minimum retransmission timeout of all internal connections established through OpenVPN
from 0.2 seconds to 12 seconds (It is assumed that 192.168.168.1/24 is your OpenVPN network segment).

You can set the above command as OpenVPN's up event callback.
In this way, we have actually avoided the tcp meltdown problem in a simple way.

We use this method to optimize the tcp-over-tcp link.
Even on the line with high latency (hundreds of milliseconds) and high packet loss,
we have not found any adverse effects.

PS: On a line with high latency, high packet loss, and high bandwidth,
it is obvious that you need to prepare a large window
for the inner tcp connections to take up the full bandwidth.

UPDATE:
The question here is that why TCP-over-TCP doesn't have a noticeable effect on TCP based VPN?
Because on a high-quality line that rarely loses packets, the TCP meltdown phenomenon is not prominent.