sshuttle?

[D. J. Bernstein]

Has anyone tried setting up sshuttle under Qubes?

After setting up root@netvm to be able to ssh to another machine ("ssh
speed"), I ran

sshuttle -v -r speed 0/0 -x 10/8

and expected that outgoing TCP connections would be transparently
proxied via the ssh connection. The sshuttle program reported that it
was doing

iptables -t nat -N sshuttle-12300
iptables -t nat -F sshuttle-12300
iptables -t nat -I OUTPUT 1 -j sshuttle-12300
iptables -t nat -I PREROUTING 1 -j sshuttle-12300
iptables -t nat -A sshuttle-12300 -j RETURN --dest 127.0.0.0/8 -p tcp
iptables -t nat -A sshuttle-12300 -j RETURN --dest 10.0.0.0/8 -p tcp
iptables -t nat -A sshuttle-12300 -j REDIRECT --dest 0.0.0.0/0 -p tcp --to-ports 12300 -m ttl ! --ttl 42

as I expected, and outgoing TCP connections _from netvm_ were proxied as
I expected, but outgoing TCP connections from other VMs failed with "no
route to host".

I haven't explored how the Qubes intra-host networking setup works,
haven't started debugging with tcpdump, etc.; I'm just hoping that
someone else has already looked at this.

---Dan

[HW42]

D. J. Bernstein:

> Has anyone tried setting up sshuttle under Qubes?

Haven't used it before but I did a quick test.

sshuttle needs to accept connection from external ips (only localhost by
default) and listen on fixed port:
sshuttle -v -l 0.0.0.0:123000 -r speed 0/0 -x 10/8

Allow the redirected packets:
iptables -I INPUT 1 -i vif+ -p tcp --dport 12300 -j ACCEPT

WARNING: This makes FORWARD firewall rules ineffective.


HW42

[Peter Palensky]

I need a sys-sshuttle qube to encapsulate traffic via sshuttle. Locally (from sys-sshuttle) it works, but connected qubes get the previously mentioned "no connection to host" message.

Played around with various nft ideas, but no success.

tcpdump on the vif shows requests (e.g. DNS, http, etc.) but they are not answered.

How do i redirect incoming traffic from vif to the sshuttle process listening on port 12300 as it is happening with local traffic?

[Tim Faber]

Hi Peter,

that does the trick for me (in /rw/config/rc.local on Qubes 4.1):
iptables -I INPUT 2 -i vif+ -j ACCEPT
ip route add local default dev lo table 100
ip rule add fwmark 1 lookup 100

sshuttle --dns -D --method tproxy --exclude REMOTE_SERVER --exclude
10.0.0.0/8 --disable-ipv6 --listen 0.0.0.0:0 -r REMOTE_SERVER 0/0


All the best

> <http://127.0.0.0/8> -p tcp

> > iptables -t nat -A sshuttle-12300 -j RETURN --dest 10.0.0.0/8

> <http://10.0.0.0/8> -p tcp

> > iptables -t nat -A sshuttle-12300 -j REDIRECT --dest 0.0.0.0/0

> <http://0.0.0.0/0> -p tcp --to-ports 12300 -m ttl ! --ttl 42

> >
> > as I expected, and outgoing TCP connections _from netvm_ were
> proxied as
> > I expected, but outgoing TCP connections from other VMs failed
> with "no
> > route to host".
> >
> > I haven't explored how the Qubes intra-host networking setup works,
> > haven't started debugging with tcpdump, etc.; I'm just hoping that
> > someone else has already looked at this.
>
> sshuttle needs to accept connection from external ips (only
> localhost by
> default) and listen on fixed port:
> sshuttle -v -l 0.0.0.0:123000 -r speed 0/0 -x 10/8
>
> Allow the redirected packets:
> iptables -I INPUT 1 -i vif+ -p tcp --dport 12300 -j ACCEPT
>
> WARNING: This makes FORWARD firewall rules ineffective.
>
>
> HW42
>
>

> --
> You received this message because you are subscribed to the Google
> Groups "qubes-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to qubes-users...@googlegroups.com
> <mailto:qubes-users...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-users/6cc6eba0-a1ac-48de-9146-1b3e3db8948dn%40googlegroups.com <https://groups.google.com/d/msgid/qubes-users/6cc6eba0-a1ac-48de-9146-1b3e3db8948dn%40googlegroups.com?utm_medium=email&utm_source=footer>.