So correct me if I am wrong but this is doing IP in TCP right ? Iirc, this is a big issue for tcp flow control, which relies on packet loss to detect congestion: as you encapsulate stuff in tcp stream, there will be no more packet loss and the tunelled tcp will not throttle correctly.
Did not read the code yet, so maybe there is something to simulate congestion packet loss.
TCP-over-TCP is not as bad as some documents describe. It works surprisingly well in practice, especially with modern congestion control algorithms (BBR). For traditional algorithms that rely on packet loss, DSVPN has the ability to couple the inner and outer congestion controllers, by setting the BUFFERBLOAT_CONTROL macro to 1 (this requires more CPU cycles, though).
This is an intriguing quote. The biggest problem I saw with tcp over tcp is not during the regular operation, but when there was a noticeable packet loss present on the line. Then the the accumulated retransmits on stacked TCP most of the time killed it. Admittedly it was maybe a decade ago after which I concluded itβs just a BadIdea(Tm) and never revisited it.
I had similar experience lately whenever using the mobile internet in poorer coverage cases (eg. a high speed train Brussels-Paris or Brussels-London) which result in frequent and big variations of latency. Of course that all is decoupled congestion control.
If anyone compared the performance of this solution on poor connections with and without BUFFERBLOAT_CONTROL, would be very very interesting to know the results!
WireGuard reconnects in less than a second whereas OpenVPN takes a good 8 (!!) seconds to reconnect. If you have an unstable connection, that's awful. If you only need SSH, Mosh (which utilizes UDP) could be suffice though.
Did not read the code yet, so maybe there is something to simulate congestion packet loss.