Shadowsocks-libev malfunctioning on OpenWrt 19.07.2

My goal is to set up shadowsocks on my router so that it would reroute all network traffic to the remote server. To achieve this, I followed this tutorial as suggested by previous users on this forum:

https://github.com/openwrt/packages/blob/master/net/shadowsocks-libev/README.md

Everything was going fine up till I reach the last step where domain name resolution seems to just fail completely after applying changes to dnsmasq.

user@iMac ~ % unset {http,https,ftp}_proxy
user@iMac ~ % nslookup google.com
;; connection timed out; no servers could be reached
user@iMac ~ % nslookup baidu.com
;; connection timed out; no servers could be reached

Any suggestions?

EDIT: Solved, for detailed solution see post #8. In fact this isn't actually a solution but more like a workaround. Check it out here if you couldn't be bothered with the reading.

https://forum.openwrt.org/t/shadowsocks-libev-malfunctioning-on-openwrt-19-07-2/63189/8?u=smartjq

Ok, some background. These are the contents of the config files as I get to the last step.

Shadowsocks-libev configuration (/etc/config/shadowsocks-libev):

config ss_rules 'ss_rules'
	option dst_default 'forward'
	option local_default 'forward'
	option dst_forward_recentrst '0'
	option src_default 'checkdst'
	option redir_tcp 'redir'
	option redir_udp 'redir'

config server 'vultr_jp_v4'
	option server '[REDACTED]'
	option server_port '[REDACTED]'
	option method 'chacha20-ietf-poly1305'
	option password '[REDACTED]'

config ss_redir 'redir'
	option mode 'tcp_and_udp'
	option reuse_port '1'
	option local_port '1100'
	option local_address '0.0.0.0'
	option server 'vultr_jp_v4'
	option disabled 'false'

config ss_tunnel 'tunnel'
	option mode 'tcp_and_udp'
	option local_port '8053'
	option server 'vultr_jp_v4'
	option tunnel_address '108.61.10.10:53' //tried "8.8.8.8:53" and "1.1.1.1:53" before but neither worked
	option local_address '127.0.0.1'
	option disabled 'false'

config ss_local 'local' //this was used to validate the configuration for the server and it turned out shadowsocks would work just fine using this mode whilst enabling socks proxy on one of my client computers
	option mode 'tcp_and_udp'
	option local_address '192.168.1.1'
	option local_port '1080'
	option server 'vultr_jp_v4'
	option disabled 'true'

DHCP configuration (/etc/config/dhcp):

root@OpenWrt:~# cat /etc/config/dhcp 

config dnsmasq
	option domainneeded '1'
	option localise_queries '1'
	option rebind_protection '1'
	option rebind_localhost '1'
	option local '/lan/'
	option domain 'lan'
	option expandhosts '1'
	option authoritative '1'
	option readethers '1'
	option leasefile '/tmp/dhcp.leases'
	option localservice '1'
	list server '127.0.0.1#8053'
	option noresolv 1
	option localuse 1

config dhcp 'lan'
	option interface 'lan'
	option start '100'
	option limit '150'
	option leasetime '12h'

config dhcp 'wan'
	option interface 'wan'
	option ignore '1'

CLI output for intermediary steps should that be helpful:

root@OpenWrt:~# iptables-save | grep ss_rules
:ss_rules_dst - [0:0]
:ss_rules_forward - [0:0]
:ss_rules_local_out - [0:0]
:ss_rules_pre_src - [0:0]
:ss_rules_src - [0:0]
-A PREROUTING -p tcp -j ss_rules_pre_src
-A OUTPUT -p tcp -j ss_rules_local_out
-A ss_rules_dst -m set --match-set ss_rules_dst_bypass dst -j RETURN
-A ss_rules_dst -m set --match-set ss_rules_dst_forward dst -j ss_rules_forward
-A ss_rules_dst -j ss_rules_forward
-A ss_rules_forward -p tcp -j REDIRECT --to-ports 1100
-A ss_rules_local_out -m set --match-set ss_rules_dst_bypass_ dst -j RETURN
-A ss_rules_local_out -j ss_rules_forward
-A ss_rules_pre_src -m set --match-set ss_rules_dst_bypass_ dst -j RETURN
-A ss_rules_pre_src -j ss_rules_src
-A ss_rules_src -m set --match-set ss_rules_src_bypass src -j RETURN
-A ss_rules_src -m set --match-set ss_rules_src_forward src -j ss_rules_forward
-A ss_rules_src -m set --match-set ss_rules_src_checkdst src -j ss_rules_dst
-A ss_rules_src -j ss_rules_dst
:ss_rules_dst - [0:0]
:ss_rules_forward - [0:0]
:ss_rules_pre_src - [0:0]
:ss_rules_src - [0:0]
-A PREROUTING -p udp -j ss_rules_pre_src
-A ss_rules_dst -m set --match-set ss_rules_dst_bypass dst -j RETURN
-A ss_rules_dst -m set --match-set ss_rules_dst_forward dst -j ss_rules_forward
-A ss_rules_dst -j ss_rules_forward
-A ss_rules_forward -p udp -j TPROXY --on-port 1100 --on-ip 0.0.0.0 --tproxy-mark 0x1/0x1
-A ss_rules_pre_src -m set --match-set ss_rules_dst_bypass_ dst -j RETURN
-A ss_rules_pre_src -j ss_rules_src
-A ss_rules_src -m set --match-set ss_rules_src_bypass src -j RETURN
-A ss_rules_src -m set --match-set ss_rules_src_forward src -j ss_rules_forward
-A ss_rules_src -m set --match-set ss_rules_src_checkdst src -j ss_rules_dst
-A ss_rules_src -j ss_rules_dst
root@OpenWrt:~# netstat -lntp | grep -E '8053|1100'
tcp        0      0 0.0.0.0:1100            0.0.0.0:*               LISTEN      8998/ss-redir
tcp        0      0 127.0.0.1:8053          0.0.0.0:*               LISTEN      8999/ss-tunnel
root@OpenWrt:~# ps ww | grep ss-
 8998 root      2364 S    /usr/bin/ss-redir -c /var/etc/shadowsocks-libev/ss_redir.redir.json
 8999 root      1928 S    /usr/bin/ss-tunnel -c /var/etc/shadowsocks-libev/ss_tunnel.tunnel.json
