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.
On the other hand, the way it works is more like ssh port forwarding than a VPN. Normally, a VPN forwards your data one packet at a time, and doesn't care about individual connections; ie. it's "stateless" with respect to the traffic. sshuttle is the opposite of stateless; it tracks every single connection.
You could compare sshuttle to something like the old Slirp program, which was a userspace TCP/IP implementation that did something similar. But it operated on a packet-by-packet basis on the client side, reassembling the packets on the server side. That worked okay back in the "real live serial port" days, because serial ports had predictable latency and buffering.
But 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 would say probably not. SSL based vpn is pretty common, and that's always done over TCP. Cisco does support DTLS, and ipsec happens below TCP, so it just depends on your provider.
An SSL based VPN can be done within a UDP wrapper. The outer layer can't be encrypted or the connection wouldn't work. It's the payload that carries your (TCP/UDP) traffic out at the other end of your VPN.
It uses iptables (on Linux) to route all traffic (or selected traffic) through the client-side component, and then forward it all to the server-side component.
"ssh -D" is closer to a proxy server:
-D [bind_address:]port
Specifies a local "dynamic" application-level port forwarding.
This works by allocating a socket to listen to port on the local
side, optionally bound to the specified bind_address. Whenever a
connection is made to this port, the connection is forwarded over
the secure channel, and the application protocol is then used to
determine where to connect to from the remote machine. Currently
the SOCKS4 and SOCKS5 protocols are supported, and ssh will act
as a SOCKS server. Only root can forward privileged ports.
Dynamic port forwardings can also be specified in the configura-
tion file.
On the other hand, sshuttle is closer to a VPN connection. If you're confused about the difference between a proxy and a VPN, then I suggest you hit up Wikipedia and do some reading.
