UDP Support?

[Peter Valdemar Mørch]

Hi,

Is there a way for me to access UDP based services in the remote
network using sshuttle?

I just tried git master HEAD and it seems UDP isn't supported over
sshuttle. I can setup UDP-over-TCP tunnelling for a particular IP
address with raw ssh and socat and it works, but is a pain to
configure especially for access to many hosts.

There have been a couple of posts about UDP but most have been about
DNS, which seems to work now. I need SNMP on UDP port 161, though, and
I'm prepared to accept even very poor performance.

I'm hoping sshuttle can do that - in addition to all the other goodies
it brings me. I've written in my notes about sshuttle 'SSH
forwarding / VPN - also UDP', but can't remember why I wrote that. :-(

Thank you for reading this far,

Peter

[Peter Valdemar Mørch]

I guess I found the answer myself. On May 30, 4:35 am, Avery Pennarun
<apenw...@gmail.com> wrote[1]:

> Of course, I might like to proxy more UDP than just DNS someday. For
> that, we need something smarter than what we have today. (And anyway,
> UDP-over-TCP is a bad idea, so we'd have to get *much* smarter.)

So I take it that UDP (e.g. for SNMP which would be useful to me) is
*not* supported today.

Would "naive" UDP be hard to add? As I said, for my SNMP needs,
performance is not a concern. In the thread "UDP Support", on Aug 21
2010, 10:02 am, after describing why artificially making UDP-over-TCP
reliable can be dangerous, Avery Pennarun <apenw...@gmail.com>
wrote[2]:
> But most people just want to forward DNS or WINS traffic. For that,
> there's no big deal, and I would welcome patches to sshuttle to make
> that work :) (It should be pretty easy, I think.)

Where would one start with such a patch? I don't know the code at all,
and a starting point/direction would be helpful! Easy sounds, well,
easy!

Sincerely,

Peter

1: http://groups.google.com/group/sshuttle/browse_thread/thread/b12cbe392c8b9c62
2: http://groups.google.com/group/sshuttle/browse_thread/thread/db21bb91704d068c

[Brian May]

On 15 July 2011 17:17, Peter Valdemar Mørch <pmo...@gmail.com> wrote:
> So I take it that UDP (e.g. for SNMP which would be useful to me) is
> *not* supported today.

UDP and IPv6 is supported in my tproxy branch.

https://github.com/brianmay/sshuttle/tree/tproxy

There are some requirements on the client end (these don't apply on the server):

* you do need a recent version of iptables (git version unless there
has been a recent release) and a recvmsg function binding (either by
patching Python or with PyXAPI-0.1 API. I have plans to get this added
to Python, but probably won't get in 2.x versions.

If there was serious interest, I could also upload my patched python
2.7 Ubuntu packages, compiled against natty to an Ubuntu PPA.

* For full support also do need to type in the following commands,
once only, as root, manually (top two are IPv4 only bottom two are
IPv6 only):

ip route add local default dev lo table 100
ip rule add fwmark 1 lookup 100
ip -6 route add local default dev lo table 100
ip -6 rule add fwmark 1 lookup 100

* sshuttle needs to be started as root. I use:

sudo SSH_AUTH_SOCK="$SSH_AUTH_SOCK"
$HOME/tree/sshuttle.tproxy/sshuttle --method=tproxy $OTHERPARAMS

This means ssh can access my ssh-agent socket.

> Would "naive" UDP be hard to add? As I said, for my SNMP needs,
> performance is not a concern. In the thread "UDP Support", on Aug 21
> 2010, 10:02 am, after describing why artificially making UDP-over-TCP
> reliable can be dangerous, Avery Pennarun <apenw...@gmail.com>
> wrote[2]:

The one issue I have had it sshuttle has no way of knowing when to
"close" the UDP connection, because UDP is stateless. So my current
implementation is hard coded to close it after it is idle for 30
seconds. Should be fine for DNS, WINS, and SNMP.
--
Brian May <br...@microcomaustralia.com.au>

[Peter Valdemar Mørch]

Thanks Brian for your posting. Sorry it has taken a couple of days to
respond:

On Jul 17, 3:48 am, Brian May <br...@microcomaustralia.com.au> wrote:
> * you do need a recent version of iptables (git version unless there
> has been a recent release) and a recvmsg function binding (either by
> patching Python or with PyXAPI-0.1 API. I have plans to get this added
> to Python, but probably won't get in 2.x versions.

I installed, configured, made and installed the git version of
iptables no problem. Rebooted to be sure.

My python under-the-hoods development is very limited... I downloaded
the tar.gz file[1] referenced from the PyXAPI home page[2], and ran
$ configure && make && sudo make install
It looked like it went well.

When I then tried to use it with:

$ sudo SSH_AUTH_SOCK="$SSH_AUTH_SOCK" $HOME/sshuttle/sshuttle --
method=tproxy -r root@cosmo:22000 172.27.114.0/24

I got this stack trace when I tried to use SNMP:

Traceback (most recent call last):
File "/home/pvm/sshuttle/main.py", line 184, in <module>
opt.syslog, opt.daemon, opt.pidfile))
File "/home/pvm/sshuttle/client.py", line 702, in main
daemon)
File "/home/pvm/sshuttle/client.py", line 541, in _main
ssnet.runonce(handlers, mux)
File "/home/pvm/sshuttle/ssnet.py", line 567, in runonce
h.callback()
File "/home/pvm/sshuttle/ssnet.py", line 469, in callback
self.handle()
File "/home/pvm/sshuttle/ssnet.py", line 457, in handle
self.got_packet(channel, cmd, data)
File "/home/pvm/sshuttle/ssnet.py", line 418, in got_packet
callback(cmd, data)
File "/home/pvm/sshuttle/client.py", line 403, in <lambda>
mux.channels[chan] = lambda cmd,data: udp_done(chan, data, method,
listener, dstip=srcip)
File "/home/pvm/sshuttle/client.py", line 384, in udp_done
sender = socket.socket(sock.family, socket.SOCK_DGRAM)
NameError: global name 'sock' is not defined

Am I doing something wrong?

1: http://www.pps.jussieu.fr/~ylg/PyXAPI/PyXAPI-0.1.tar.gz
2: http://pypi.python.org/pypi/PyXAPI/

Peter

[Brian May]

On 19 July 2011 00:46, Peter Valdemar Mørch <pmo...@gmail.com> wrote:
> Traceback (most recent call last):
>  File "/home/pvm/sshuttle/main.py", line 184, in <module>
>    opt.syslog, opt.daemon, opt.pidfile))
>  File "/home/pvm/sshuttle/client.py", line 702, in main
>    daemon)
>  File "/home/pvm/sshuttle/client.py", line 541, in _main
>    ssnet.runonce(handlers, mux)
>  File "/home/pvm/sshuttle/ssnet.py", line 567, in runonce
>    h.callback()
>  File "/home/pvm/sshuttle/ssnet.py", line 469, in callback
>    self.handle()
>  File "/home/pvm/sshuttle/ssnet.py", line 457, in handle
>    self.got_packet(channel, cmd, data)
>  File "/home/pvm/sshuttle/ssnet.py", line 418, in got_packet
>    callback(cmd, data)
>  File "/home/pvm/sshuttle/client.py", line 403, in <lambda>
>    mux.channels[chan] = lambda cmd,data: udp_done(chan, data, method,
> listener, dstip=srcip)
>  File "/home/pvm/sshuttle/client.py", line 384, in udp_done
>    sender = socket.socket(sock.family, socket.SOCK_DGRAM)
> NameError: global name 'sock' is not defined