10582 root      1216 S    grep ss-

Some update:
Looks like ss_redir is working considering the international page for Bing would load up if I try to go to bing.com using its previously resolved IP and my browser does seem to have the external IP of the remote server.

It seems to me that somewhere between ss_tunnel and dnsmasq is broken that's causing DNS resolution to fail. I am completely lost now :frowning:

Any help would be greatly appreciated!!!! <3

EDIT: Looked around the forum a bit and I suspect this might be a duplicate of this issue. Not sure tho.

Yet another update:
ss-tunnel seems to be the culprit here although I can't see how it wouldn't work.

In theory, this command should give me a tunnel to translates 8.8.8.8:53 to 127.0.0.1:5300 (or at least that's the command actually being used by the openwrt shadowsocks service anyway):

ss-tunnel -c /var/etc/shadowsocks.cfg054a8f.json -U -l 5300 -L 8.8.8.8:53 --mtu 1492 -f /var/run/ss-tunnel-cfg054a8f.pid -v

After forwarding the port, if I do nslookup google.com 127.0.0.1:5300, it would still report ;; connection timed out; no servers could be reached, which seems to me that the tunnel is somehow broken although other shadowsocks services work. Using netcat I can see that the udp port 5300 on my router should be open:

user@iMac ~ % nc -uzvw3 192.168.1.1 5300
Connection to 192.168.1.1 port 5300 [udp/hacl-hb] succeeded!

If I run the command nslookup google.com 8.8.8.8#53 on the remote server everything just works and it gives me:

[root@SS ~]# nslookup google.com 8.8.8.8
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
Name:	google.com
Address: 172.217.6.238
Name:	google.com
Address: 2607:f8b0:4006:805::200e

So I'm assuming ss-tunnel should be the source of the problem.
Any ideas?

I use ss-redir too.The different is that I use dns-over-tls to deal with DNS pollution .

1 Like

Thanks so much for the reply. This really helped having scratched my head cluelessly for hours. <3

After pulling up a quick search, I found there are several DNS over TLS solutions around for OpenWrt.

https://openwrt.org/docs/guide-user/services/dns/dot_unbound
https://openwrt.org/docs/guide-user/services/dns/dot_dnsmasq_stubby

In the case that if I were to aim for minimal performance overhead, may I ask would you recommend using Unbound or Stubby?

Fixed with @RavenChan's workaround.

Turns out for some reason ss-tunnel keeps failing to redirect UDP traffic but DNS over TLS works. I suspect this is because DNS pollution happens to all UDP packets towards outside of the nationwide firewall so encapsulating UDP traffic within TLS TCP would "just work". On OpenWrt this can be solved by using Unbound which if I'm understanding everything correctly here will give you DNS resolution over TLS, hence TCP traffic.

Basically you just have to ditch ss-tunnel for tunneling through DNS resolution and instead use Unbound, setting it to whichever clean DNS server you'd like to use (personally I'm using 1.1.1.1). I guess this implies performance wise there will be a reduction if ss-redir isn't enabled for localhost but honestly this is the next best alternative so I'm accepting this with as my final solution.

Marking solved now.

Personally I would recommend using Stubby.Unbound kind of has some issue with CNAME(which is what I'm experiencing right now.)Here is a post regard this CNAME thing but it's Chinese:https://www.v2ex.com/t/561495

1 Like

Ah I see, so currently Unbound has problems filtering subdomains while interfering with DNS resolution. I guess Iโ€™ll wait until they merge the patch into its master branch thereby into the OpenWrt build bot and see what happens next. As of now Iโ€™m quite satisfied with my setup since global mode was all I needed. But then again, I can see how itโ€™d be a nice addition to Unbound itself.

Appreciate the suggestion!

If I remember correctly,Unbound doesn't compile with ipset.So if your set up requires ipset , you have to compile Unbound yourself.

Unbound automatically will not appear to follow CNAME that cross SOA or CNAME inserted into its configuration files. The client will be given the CNAME and the client will need to ask the next question. dnsmasq automatically completes CNAME because it just wants an A/AAAA record and simply forwards all requests to the one or two upstream servers anyway. Github issues on CNAME filtering.

Unbound 1.10.0 package has ipset support with Unbound-daemon-heavy

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.