[Discuss] sshuttle, a pseudo-VPN built on ssh

[tmetro+blu at gmail.com (Tom Metro)]

A Hak5 episode talked about sshuttle, "a poor man's VPN":
https://github.com/apenwarr/sshuttle

It uses some iptables rules, Python glue, and an ssh tunnel to create a
VPN of sorts.

It's supposed to be simpler to set up than a proper VPN, and doesn't
require root on the end-point, as long as it already has an ssh daemon,
though it does require Python to be present on both ends, and needs root
locally to make the iptables changes.

Quoting the theory of operation:

  sshuttle is not exactly a VPN, and not exactly port forwarding. It's
  kind of both, and kind of neither.

  It's like a VPN, since it can forward every port on an entire network,
  not just ports you specify. Conveniently, it lets you use the "real"
  IP addresses of each host rather than faking port numbers on
  localhost.
  [...]
  [It] creates a transparent proxy server on your local machine for all
  IP addresses that match 0.0.0.0/0. (You can use more specific IP
  addresses if you want; use any number of IP addresses or subnets to
  change which addresses get proxied. Using 0.0.0.0/0 proxies
  everything, which is interesting if you don't trust the people on your
  local network.)

  Any TCP session you initiate to one of the proxied IP addresses will
  be captured by sshuttle and sent over an ssh session to the remote
  copy of sshuttle, which will then regenerate the connection on that
  end, and funnel the data back and forth through ssh.
  [...]
  ...if your "client" machine is a router, everyone on your local
  network can make connections to your remote network.

The readme doesn't address how it handles reverse connections, but based
on the description, particularly the lack of iptables rules on the
remote end-point, I presume it handles only outbound connections.
(Apparently it supports a --listen option for selective reverse
tunneling.) In most typical cases this could be considered an advantage,
as it avoids exposing your local machine to whatever might be on the
remote LAN. (One reason why I generally prefer port forwarding.)

Presumably it is doing NAPT (network address and port translation) on
the far end, creating outbound connections on dynamically allocated ports.


The author's list of reasons why you would use sshuttle include:

  You hate openssh's port forwarding because it's randomly slow and/or
  stupid.

  openssh's PermitTunnel feature...does TCP-over-TCP, which has terrible
  performance...


(I have observed occasional issues with ssh tunneled TCP connections.
I've used security cameras remotely, and while receiving streamed video,
the cameras respond to pan/tilt commands only after a significant delay,
suggesting the tunnel is suffering from buffering problems.)

He goes on to describe the problem with encapsulating TCP:

  ...you can't safely just forward TCP packets over a TCP session (like
  ssh), because TCP's performance depends fundamentally on packet loss;
  it must experience packet loss in order to know when to slow down! At
  the same time, the outer TCP session (ssh, in this case) is a reliable
  transport, which means that what you forward through the tunnel never
  experiences packet loss. The ssh session itself experiences packet
  loss, of course, but TCP fixes it up and ssh (and thus you) never know
  the difference. But neither does your inner TCP session, and extremely
  screwy performance ensues.

  sshuttle assembles the TCP stream locally, multiplexes it statefully
  over an ssh session, and disassembles it back into packets at the
  other end. So it never ends up doing TCP-over-TCP. It's just
  data-over-TCP, which is safe.

I find this explanation to be too vague to explain how it accomplishes
what is claimed. Where is the packet loss permitted? Why does unpacking
and repacking the TCP payload permit this?

Routers facilitate packet loss for flow control, and manage to do so
without disassembling and reassembling TCP packets. Can't iptables be
leveraged to provide this routing behavior?

The theory of operation also doesn't make it clear exactly what the
Python bits are doing. The implication is that it is directly involved
in processing every byte passed through the tunnel, which is not
something you'd normally do with a high-level language like Python.

No mention of benchmarks comparing the performance of this solution to
simple ssh port forwarding tunnels or OpenVPN, though the topic of
performance relative to other options has come up on the project's
discussion group:

why sshuttle is slower than pptp?
https://groups.google.com/forum/?fromgroups=#!topic/sshuttle/G-CrtLz-kPs

Performance testing sshuttle over IPv4 vs. a Back to My Mac-based IPSec
tunnel
https://groups.google.com/d/topic/sshuttle/y-OFAhyDe_Q/discussion

The user in the first posting compared it against several alternatives
and found sshuttle to be twice as fast as a simple ssh port forward, but
as you'd expect, slower than PPTP or a raw connection. So it could in
fact offer a performance boost over simple ssh tunnels.

(I've bcc'ed the author and will forward his reply, if any, to the list,
with his permission.)

 -Tom

-- 
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/