Looks like a bug in my code.

It looks like "sock.family" needs to be replaced with just "family" on
line 384 of client.py.

Will test this out myself and upload a fix. Thanks for the report.
--
Brian May <br...@microcomaustralia.com.au>

[Brian May]

On 19 July 2011 09:29, Brian May <br...@microcomaustralia.com.au> wrote:
> Will test this out myself and upload a fix. Thanks for the report.

As it happened, there were several more bugs in the UDP code. Have
fixed them, and pushed my changes to my repository.

It now works with both versions of the recvmsg function for DNS traffic.

Thanks again.
--
Brian May <br...@microcomaustralia.com.au>

[Peter Valdemar Mørch]

Yiiihar! It works!!! :-) Thanks for the help!

[Peter Valdemar Mørch]

My previous test was on a Ubuntu Natty based system, like what I use
for my desktop. Where I really need it is for debian lenny, and there,
I get this error:

# ./sshuttle --method=tproxy -r root@cosmo:22000 172.27.114.0/24

Traceback (most recent call last):

File "./main.py", line 184, in <module>
opt.syslog, opt.daemon, opt.pidfile))
File "/root/sshuttle/client.py", line 688, in main
tcp_listener.setsockopt(socket.SOL_IP, IP_TRANSPARENT, 1)
File "/root/sshuttle/client.py", line 199, in setsockopt
self.v6.setsockopt(level, optname, value)
File "<string>", line 1, in setsockopt
socket.error: (92, 'Protocol not available')

