Thanks Tim! In my case (Qubes 4.2) it was 

nft add rule ip qubes custom-input iifname "vif*" accept

On Saturday, March 30, 2024 at 3:00:59 PM UTC+1 Tim Faber wrote:

> 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
>
>
> On 3/30/24 12:52, Peter Palensky wrote:
> > 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?
> > On Wednesday, February 18, 2015 at 9:05:10 PM UTC+1 HW42 wrote:
> > 
> > D. J. Bernstein:
> > > Has anyone tried setting up sshuttle under Qubes?
> > 
> > Haven't used it before but I did a quick test.
> > 
> > > 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
> > <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
> >.
>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/7ee4407b-c3c9-4653-b16d-b79213fa7428n%40googlegroups.com.

Reply via email to