Sshuttle is a VPN that runs on top of ssh. It allows connecting to remote networks through any ssh server without requiring administrative access or special server software. Sshuttle uses transparent proxying instead of encapsulating traffic, avoiding issues with TCP-over-TCP. It also includes features like self-assembly, DNS remangling, automatic host and network discovery to simplify VPN configuration and usage.

1. Sshuttle, the unilateral VPN Avery Pennarun 2011 04 30

4. Virtually all implementations are incompatible

5. Not designed for NAT

6. Requires kernel-level support

7. Bloats packets

8. Requires a genius to configure 9

10. Free

11. Still requires kernel-level support

12. Still hard to configure

15. Easy to set up: often installed by default

16. Works with simple password authentication

17. But allows fancy public key crypto

18. Sucks at port forwarding 12

20. Works with any ssh server

21. Exactly as easy as ssh

22. Leaves all the crypto to ssh

23. Gets through NAT as easily as ssh

24. Needs no admin access on the server 14

26. But when carrying TCP over TCP, the inner TCP never experiences packet loss because the outer TCP fixes it 17

28. How do they know the link between is only 1 MBit? 18

30. The slow link drops packets if you send too fast

31. And TCP notices this and slows down 18

33. How do they know to transmit at only 500 kbits each? 19

39. People see routers dropping packets and try to “fix” it by adding big buffers

40. Your cable modem or DSL router does this

41. The Linux kernel does this

42. And it destroys TCP performance

43. That's the only reason why large uploads (Bittorrent) make your Internet suck 22

45. ...and the link is 6 MBit (600 kbytes/sec)

46. Then you have about 0.1*600 = 60 kbytes in flight at any moment

47. a 600 kbyte buffer means 10 seconds of latency

48. The “right” buffer is roughly bandwidth*delay

49. “ As big as possible” is always wrong! 24

52. Doesn't use a “tap” interface and capture packets

53. Uses “transparent proxying” instead

54. Kind of like the old SLiRP tool

55. Unwinds the inner TCP and sends the payload 26

57. Unfails TCP Slow Start algorithm by sharing it between connections

58. Reduces TCP/IP overhead instead of adding it (especially by merging small packets)

60. Can use simple, well-understood streaming encryption (ssh is more trustworthy than IPsec) 28

62. sshuttle uses a cheap hack to keep latency low even in heavy-traffic situations

63. So if you upload and ssh at the same time, use sshuttle... it'll suck less 29

64. But that's not all...

67. The server always has the latest features

69. Self-assembly: Phase 1 ssh myserver “ python -c ' import sys; skip_imports=1; verbosity=0; exec compile(sys.stdin.read(764), amp;quot;assembler.pyamp;quot;, amp;quot;execamp;quot;) ' ” 32

70. Self-assembly: Phase 2 import sys, zlib z = zlib.decompressobj() mainmod = sys.modules[__name__] name = 1 while name: name = sys.stdin.readline().strip() if name: nbytes = int(sys.stdin.readline()) content = z.decompress(sys.stdin.read(nbytes)) exec compile(content, name, "exec") mainmod.__dict__[name[:-3]] = mainmod main() 34

72. But we make an exception for DNS

73. Packets destined for your local nameserver get bounced to the remote one instead

74. And answers pretend to come from your local one 35

76. Maybe you only want the remote computer names in your local DNS

78. reverse DNS, netstat -a

79. and so on 36

81. --auto-nets just asks the server which routes are local

82. And sets up your local routing to send those over the VPN 37

85. Also, there is a fancy MacOS GUI

86. Demo 38

87. Questions? 40