Can you elaborate? i've found the opposite to be true, but then I am usually restricted by crappy ADSL bandwidth of 6mbit or less so i could be more sensitive to different aspects of "slow".
Note that sshuttle deconstructs the TCP packets before sending them over SSH which already uses TCP, it also performs differently to `ssh -D` and manages the buffer to prevent blocking behaviour over bandwidth limited connections:
--no-latency-control
Sacrifice latency to improve bandwidth benchmarks. ssh uses re‐
ally big socket buffers, which can overload the connection if
you start doing large file transfers, thus making all your other
sessions inside the same tunnel go slowly. Normally, sshuttle
tries to avoid this problem using a “fullness check” that allows
only a certain amount of outstanding data to be buffered at a
time. But on high-bandwidth links, this can leave a lot of your
bandwidth underutilized. It also makes sshuttle seem slow in
bandwidth benchmarks (benchmarks rarely test ping latency, which
is what sshuttle is trying to control). This option disables
the latency control feature, maximizing bandwidth usage. Use at
your own risk.
Note that sshuttle deconstructs the TCP packets before sending them over SSH which already uses TCP, it also performs differently to `ssh -D` and manages the buffer to prevent blocking behaviour over bandwidth limited connections: