sshuttle does not work in kernel 4.9.84 or kernel 4.14.22

[lbratch]

Hello

sshuttle does not work in at least kernel 4.9.84 or kernel 4.14.22 (and I suspect the other latest stable kernels). It was broken by the following patch:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-4.9.y&id=4ec264d8128958e66d048f45fd1c4c28cfedb119

commit 4ec264d8128958e66d048f45fd1c4c28cfedb119
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Tue Jan 30 19:01:40 2018 +0100

    netfilter: on sockopt() acquire sock lock only in the required scope
    
    commit 3f34cfae1238848fd53f25e5c8fd59da57901f4b upstream.

sshuttle appears to connect, but does not forward any traffic. In addition, it does not close cleanly (not even with a kill -9):

# sshuttle -v -r remote-host 10.0.0.0/8
Starting sshuttle proxy.
firewall manager: Starting firewall with Python version 3.5.4
firewall manager: ready method name nat.
IPv6 enabled: False
UDP enabled: False
DNS enabled: False
TCP redirector listening on ('127.0.0.1', 12300).
Starting client with Python version 3.5.4
c : connecting to server...
Password:
Starting server with Python version 3.5.4
 s: latency control setting = True
c : Connected.
 s: available routes:
 s:   2/10.0.0.0/8
firewall manager: setting up.
>> 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.1/32 -p tcp
>> iptables -t nat -A sshuttle-12300 -j REDIRECT --dest 10.0.0.0/8 -p tcp --to-ports 12300 -m ttl ! --ttl 42
^CKilled by signal 2.
^C^C^C
^C

Reverting the kernel patch fixes the issue.

I realise this may be a kernel bug (not sure if this counts as breaking userspace...) and if so I'm happy to file a bug there instead.

Thanks
Luke

[brianmay]

Thanks for your report, including the link to the kernel commit that broke things. By the looks of it, the kernel patch wasn't supposed to change the userspace experience, and as a result, yes it does sound like a kernel issue. Furthermore, if it breaks sshuttle, it is likely to break other things too (maybe transparent proxies?)

I think keeping this bug report open for now will probably be a good thing, however, as chances are it won't be long until other people have similar problems.

If you do file a kernel bug report, please link to it here.

Thanks again!

[lbratch]

Good news, I reported it to the kernel developers and they already had a fix queued up.

Bug thread:
https://marc.info/?t=151972462000001

Queued fix:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-4.9/netfilter-drop-outermost-socket-lock-in-getsockopt.patch?id=9b5ac8914f462baebf3db3515f7625c4e22d1e6f

I'll post again in this thread when I see it appear in a stable kernel release.

[douglassd]

Thanks for reporting @lbratch. I ran into this prior to your report, after I updated to kernel 4.15.6 (with various patches from repo-ck ). Rolling back to 4.15.5 fixed the problem.

kernel 4.15.7 was released on 2018-02-28 and has fixed the issue for me. From the release notes:

commit d7ef969797fdeeb12a3afe069d86d1eaf037ac71
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Thu Feb 8 12:19:00 2018 +0100

netfilter: drop outermost socket lock in getsockopt()

commit 01ea306f2ac2baff98d472da719193e738759d93 upstream. 

[lbratch]

I can confirm that things are fixed in 4.9.85 and 4.14.23 too (also released yesterday).

[majewsky]

Another confirmation: sshuttle was broken with kernel 4.15.6, is working again with 4.15.7 (on Arch Linux).

[kudesibe]

I'm on fedora 27 and sshuttle was broken with 4.15.6, I found this article and update it to 4.15.7, after that my sshuttle works as before.

[kostyrev]

I think we've got it already.
what's the point to enumerate all OSes?

[alezzandro]

Same issue here!

4.15.6-300.fc27.x86_64

Solved jumping back to
4.14.11-300.fc27.x86_64

[savvasal]

Same here.

4.15.4-300.fc27 works also.

[brianmay]

Closing this as fixed in Linux kernel.