TCP works without the --method=tproxy, but it won't even connect with
--method=tproxy.

I seem to remember something about the tproxy stuff requiring a
relatively new kernel. Debian lenny uses 2.6.26, and is that the
problem? What is the minimum?

Peter

[Roger]

On Tue, Jul 19, 2011 at 9:31 PM, Peter Valdemar Mørch <pmo...@gmail.com> wrote:

I seem to remember something about the tproxy stuff requiring a
relatively new kernel. Debian lenny uses 2.6.26, and is that the
problem? What is the minimum?

You're right. 2.6.37 or greater is required.

Roger

[Roger]

PS: the depedenices (kernel and iptables) are on the client side. Nothing special on the server side.

[Peter Valdemar Mørch]

Sorry to bug this list again, but I still can't get it working on
lenny, I'm affraid. I built a 2.6.39.3 kernel and tried once more:

host:~/sshuttle# ./sshuttle --method=tproxy -r root@cosmo:22000
172.27.114.0/24
Debian GNU/Linux lenny/sid

Connected.
host: No chain/target/match by that name.
fatal: ['iptables', '-t', 'mangle', '-A', 'sshuttle-t-12300', '-m',
'socket', '-j', 'sshuttle-d-12300', '-m', 'tcp', '-p', 'tcp'] returned
1
client: fatal: cleanup: ['python', './main.py', 'python', '--
firewall', '12300', '12300', '0', '0', 'tproxy', '1'] returned 99
host:~/sshuttle# uname -r
2.6.39.3
host:~/sshuttle# iptables --version
iptables v1.4.11.1

:-(

I tried running the iptables command by hand:

host:~/sshuttle# iptables -t mangle -A sshuttle-t-12300 -m socket -j
sshuttle-d-12300 -m tcp -p tcp
iptables v1.4.11.1: Couldn't load target `sshuttle-d-12300':No such
file or directory

But I'm guessing this one command is part of a larger scheme and
doesn't point to a problem.

Any ideas?

Gratefully,

Peter

[Brian May]

On 20 July 2011 04:59, Peter Valdemar Mørch <pmo...@gmail.com> wrote:
> host:~/sshuttle# iptables -t mangle -A sshuttle-t-12300 -m socket -j
> sshuttle-d-12300 -m tcp -p tcp
> iptables v1.4.11.1: Couldn't load target `sshuttle-d-12300':No such
> file or directory

That is just a bit weird, because it implies that the sshuttle-d-12300
table isn't created at the time.

However it is created (and flushed) several lines above that line that
failed. In the same if block in fact.

Can you please rerun with -vvv and post the results here? Also "sudo
iptables -L -t mangle -n" will show if that table really exists or
not.

Thanks
--
Brian May <br...@microcomaustralia.com.au>

[Peter Valdemar Mørch]

On Wed, Jul 20, 2011 at 1:55 AM, Brian May <br...@microcomaustralia.com.au> wrote:

Can you please rerun with -vvv and post the results here? Also "sudo
iptables -L -t mangle -n" will show if that table really exists or
not.

Sure:

host:~/sshuttle# ./sshuttle -vvv --method=tproxy -r root@cosmo:22000 172.27.114.0/24
Starting sshuttle proxy.
recvmsg socket_ext support enabled.
tproxy UDP support enabled.
Binding redirector: 12300
TCP redirector listening on ('::1', 12300, 0, 0).
TCP redirector listening on ('127.0.0.1', 12300).
UDP redirector listening on ('::1', 12300, 0, 0).
UDP redirector listening on ('127.0.0.1', 12300).
firewall manager ready method tproxy.
c : connecting to server...
c : executing: ['ssh', '-p', '22000', 'root@cosmo', '--', 'P=python2; $P -V 2>/dev/null || P=python; exec "$P" -c \'import sys; skip_imports=1; verbosity=3; exec compile(sys.stdin.read(764), "assembler.py", "exec")\'']
c :  > channel=0 cmd=PING len=7 (fullness=0)
Debian GNU/Linux lenny/sid

server: assembling 'cmdline_options.py' (45 bytes)
server: assembling 'helpers.py' (791 bytes)
server: assembling 'ssubprocess.py' (13704 bytes)
server: assembling 'ssnet.py' (5582 bytes)
c : connected.
Connected.
c : Waiting: 5 r=[3, 5, 7, 8, 11] w=[11] x=[] (fullness=7/0)
c :   Ready: 5 r=[11] w=[11] x=[]
c : <  channel=0 cmd=PING len=7
c :  > channel=0 cmd=PONG len=7 (fullness=7)
c : <  channel=0 cmd=ROUTES len=36
firewall manager: starting transproxy.
server: assembling 'hostwatch.py' (2242 bytes)
server: assembling 'server.py' (2970 bytes)
 s: latency control setting = True
 s: available routes:
 s:   2/10.143.96.16/28
 s:   2/10.143.96.16/28
 s:  > channel=0 cmd=PING len=7 (fullness=0)
 s:  > channel=0 cmd=ROUTES len=36 (fullness=7)
 s: Waiting: 1 r=[4] w=[5] x=[] (fullness=43/0)
 s:   Ready: 1 r=[] w=[5] x=[]
 s: mux wrote: 15/15
 s: mux wrote: 44/44
 s: Waiting: 1 r=[4] w=[] x=[] (fullness=43/0)
>> iptables -t mangle -N sshuttle-m-12300
>> iptables -t mangle -F sshuttle-m-12300
>> iptables -t mangle -N sshuttle-d-12300
>> iptables -t mangle -F sshuttle-d-12300
>> iptables -t mangle -N sshuttle-t-12300
>> iptables -t mangle -F sshuttle-t-12300
>> iptables -t mangle -I OUTPUT 1 -j sshuttle-m-12300
>> iptables -t mangle -I PREROUTING 1 -j sshuttle-t-12300
>> iptables -t mangle -A sshuttle-d-12300 -j MARK --set-mark 1
>> iptables -t mangle -A sshuttle-d-12300 -j ACCEPT

>> iptables -t mangle -A sshuttle-t-12300 -m socket -j sshuttle-d-12300 -m tcp -p tcp

iptables: No chain/target/match by that name.
firewall manager: undoing changes.
>> iptables -t mangle -D OUTPUT -j sshuttle-m-12300
>> iptables -t mangle -F sshuttle-m-12300
>> iptables -t mangle -X sshuttle-m-12300
>> iptables -t mangle -D PREROUTING -j sshuttle-t-12300
>> iptables -t mangle -F sshuttle-t-12300
>> iptables -t mangle -X sshuttle-t-12300
>> iptables -t mangle -F sshuttle-d-12300
>> iptables -t mangle -X sshuttle-d-12300

fatal: ['iptables', '-t', 'mangle', '-A', 'sshuttle-t-12300', '-m', 'socket', '-j', 'sshuttle-d-12300', '-m', 'tcp', '-p', 'tcp'] returned 1

c : fatal: cleanup: ['python', './main.py', 'python', '-v', '-v', '-v', '--firewall', '12300', '12300', '0', '0', 'tproxy', '1'] returned 99
host:~/sshuttle#  s:   Ready: 1 r=[4] w=[] x=[]

host:~/sshuttle# sudo iptables -L -t mangle -nChain PREROUTING (policy ACCEPT)
target     prot opt source               destination        

Chain INPUT (policy ACCEPT)
target     prot opt source               destination        

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination        

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination        

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination        
host:~/sshuttle#

[Roger]

On Wed, Jul 20, 2011 at 10:00 AM, Peter Valdemar Mørch <pmo...@gmail.com> wrote:

>> iptables -t mangle -A sshuttle-t-12300 -m socket -j sshuttle-d-12300 -m tcp -p tcp

iptables: No chain/target/match by that name.

Could you also post your kernel configuration?

Thanks

Roger

[Peter Valdemar Mørch]

On Wed, Jul 20, 2011 at 4:07 AM, Roger <wen...@gmail.com> wrote:

Could you also post your kernel configuration?

Sure. I'm not doing that inline though... http://pastebin.com/QqUCz70p

Peter

[Roger]

at least this is wrong:

# CONFIG_NETFILTER_TPROXY is not set

We need tproxy support in kernel. Maybe you have other settings missing in your config as well.

My suggestion is to start with the configuration of stock (high version) kernel in your distribution.

Roger
 

[Peter Valdemar Mørch]

Will do. It takes a while to compile a new kernel, though.

Peter

[Peter Valdemar Mørch]

Yup, that worked! Thanks a lot!

[dr...@google.com]

Will this work with Mac as the client?

[Brian May]

drees via sshuttle <sshu...@googlegroups.com> writes:

> Will this work with Mac as the client?

If you mean Mac as the sshuttle client, then no. You need TPROXY
support, and TPROXY is specific to iptables found in Linux.
--
Brian May <br...@microcomaustralia.com.au>