In a normal tunnel setup, one tunnels at the IP layer, and dumps all IP packets into the tunnel. At the far end of the tunnel, packets are sent onwards based on the far end's routing table. Things like DNS "just work" because everything happens at a layer below TCP and UDP. In this system, he's making it work for each non-tcp using layer 4 protocol separately, leading to weirdness like rewriting /etc/hosts.
For tcp, he's nating all traffic locally to a local server, which then multiplexes all incoming traffic into the ssh connection. The remote side then unmultiplexes the data. I don't fully understand how this avoids tcp over tcp. Maybe I'm dumb. [edit: yeah, I'm dumb. the tcp connection is terminated at the local server, the contents are pumped over the ssh connection, and the remote side opens a new tcp connection]
I wrote this mostly because I read the readme and went "but how does it work?".
sshuttle does not (currently) attempt to do anything other than TCP and DNS. UDP ought to be possible (other than that UDP-over-TCP could have similar problems to TCP-over-TCP, ie. that packets are never lost and this could confuse a hypothetical UDP-based congestion control algorithm). ICMP is probably not possible unless we run the server side as root.
The "--auto-hosts" option you linked to is not the same as the "--dns" option. auto-hosts doesn't capture DNS at all; instead it just adds to your local /etc/hosts. I use this feature much more than --dns, actually, because unlike --dns, it works great if you have multiple tunnels to different offices open at once. (You get all the hostnames from all the offices.)
sshuttle was originally designed to VPN into an office and forward a couple of subnets over. In that case, you often don't want to use the remote DNS server, you just want to know the remote hostnames, because most of your DNS lookups have nothing to do with the remote server. Hence --auto-nets and --auto-hosts.
Nowadays it seems like sshuttle is mostly being used to counter things like Firesheep, which means you want to forward all your traffic to a remote server. In that case --dns - which forwards all your port 53 traffic over the VPN - is preferable.
We could actually do all the other UDP ports the same way we do --dns. We just don't, because I haven't needed it and nobody else has submitted a patch.
In a normal tunnel setup, one tunnels at the IP layer, and dumps all IP packets into the tunnel. At the far end of the tunnel, packets are sent onwards based on the far end's routing table. Things like DNS "just work" because everything happens at a layer below TCP and UDP. In this system, he's making it work for each non-tcp using layer 4 protocol separately, leading to weirdness like rewriting /etc/hosts.
For tcp, he's nating all traffic locally to a local server, which then multiplexes all incoming traffic into the ssh connection. The remote side then unmultiplexes the data. I don't fully understand how this avoids tcp over tcp. Maybe I'm dumb. [edit: yeah, I'm dumb. the tcp connection is terminated at the local server, the contents are pumped over the ssh connection, and the remote side opens a new tcp connection]
I wrote this mostly because I read the readme and went "but how does it work?".